Expand Series Active Branch Logic in SetComponentFlowRate

[EnergyArchmage]

Pull request overview

• Fixes #ISSUENUMBERHERE (IF THIS IS A DEFECT)
• Draft, suggested fix.
• Revise worker routine SetComponentFlowRate to include added logic related to series-active branches. Do not always make a zero flow request when a series active branch already has flow. Should correct plant model that are not including series active logic in a single, central place in code.

NOTE: ENHANCEMENTS MUST FOLLOW A SUBMISSION PROCESS INCLUDING A FEATURE PROPOSAL AND DESIGN DOCUMENT PRIOR TO SUBMITTING CODE

Pull Request Author

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

• 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

Reviewer

This will not be exhaustively relevant to every PR.

• 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 macos-14 for commit e0f9212

Regression Summary

• EIO: 15
• ESO Big Diffs: 13
• MTR Big Diffs: 4
• Table Big Diffs: 11
• Table String Diffs: 6
• MTR Small Diffs: 6
• ERR: 8
• ESO Small Diffs: 6
• Table Small Diffs: 4

• View Results
• Download Regressions

[mjwitte]

@EnergyArchmage What about downstream components on a series active branch. For example, 2 chillers in series, the first chiller is off, but the second chiller is on. How does the first chiller find out there should be flow on the branch?

[EnergyArchmage]

That situation is the main point the change is trying to address. The beginning iteration there isn't any flow yet, so yes, the first chiller is off and doesn't see any flow on the node. But the next iteration, the second chiller will come on and make a flow request, and if flow gets going then the first chiller will see flow on the node. The idea is for the first chiller to not keep requesting zero flow even when there is flow. That zero request seems to set up a fight between a zero flow request and some flow and isn't helpful when we know there is already flow. Series active branches are supposed to look at the last node on the branch but it seems that design is not completely implemented and mismatched flow requests on upstream nodes can cause problems, like more iterations before things settle down.

[rraustad]

Why not use if (comp.FlowCtrl == DataBranchAirLoopPlant::ControlType::SeriesActive) on line 152 and comp.NodeNumIn on line 153

CompData &CompData::getPlantComponent(EnergyPlusData &state, PlantLocation const &plantLoc)
{
    return state.dataPlnt->PlantLoop(plantLoc.loopNum).LoopSide(plantLoc.loopSideNum).Branch(plantLoc.branchNum).Comp(plantLoc.compNum);
}

[EnergyArchmage]

It wasn't clear to me if that "comp" is a real pointer

[mjwitte]

@EnergyArchmage Ran local annual regressions (with minimum hourly reporting). Files with large mtr and/or table diffs:

5ZoneAirCooled_RunaroundHeatRecovery - pump electricity has doubled
5ZoneBranchSupplyPumps - pump elec +3.8%
ASHRAE901_OfficeLarge_STD2019_Denver - pump elec +5%
ASHRAE901_OfficeLarge_STD2019_Denver_Chiller205 - pump elec +5%
ASHRAE901_OfficeLarge_STD2019_Denver_ChillerEIR - pump elec +5%
ASHRAE901_OfficeLarge_STD2019_Denver_Chiller205_Detailed - pump elec +5%
CoolingTowerWithWBDeltaTempOp - cooling elec +3%
ASHRAE901_Hospital_STD2019_Denver - pump elec +17%, cooling elec +1.4%
IceStorage-Parallel - heat reject elec -1%
IceStorage-Series-ChillerDownstream - heat reject and cooling elec -<1%
HospitalLowEnergy - big diffs are all <2%, no big diffs in ABUPS
WaterSideEconomizer_Integrated - cooling diesel and heat reject water -1.3%
_BranchPumpsWithCommonPipe - pump elec +35%, district heat -5%

So, the general trend is an increase in pump power, some files by a lot. I guess that's what you would expect, but I haven't looked at any detailed hourly results yet to see what's happening. That's next.

[mjwitte]

For 5ZoneAirCooled_RunaroundHeatRecovery, the number of hours that HR CIRC PUMP is running has gone from 2230 to 6963. There are a few random hours where one HR coil shows a load and the other doesn't (e.g. 01/07 08:00-09:00, 01/08 7-9, 02/06 7-9, 02/07 7-9, and more. Seems like the pump should be off for these hours?

Hmm, but with develop for these same hours, the HR pump shows mass flow, but the HR coils both show zero flow and zero output, and zero flow at the HR demand outlet, so the loop's not balanced with develop for those hours.

[EnergyArchmage]

For 5ZoneAirCooled_RunaroundHeatRecovery

I have been plotting detailed frequency results and am not seeing any problems in the reference (develop) case. But something is going wrong with this code change where flow is staying on too often in the heat recovery loop. I am not very familiar with the run around loop implementation so haven't gotten very far. But I am not sure series-active branch control type was intended to apply to two demand coils on the same branch, it is more for supply side equipment. So may have to look at how series-active gets set for this case .