Add Reports to Support createRMD - ruleset model description #10372

JasonGlazer · 2024-01-18T19:45:59Z

Pull request overview

Support for the next phase of createRMD development by adding reports and the NFP

Pull Request Author

Add to this list or remove from it as applicable. This is a simple templated set of guidelines.

Reviewer

This will not be exhaustively relevant to every PR.

…] [actions skip]

… other fixes [decent_ci_skip] [actions skip]

… [actions skip]

…eateRMD-Ph3

…ctions skip]

…yPlus into Support-CreateRMD-Ph3

…eateRMD-Ph3

…nt heating coils table

…eateRMD-Ph3

…Pump:AirToAir and AirLoopHVAC:UnitaryHeatPump:WaterToAir

…yPlus into Support-CreateRMD-Ph3

…rmat

Myoldmopar

This is a huge set of changes. I actually tried to get through them all. Looks like some pretty standard patterns being applied, you've documented it well, and lots of added testing including 2 new unit test files. I have a couple questions/comments, but I suspect this is very close.

Myoldmopar · 2024-07-10T13:43:22Z

src/EnergyPlus/CondenserLoopTowers.cc

@@ -3427,7 +3427,7 @@ namespace CondenserLoopTowers {
                this->Name,
                state.dataPlnt->PlantLoop(this->plantLoc.loopNum).FluidName); // Fluid Name more reasonable than FluidType
            OutputReportPredefined::PreDefTableEntry(state, state.dataOutRptPredefined->pdchCTFCRange, this->Name, this->DesignRange);
-            OutputReportPredefined::PreDefTableEntry(state, state.dataOutRptPredefined->pdchCTFCRange, this->Name, this->DesignApproach);
+            OutputReportPredefined::PreDefTableEntry(state, state.dataOutRptPredefined->pdchCTFCApproach, this->Name, this->DesignApproach);


Myoldmopar · 2024-07-10T13:45:00Z

src/EnergyPlus/Construction.cc

+{
+    // Report the layers for each opaque construction in predefined tabular report
+    // J. Glazer March 2024
+    auto &opd = state.dataOutRptPredefined;


I don't think you ever used this shortcut you made. I'd say either remove it or use it in the loop. In this tiny little function with just a couple uses, it's fine either way. Also maybe I just can't see the usage here on GH.

Thanks, I removed that line.

Myoldmopar · 2024-07-10T13:46:13Z

src/EnergyPlus/Construction.cc

+    if (state.dataOutRptPredefined->pdchOpqConsLayCol.size() > 0) {
+        for (int i = 1; i <= this->TotLayers; ++i) {
+            int layerIndex = this->LayerPoint(i);
+            auto const *thisMaterial = state.dataMaterial->Material(layerIndex);


Hmm... are materials held as pointers? If so, this is great. If not, this is still technically right, but you could use a reference instead like we do all over. I'm assuming it must be held as a pointer or you wouldn't have done that.

Thanks, I just copied that line without thinking. I fixed it to a normal reference.

Myoldmopar · 2024-07-10T13:48:27Z

src/EnergyPlus/DataAirLoop.hh

@@ -85,6 +85,9 @@ namespace DataAirLoop {
        Array1D_int TermUnitCoolSizingIndex;       // Air terminal sizing numbers for zones cooled by this air loop
        Array1D_int TermUnitHeatSizingIndex;       // Air terminal sizing numbers for zones heated by this air loop
        Array1D<HVAC::AirDuctType> SupplyDuctType; // 1=main, 2=cooling, 3=heating, 4=other
+        Array1D_int SupplyDuctBranchNum;           // Supply duct branch number
+        Array1D_int SupplyAirPathNum;              // Supply air path indexes
+        Array1D_int ReturnAirPathNum;              // Return air path indexes


OK, but I still think EPVector is a better option for a lightweight 1-based array. Both Array1D and EPVector are destined to become regular old C++ vectors, so it's not crucial, but @jasondegraw and company have set up EPVector as a great piece of that transition.

Anyway, no huge deal, carrying on...

Using EPVector is a good idea here.

Myoldmopar · 2024-07-10T13:51:01Z

src/EnergyPlus/Fans.cc

@@ -2386,8 +2397,8 @@ void FanComponent::report(EnergyPlusData &state)
    totalEnergy = totalPower * state.dataHVACGlobal->TimeStepSysSec;
    deltaTemp = outletAirTemp - inletAirTemp;

-    if (type == HVAC::FanType::OnOff) {
-        if (airLoopNum > 0) {
+    if (isAFNFan && (airLoopNum > 0)) {


Is isAFNFan another bug fix?

I don't remember @mjwitte do you?

Is isAFNFan another bug fix?

Not really. Previously airLoopNum was being used (abused) only for AFN fans. So, the code assumed that airloopNum>0 meant this fan was an AFN fan. When I expanded the use of airLoopNum for be set for all fans (to support RMD reports) that was no longer the case, so I added the new isAFNFan flag to track that.

Myoldmopar · 2024-07-10T13:52:13Z

src/EnergyPlus/Furnaces.cc

@@ -688,6 +689,8 @@ namespace Furnaces {
        std::string_view constexpr getAirLoopHVACHeatCoolInput("GetAirLoopHVACHeatCoolInput");
        std::string_view constexpr routineName = "GetFurnaceInput";

+        using namespace OutputReportPredefined;


Is this needed? You are explicitly listing out the namespace when you are calling PreDefTableEntry, which is our current pattern, so I'm not sure this is needed.

Myoldmopar · 2024-07-10T13:53:33Z

src/EnergyPlus/SimAirServingZones.cc

@@ -1479,8 +1486,10 @@ void InitAirLoops(EnergyPlusData &state, bool const FirstHVACIteration) // TRUE
            }
            EPVector<int> supNode;
            EPVector<DataZoneEquipment::AirNodeType> supNodeType;
+            EPVector<int> supNodeCompNum;


weilixu · 2024-07-10T14:58:56Z