Fix #10857 - Report System Summary:Thermostat Schedules depends on order of ZoneControl:Thermostat control types by jmarrec · Pull Request #10861 · NatLabRockies/EnergyPlus

jmarrec · 2024-12-17T14:07:56Z

Pull request overview

Fixes Report System Summary:Thermostat Schedules depends on order of ZoneControl:Thermostat control types #10857

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.

…: schedule reported the opposite #10857 (comment)

…Thermostat with ", "

…no matter the order in which Tstat controls are declared

jmarrec · 2024-12-17T14:09:20Z

tst/EnergyPlus/unit/ZoneTempPredictorCorrector.unit.cc

+    EXPECT_EQ("SINGLEHEATINGSCH", RetrievePreDefTableEntry(*state, orp.pdchStatSchdHeatName, "zoneA"));
+    EXPECT_EQ("NOT FOUND", RetrievePreDefTableEntry(*state, orp.pdchStatSchdCoolName, "zoneA"));


Existing test was incorrect, cf #10857 (comment)

jmarrec · 2024-12-17T14:09:27Z

tst/EnergyPlus/unit/ZoneTempPredictorCorrector.unit.cc

+    EXPECT_EQ("NOT FOUND", RetrievePreDefTableEntry(*state, orp.pdchStatSchdHeatName, "zoneB"));
+    EXPECT_EQ("SINGLECOOLINGSCH", RetrievePreDefTableEntry(*state, orp.pdchStatSchdCoolName, "zoneB"));


jmarrec · 2024-12-17T14:15:06Z

tst/EnergyPlus/unit/ZoneTempPredictorCorrector.unit.cc

+
+TEST_F(EnergyPlusFixture, FillPredefinedTableOnThermostatSchedules_MultipleControls)
+{
+    using namespace EnergyPlus::OutputReportPredefined;
+
+    state->dataScheduleMgr->Schedule.allocate(6);
+    constexpr int SingleHeatingSchIndex = 1;
+    constexpr int SingleCoolingSchIndex = 2;
+    constexpr int SingleHeatCoolSchIndex = 3;
+    constexpr int DualSetPointWDeadBandHeatSchIndex = 4;
+    constexpr int DualSetPointWDeadBandCoolSchIndex = 5;
+    constexpr int CTSchedIndex = 6;
+    state->dataScheduleMgr->Schedule(SingleHeatingSchIndex).Name = "SINGLEHEATINGSCH";
+    state->dataScheduleMgr->Schedule(SingleCoolingSchIndex).Name = "SINGLECOOLINGSCH";
+    state->dataScheduleMgr->Schedule(SingleHeatCoolSchIndex).Name = "SINGLEHEATCOOLSCH";
+    state->dataScheduleMgr->Schedule(DualSetPointWDeadBandHeatSchIndex).Name = "DUALSETPOINTWDEADBANDHEATSCH";
+    state->dataScheduleMgr->Schedule(DualSetPointWDeadBandCoolSchIndex).Name = "DUALSETPOINTWDEADBANDCOOLSCH";
+    state->dataScheduleMgr->Schedule(CTSchedIndex).Name = "CONTROL SCHEDULE";
+
+    state->dataScheduleMgr->ScheduleInputProcessed = true;
+
+    auto &orp = *state->dataOutRptPredefined;
+    auto &dzc = *state->dataZoneCtrls;
+
+    SetPredefinedTables(*state);
+
+    constexpr int NumControlTypes = 4;
+    dzc.NumTempControlledZones = NumControlTypes;
+    dzc.TempControlledZone.allocate(dzc.NumTempControlledZones);
+
+    // [1, 2, 3, 4]
+    std::vector<int> order(NumControlTypes);
+    std::iota(order.begin(), order.end(), 1);
+    for (size_t i = 0; i < order.size(); ++i) {
+        char zoneLetter = char(int('A') + i);
+        // Simple left rotate: [2, 3, 4, 1], etc
+        std::rotate(order.begin(), std::next(order.begin()), order.end());
+        auto &tcz = dzc.TempControlledZone(i + 1);
+
+        const std::string ZoneName = fmt::format("ZONE {}", zoneLetter);
+        tcz.ZoneName = ZoneName;
+        tcz.Name = fmt::format("TSTAT {}", zoneLetter);
+        tcz.ControlTypeSchedName = state->dataScheduleMgr->Schedule(CTSchedIndex).Name;
+        tcz.CTSchedIndex = CTSchedIndex;
+        tcz.NumControlTypes = NumControlTypes;
+        tcz.ControlTypeEnum.allocate(NumControlTypes);
+        tcz.ControlTypeName.allocate(NumControlTypes);
+
+        tcz.ControlTypeEnum(order.at(0)) = HVAC::ThermostatType::SingleHeating;
+        tcz.ControlTypeName(order.at(0)) = "SINGLEHEATING CTRL";
+        tcz.SchIndx_SingleHeatSetPoint = SingleHeatingSchIndex;
+
+        tcz.ControlTypeEnum(order.at(1)) = HVAC::ThermostatType::SingleCooling;
+        tcz.ControlTypeName(order.at(1)) = "SINGLECOOLING CTRL";
+        tcz.SchIndx_SingleCoolSetPoint = SingleCoolingSchIndex;
+
+        tcz.ControlTypeEnum(order.at(2)) = HVAC::ThermostatType::SingleHeatCool;
+        tcz.ControlTypeName(order.at(2)) = "SINGLEHEATCOOL CTRL";
+        tcz.SchIndx_SingleHeatCoolSetPoint = SingleHeatCoolSchIndex;
+
+        tcz.ControlTypeEnum(order.at(3)) = HVAC::ThermostatType::DualSetPointWithDeadBand;
+        tcz.ControlTypeName(order.at(3)) = "DUALSETPOINTWITHDEADBAND CTRL";
+        tcz.SchIndx_DualSetPointWDeadBandHeat = DualSetPointWDeadBandHeatSchIndex;
+        tcz.SchIndx_DualSetPointWDeadBandCool = DualSetPointWDeadBandCoolSchIndex;
+    }
+
+    FillPredefinedTableOnThermostatSchedules(*state);


New unit test.

I define ZoneControlThermostats with each having all of these:

ThermostatSetpoint:SingleHeating

ThermostatSetpoint:SingleCooling

ThermostatSetpoint:SingleHeatingOrCooling

ThermostatSetpoint:DualSetpoint

I test 4 different orders of declaration (I use a left rotate), since it seems the wanted feature on the #10857 was it shouldn't differ no matter in which order the control types were defined.

ZONE A i=0, order=[2, 3, 4, 1] SingleCooling, SingleHeatCool, DualSetPointWithDeadBand, SingleHeating, ZONE B i=1, order=[3, 4, 1, 2] SingleHeatCool, DualSetPointWithDeadBand, SingleHeating, SingleCooling, ZONE C i=2, order=[4, 1, 2, 3] DualSetPointWithDeadBand, SingleHeating, SingleCooling, SingleHeatCool, ZONE D i=3, order=[1, 2, 3, 4] SingleHeating, SingleCooling, SingleHeatCool, DualSetPointWithDeadBand,

jmarrec · 2024-12-17T14:15:29Z

tst/EnergyPlus/unit/ZoneTempPredictorCorrector.unit.cc

+    for (size_t i = 0; i < order.size(); ++i) {
+        char zoneLetter = char(int('A') + i);
+        const std::string ZoneName = fmt::format("ZONE {}", zoneLetter);
+        EXPECT_EQ(fmt::format("TSTAT {}", zoneLetter), RetrievePreDefTableEntry(*state, orp.pdchStatName, ZoneName)) << "Failed for " << ZoneName;
+        EXPECT_EQ("CONTROL SCHEDULE", RetrievePreDefTableEntry(*state, orp.pdchStatCtrlTypeSchd, ZoneName)) << "Failed for " << ZoneName;
+        EXPECT_EQ("DualSetPointWithDeadBand, SingleCooling, SingleHeatCool, SingleHeating",
+                  RetrievePreDefTableEntry(*state, orp.pdchStatSchdType1, ZoneName))
+            << "Failed for " << ZoneName;
+        EXPECT_EQ("DUALSETPOINTWITHDEADBAND CTRL, SINGLECOOLING CTRL, SINGLEHEATCOOL CTRL, SINGLEHEATING CTRL",
+                  RetrievePreDefTableEntry(*state, orp.pdchStatSchdTypeName1, ZoneName))
+            << "Failed for " << ZoneName;
+        EXPECT_EQ("DUALSETPOINTWDEADBANDHEATSCH, SINGLEHEATCOOLSCH, SINGLEHEATINGSCH",
+                  RetrievePreDefTableEntry(*state, orp.pdchStatSchdHeatName, ZoneName))
+            << "Failed for " << ZoneName;
+        EXPECT_EQ("DUALSETPOINTWDEADBANDCOOLSCH, SINGLECOOLINGSCH, SINGLEHEATCOOLSCH",
+                  RetrievePreDefTableEntry(*state, orp.pdchStatSchdCoolName, ZoneName))
+            << "Failed for " << ZoneName;
+    }


Order stays the same.

I join the names when multiple found with a ", "

jmarrec · 2024-12-17T14:16:15Z

src/EnergyPlus/ZoneTempPredictorCorrector.cc

+    // Helper struct so we can sort to ensure a consistent order.
+    // No matter the order in which the multiple Field Sets (Control Object Type, Control Name), the same thing is reported to the tabular outputs
+    struct ControlTypeInfo
+    {
+        // HVAC::ThermostatType tType = HVAC::ThermostatType::Invalid;
+        std::string thermostatType;
+        std::string controlTypeName;
+        std::string heatSchName;
+        std::string coolSchName;
+
+        // Only need the operator<, and we use C++17 so I can't use a defaulted 3-way operator<=>
+        bool operator<(const ControlTypeInfo &other) const
+        {
+            return std::tie(this->thermostatType, this->controlTypeName, this->heatSchName, this->coolSchName) <
+                   std::tie(other.thermostatType, other.controlTypeName, other.heatSchName, other.coolSchName);
+        }
+    };


A struct so we can collect the multiple control types, and sort them, so the order doesn't matter.

Oooh, interesting. I hadn't paid attention to std tie. This isn't something that happens regularly throughout the simulation though, right?

Happens only once, at the end of ManageSimulation: https://github.com/NREL/EnergyPlus/blob/31e3c33467c5873371bf48b12a7318215971c315/src/EnergyPlus/SimulationManager.cc#L553

Call chain:
WriteTabularReports > FillRemainingPredefinedEntries > FillPredefinedTableOnThermostatSchedules

jmarrec · 2024-12-17T14:16:41Z

src/EnergyPlus/ZoneTempPredictorCorrector.cc

+    using ControlTypeInfoMemPtr = std::string ControlTypeInfo::*;
+
+    auto joinStrings = [](const std::vector<ControlTypeInfo> &infos, ControlTypeInfoMemPtr memPtr) -> std::string {
+        std::vector<std::string> result;
+        result.reserve(infos.size());
+        for (const auto &info : infos) {
+            std::string val = info.*memPtr;
+            if (val.empty()) {
+                continue;
+            }
+            result.emplace_back(std::move(val));
+        }
+        return fmt::format("{}", fmt::join(result, ", "));
+    };


Some shenanigans with a Pointer to member to collect and join.

Indeed. Reminds me of some of our other functions that operate on structs that have a .Name string member.

jmarrec · 2024-12-17T14:17:02Z

src/EnergyPlus/ZoneTempPredictorCorrector.cc

+        std::vector<ControlTypeInfo> infos;
+        infos.reserve(tcz.NumControlTypes);
        for (int ctInx = 1; ctInx <= tcz.NumControlTypes; ++ctInx) {
-            PreDefTableEntry(state, orp->pdchStatSchdType1, tcz.ZoneName, HVAC::thermostatTypeNames[(int)tcz.ControlTypeEnum(ctInx)]);
-            PreDefTableEntry(state, orp->pdchStatSchdTypeName1, tcz.ZoneName, tcz.ControlTypeName(1));
+            ControlTypeInfo info;
+            info.thermostatType = HVAC::thermostatTypeNames[(int)tcz.ControlTypeEnum(ctInx)];
+            info.controlTypeName = tcz.ControlTypeName(ctInx);
            switch (tcz.ControlTypeEnum(ctInx)) {
            case HVAC::ThermostatType::DualSetPointWithDeadBand:
-                PreDefTableEntry(
-                    state, orp->pdchStatSchdHeatName, tcz.ZoneName, ScheduleManager::GetScheduleName(state, tcz.SchIndx_DualSetPointWDeadBandHeat));
-                PreDefTableEntry(
-                    state, orp->pdchStatSchdCoolName, tcz.ZoneName, ScheduleManager::GetScheduleName(state, tcz.SchIndx_DualSetPointWDeadBandCool));
+                info.coolSchName = ScheduleManager::GetScheduleName(state, tcz.SchIndx_DualSetPointWDeadBandCool);
+                info.heatSchName = ScheduleManager::GetScheduleName(state, tcz.SchIndx_DualSetPointWDeadBandHeat);
                break;
            case HVAC::ThermostatType::SingleHeatCool:
-                PreDefTableEntry(
-                    state, orp->pdchStatSchdHeatName, tcz.ZoneName, ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleHeatCoolSetPoint));
-                PreDefTableEntry(
-                    state, orp->pdchStatSchdCoolName, tcz.ZoneName, ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleHeatCoolSetPoint));
+                info.coolSchName = ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleHeatCoolSetPoint);
+                info.heatSchName = ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleHeatCoolSetPoint);
                break;
            case HVAC::ThermostatType::SingleCooling:
-                PreDefTableEntry(
-                    state, orp->pdchStatSchdHeatName, tcz.ZoneName, ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleCoolSetPoint));
+                info.coolSchName = ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleCoolSetPoint);
                break;
            case HVAC::ThermostatType::SingleHeating:
-                PreDefTableEntry(
-                    state, orp->pdchStatSchdCoolName, tcz.ZoneName, ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleHeatSetPoint));
+                info.heatSchName = ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleHeatSetPoint);
                break;
            }
+            infos.emplace_back(std::move(info));
+        }


Alright, collect the Control Type infos.

OK this is nicer looking.

jmarrec · 2024-12-17T14:17:07Z

src/EnergyPlus/ZoneTempPredictorCorrector.cc

            }
+            infos.emplace_back(std::move(info));
+        }
+        std::sort(infos.begin(), infos.end());


jmarrec · 2024-12-17T14:19:28Z

src/EnergyPlus/ZoneTempPredictorCorrector.cc

+        PreDefTableEntry(state, orp->pdchStatSchdType1, tcz.ZoneName, joinStrings(infos, &ControlTypeInfo::thermostatType));
+        PreDefTableEntry(state, orp->pdchStatSchdTypeName1, tcz.ZoneName, joinStrings(infos, &ControlTypeInfo::controlTypeName));
+        if (auto heatSchNames = joinStrings(infos, &ControlTypeInfo::heatSchName); !heatSchNames.empty()) {
+            PreDefTableEntry(state, orp->pdchStatSchdHeatName, tcz.ZoneName, heatSchNames);
+        }
+        if (auto coolSchNames = joinStrings(infos, &ControlTypeInfo::coolSchName); !coolSchNames.empty()) {
+            PreDefTableEntry(state, orp->pdchStatSchdCoolName, tcz.ZoneName, coolSchNames);


Then join them with ", ".

For HeatSchNames / CoolSchNames, it's possible it's empty, and writing a "" is not the same as a null, so an extra if statement there

Got it. Great.

github-actions · 2024-12-17T14:57:37Z

⚠️ Regressions detected on macos-14 for commit `f35325f`

Regression Summary

Table String Diffs: 308
Audit: 304

github-actions · 2024-12-17T14:58:47Z

⚠️ Regressions detected on macos-14 for commit `7b68cb9`

Regression Summary

Table String Diffs: 308
Audit: 304

github-actions · 2024-12-17T15:09:33Z

⚠️ Regressions detected on macos-14 for commit `8397ca6`

Regression Summary

Table String Diffs: 308
Audit: 304

nrel-bot-2c · 2024-12-25T00:19:08Z

@jmarrec it has been 7 days since this pull request was last updated.

nrel-bot-2 · 2025-01-02T00:25:25Z

@jmarrec it has been 8 days since this pull request was last updated.

nrel-bot-2 · 2025-01-10T00:28:48Z

@jmarrec it has been 8 days since this pull request was last updated.

Myoldmopar

Yeah, nice looking stuff in here. Thanks @jmarrec

Myoldmopar · 2025-01-10T19:22:25Z

src/EnergyPlus/ZoneTempPredictorCorrector.cc

+    using ControlTypeInfoMemPtr = std::string ControlTypeInfo::*;
+
+    auto joinStrings = [](const std::vector<ControlTypeInfo> &infos, ControlTypeInfoMemPtr memPtr) -> std::string {
+        std::vector<std::string> result;
+        result.reserve(infos.size());
+        for (const auto &info : infos) {
+            std::string val = info.*memPtr;
+            if (val.empty()) {
+                continue;
+            }
+            result.emplace_back(std::move(val));
+        }
+        return fmt::format("{}", fmt::join(result, ", "));
+    };


Indeed. Reminds me of some of our other functions that operate on structs that have a .Name string member.

Myoldmopar · 2025-01-10T19:22:41Z

tst/EnergyPlus/unit/ZoneTempPredictorCorrector.unit.cc

+    EXPECT_EQ("SINGLEHEATINGSCH", RetrievePreDefTableEntry(*state, orp.pdchStatSchdHeatName, "zoneA"));
+    EXPECT_EQ("NOT FOUND", RetrievePreDefTableEntry(*state, orp.pdchStatSchdCoolName, "zoneA"));


Myoldmopar · 2025-01-10T19:23:56Z

src/EnergyPlus/ZoneTempPredictorCorrector.cc

+        std::vector<ControlTypeInfo> infos;
+        infos.reserve(tcz.NumControlTypes);
        for (int ctInx = 1; ctInx <= tcz.NumControlTypes; ++ctInx) {
-            PreDefTableEntry(state, orp->pdchStatSchdType1, tcz.ZoneName, HVAC::thermostatTypeNames[(int)tcz.ControlTypeEnum(ctInx)]);
-            PreDefTableEntry(state, orp->pdchStatSchdTypeName1, tcz.ZoneName, tcz.ControlTypeName(1));
+            ControlTypeInfo info;
+            info.thermostatType = HVAC::thermostatTypeNames[(int)tcz.ControlTypeEnum(ctInx)];
+            info.controlTypeName = tcz.ControlTypeName(ctInx);
            switch (tcz.ControlTypeEnum(ctInx)) {
            case HVAC::ThermostatType::DualSetPointWithDeadBand:
-                PreDefTableEntry(
-                    state, orp->pdchStatSchdHeatName, tcz.ZoneName, ScheduleManager::GetScheduleName(state, tcz.SchIndx_DualSetPointWDeadBandHeat));
-                PreDefTableEntry(
-                    state, orp->pdchStatSchdCoolName, tcz.ZoneName, ScheduleManager::GetScheduleName(state, tcz.SchIndx_DualSetPointWDeadBandCool));
+                info.coolSchName = ScheduleManager::GetScheduleName(state, tcz.SchIndx_DualSetPointWDeadBandCool);
+                info.heatSchName = ScheduleManager::GetScheduleName(state, tcz.SchIndx_DualSetPointWDeadBandHeat);
                break;
            case HVAC::ThermostatType::SingleHeatCool:
-                PreDefTableEntry(
-                    state, orp->pdchStatSchdHeatName, tcz.ZoneName, ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleHeatCoolSetPoint));
-                PreDefTableEntry(
-                    state, orp->pdchStatSchdCoolName, tcz.ZoneName, ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleHeatCoolSetPoint));
+                info.coolSchName = ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleHeatCoolSetPoint);
+                info.heatSchName = ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleHeatCoolSetPoint);
                break;
            case HVAC::ThermostatType::SingleCooling:
-                PreDefTableEntry(
-                    state, orp->pdchStatSchdHeatName, tcz.ZoneName, ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleCoolSetPoint));
+                info.coolSchName = ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleCoolSetPoint);
                break;
            case HVAC::ThermostatType::SingleHeating:
-                PreDefTableEntry(
-                    state, orp->pdchStatSchdCoolName, tcz.ZoneName, ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleHeatSetPoint));
+                info.heatSchName = ScheduleManager::GetScheduleName(state, tcz.SchIndx_SingleHeatSetPoint);
                break;
            }
+            infos.emplace_back(std::move(info));
+        }


OK this is nicer looking.

Myoldmopar · 2025-01-10T19:24:12Z

src/EnergyPlus/ZoneTempPredictorCorrector.cc

+        PreDefTableEntry(state, orp->pdchStatSchdType1, tcz.ZoneName, joinStrings(infos, &ControlTypeInfo::thermostatType));
+        PreDefTableEntry(state, orp->pdchStatSchdTypeName1, tcz.ZoneName, joinStrings(infos, &ControlTypeInfo::controlTypeName));
+        if (auto heatSchNames = joinStrings(infos, &ControlTypeInfo::heatSchName); !heatSchNames.empty()) {
+            PreDefTableEntry(state, orp->pdchStatSchdHeatName, tcz.ZoneName, heatSchNames);
+        }
+        if (auto coolSchNames = joinStrings(infos, &ControlTypeInfo::coolSchName); !coolSchNames.empty()) {
+            PreDefTableEntry(state, orp->pdchStatSchdCoolName, tcz.ZoneName, coolSchNames);


Got it. Great.

…SummaryThermostats

Myoldmopar · 2025-01-10T19:44:35Z

I addressed the Clang format thing and pushed it up. I will go ahead and let the Code Integrity check finish but I don't plan on waiting too long on this.

Myoldmopar · 2025-01-10T20:14:32Z

Well the docs are failing due to a MikTeX timeout. I tried re-running it, but it did the same thing. Ignoring it for now... otherwise this is clean. I will go ahead and get this merged to avoid wasting CI cycles on it. Thanks @jmarrec !

github-actions · 2025-01-10T20:33:06Z

⚠️ Regressions detected on macos-14 for commit `fd879cf`

Regression Summary

Table String Diffs: 308
Audit: 304

JasonGlazer · 2025-01-10T20:42:56Z

Thanks @jmarrec for fixing this and your review @Myoldmopar!

jmarrec added 5 commits December 17, 2024 10:57

#10857 - Existing unit test is broken for SingleHeating/SingleCooling…

cf934f5

…: schedule reported the opposite #10857 (comment)

#10857 - Fix SingleHeating/SingleCooling: schedule reported the opposite

f823493

Add a test for #10857, assuming we join with ", "

74dca14

FIx #10857 - Join multiple Control Types & Schedules for ZoneControl:…

8015564

…Thermostat with ", "

Adjust test for #10857 - Seems like a consistent order was warranted …

f6c38b8

…no matter the order in which Tstat controls are declared

jmarrec added the Defect Includes code to repair a defect in EnergyPlus label Dec 17, 2024

jmarrec self-assigned this Dec 17, 2024

jmarrec force-pushed the 10857_ReportSystemSummaryThermostats branch from 2bdd43a to c6f493a Compare December 17, 2024 14:08

#10857 - Make it declaration-order independent

15fc6e5

jmarrec force-pushed the 10857_ReportSystemSummaryThermostats branch from c6f493a to 15fc6e5 Compare December 17, 2024 14:18

jmarrec commented Dec 17, 2024

View reviewed changes

Myoldmopar approved these changes Jan 10, 2025

View reviewed changes

Myoldmopar added 2 commits January 10, 2025 13:26

Merge remote-tracking branch 'origin/develop' into 10857_ReportSystem…

fd20998

…SummaryThermostats

Clang format

8e13be2

Myoldmopar merged commit 31e3c33 into develop Jan 10, 2025
5 of 6 checks passed

Myoldmopar deleted the 10857_ReportSystemSummaryThermostats branch January 10, 2025 20:14

		EXPECT_EQ("SINGLEHEATINGSCH", RetrievePreDefTableEntry(*state, orp.pdchStatSchdHeatName, "zoneA"));
		EXPECT_EQ("NOT FOUND", RetrievePreDefTableEntry(*state, orp.pdchStatSchdCoolName, "zoneA"));

		EXPECT_EQ("NOT FOUND", RetrievePreDefTableEntry(*state, orp.pdchStatSchdHeatName, "zoneB"));
		EXPECT_EQ("SINGLECOOLINGSCH", RetrievePreDefTableEntry(*state, orp.pdchStatSchdCoolName, "zoneB"));

Conversation

jmarrec commented Dec 17, 2024

Pull request overview

Pull Request Author

Reviewer

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jmarrec Jan 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Dec 17, 2024

⚠️ Regressions detected on macos-14 for commit f35325f

Uh oh!

github-actions bot commented Dec 17, 2024

⚠️ Regressions detected on macos-14 for commit 7b68cb9

Uh oh!

github-actions bot commented Dec 17, 2024

⚠️ Regressions detected on macos-14 for commit 8397ca6

Uh oh!

nrel-bot-2c commented Dec 25, 2024

Uh oh!

nrel-bot-2 commented Jan 2, 2025

Uh oh!

nrel-bot-2 commented Jan 10, 2025

Uh oh!

Myoldmopar left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Myoldmopar commented Jan 10, 2025

Uh oh!

Myoldmopar commented Jan 10, 2025

Uh oh!

Uh oh!

github-actions bot commented Jan 10, 2025

⚠️ Regressions detected on macos-14 for commit fd879cf

Uh oh!

JasonGlazer commented Jan 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

jmarrec Jan 14, 2025 •

edited

Loading

⚠️ Regressions detected on macos-14 for commit `f35325f`

⚠️ Regressions detected on macos-14 for commit `7b68cb9`

⚠️ Regressions detected on macos-14 for commit `8397ca6`

⚠️ Regressions detected on macos-14 for commit `fd879cf`