ZoneBaseboard:OutdoorTemperatureControlled autosizing is missing

[joseph-robertson]

Pull request overview

• Fixes ZoneBaseboard:OutdoorTemperatureControlled autosizing is missing #5344
• Reviving code from 65676922 pnnl autosizing #4236, which got left behind.

Description of the purpose of this PR

Pull Request Author

• Title of PR should be user-synopsis style (clearly understandable in a standalone changelog context)
• Label the PR with at least one of: Defect, Refactoring, NewFeature, Performance, and/or DoNoPublish
• Pull requests that impact EnergyPlus code must also include unit tests to cover enhancement or defect repair
• Author should provide a "walkthrough" of relevant code changes using a GitHub code review comment process
• If any diffs are expected, author must demonstrate they are justified using plots and descriptions
• If changes fix a defect, the fix should be demonstrated in plots and descriptions
• If any defect files are updated to a more recent version, upload new versions here or on DevSupport
• If IDD requires transition, transition source, rules, ExpandObjects, and IDFs must be updated, and add IDDChange label
• If structural output changes, add to output rules file and add OutputChange label
• If adding/removing any LaTeX docs or figures, update that document's CMakeLists file dependencies
• If adding/removing any output files (e.g., eplustbl.*)
  • Update ..\scripts\Epl-run.bat
  • Update ..\scripts\RunEPlus.bat
  • Update ..\src\EPLaunch\ MainModule.bas, epl-ui.frm, and epl.vbp (VersionComments)
  • Update ...github\workflows\energyplus.py

Reviewer

• Perform a Code Review on GitHub
• If branch is behind develop, merge develop and build locally to check for side effects of the merge
• If defect, verify by running develop branch and reproducing defect, then running PR and reproducing fix
• If feature, test running new feature, try creative ways to break it
• CI status: all green or justified
• Check that performance is not impacted (CI Linux results include performance check)
• Run Unit Test(s) locally
• Check any new function arguments for performance impacts
• Verify IDF naming conventions and styles, memos and notes and defaults
• If new idf included, locally check the err file and other outputs

[github-actions]

⚠️ Regressions detected on ubuntu-24.04 for commit 1993c6e

Regression Summary

• Audit: 3
• EIO: 3
• Table Big Diffs: 3
• ESO Big Diffs: 1
• MTR Big Diffs: 1
• ZSZ Big Diffs: 1
• Table String Diffs: 1

• View Results
• Download Regressions

[github-actions]

⚠️ Regressions detected on macos-14 for commit 1993c6e

Regression Summary

• Audit: 3
• EIO: 3
• Table Big Diffs: 3
• ESO Big Diffs: 1
• MTR Big Diffs: 1
• ZSZ Big Diffs: 1
• Table String Diffs: 1

• View Results
• Download Regressions

[joseph-robertson]

Does it seem like InternalHeatGains.scc is the appropriate place nowadays to put autosizing code for this object? The code pre-dates much refactor work (e.g., state).

@rraustad

[rraustad]

What original code? I don't see any code that was deleted. I think == was used to determine when all design days have simulated (i.e., components don't usually size until zone sizing is complete). But each design day has multiple time steps so just looking at the CurEnvirNum isn't enough to know that sizing has completed. Most sizing routines are not called until !state.dataGlobal->SysSizingCalc. This does seem weird in that state.dataEnvrn->OutDryBulbTemp is set by the weather manager each time step, so this code is capturing the last time step's OAT in each specific design day. Not what I would expect. Also, at line 6926 below it's looking for max OAT not the min (i.e., if (MinDesOutTemp > DesDayOutDryBulbTemp(Loop))). Too much to discuss in a comment.

[joseph-robertson]

Sorry, I was just referring to the original code in #4236.

I tried introducing !state.dataGlobal->ZoneSizingCalc in d994859. It brings the InitInternalHeatGains call down from "Initializing Internal Heat Gains" to "Initializing Simulation", which I think aligns with the other baseboard type.

From what I can tell the code is permitting input of a design zone heating setpoint (high temperature), but then looking to design day (days?) for a low temperature? But as you point out, looking at state.dataEnvrn->OutDryBulbTemp which would be the design day's last timestep's OAT; is there a precendence for this kind of weather info gathering, or why couldn't low temperature just be defaulted/input like high temperature?

I'll dig around and see how infiltration and ventilation MCPI and MCPV are used in other places.

[rraustad]

What would typically happen in a sizing routine is the component would look to FinalZoneSizing data for information needed for sizing (which means you don't need to gather data as done here with DesDayOutDryBulbTemp(ScannedEnvirNum)). In this case it would be FinalZoneSizing(zn).OutTempAtHeatPeak but using that data would need to be tested to make sure the size of the baseboard was sufficient to meet the peak baseboard load. For example, what is the total infiltration and ventilation load at the peak heating timestep? Is there a time where infiltration and ventilation would be larger and therefore the baseboard would not have sufficient capacity to meet the load? There is also an array of this same data using the min of CalcFinalZoneSizing(zn).HeatOutTempSeq(ts) which would give the minimum OAT for the peak heating design day. There are always questions of this nature regarding which sizing data is appropriate for component sizing (e.g., the peak heating load may not correspond to the peak infiltration or ventilation load).

[rraustad]

Does it seem like InternalHeatGains.scc is the appropriate place nowadays to put autosizing code for this object? The code pre-dates much refactor work (e.g., state).

@rraustad

The BaseBoards do have a size function, but this object is managed in InternalHeatGains, for whatever reason. Sizing is typically called from the init function with proper protection to ensure it is called after sizing completes. So this does seem OK since it's called from InitInternalHeatGains. For zone equipment the protection could use !state.dataGlobal->ZoneSizingCalc (where FinalZoneSizing is complete and available) but most components wait for all sizing to complete.

void InitBaseboard()

    if (!state.dataGlobal->SysSizingCalc && baseboard->baseboards(BaseboardNum).MySizeFlag ) {
        // for each coil, do the sizing once.
        SizeElectricBaseboard(state, BaseboardNum);
        baseboard->baseboards(BaseboardNum).MySizeFlag = false;
    }

So this new code does call a sizing function, it's called from init in the code that manages the object, and the sizing call should be protected to only call the new size function after sizing is complete. Using !OutTempScanNotDone as protection could work as intended, since this appears to only be interested in design day OAT and surface properties, but it doesn't look to me as if that's the case. Also, infiltration and ventilation MCPI and MCPV are also time step variables so something else will need to be used to get the peak of those data.