Issue2180 boiler plant main controller oct 2021

[mwetter]

This replaces #2685

@JayHuLBL @karthikeyad-pnnl: Please make sure this contains the changes from #2685

Note that this is on a branch with the new name issue2180_BoilerPlant_MainController_oct_2021 to distinguish it from the old branch issue2180_BoilerPlant_MainController (whose changes are on this branch too).

I essentially did the following:

 git checkout -b karthikeyad-pnnl-issue2180_MainBoilerPlantController issue2180_BoilerPlant_MainController
 git checkout -b issue2180_BoilerPlant_MainController
 git pull
 git branch --set-upstream-to=origin/issue2180_BoilerPlant_MainController issue2180_BoilerPlant_MainController
 git pull
 git diff --name-only origin/master
 git checkout -b karthikeyad-pnnl-issue2180_MainBoilerPlantController issue2180_BoilerPlant_MainController
 git pull https://github.com/karthikeyad-pnnl/modelica-buildings.git issue2180_MainBoilerPlantController
 git checkout issue2180_BoilerPlant_MainController
 git merge --no-ff karthikeyad-pnnl-issue2180_MainBoilerPlantController
 git diff --name-only origin/master
 git checkout -b issue2180_BoilerPlant_MainController_oct_2021
 git diff --name-only origin/master
 git push --set-upstream origin issue2180_BoilerPlant_MainController_oct_2021

[JayHuLBL]

@karthikeyad-pnnl These plots are missing.

[JayHuLBL]

@karthikeyad-pnnl I corrected the html errors, but did not get chance to check if all the changes from #2685 are included here. At least I noticed some images are missing.

[karthikeyad-pnnl]

@karthikeyad-pnnl Putting more thought into the validation model, I think the load model should be revisited and that the heating heat flow rate should be tracked, rather than the HW mass flow rate. The reason is that, contrary to the chiller plant, there is no ∆p reset for the boiler plant, only a supply temperature reset. So, at low load, the control intent is to reset down the HWST to maximize the opening of the terminal control valves. Controlling for a mass flow rate taken from another simulation makes little sense because, as you noticed, at low load the plant gets disabled because the terminal control valves close. If you switch to using, e.g., an explicit radiator model and track the heating heat flow rate, the HWST reset at low load keeps the control valve more open and the simulation exhibits the actual control intent, which is to operate at low temperature and high flow rate. The plant only gets disabled at zero load. I've quickly tested this in https://github.com/AntoineGautier/modelica-buildings/tree/tmp/issue3266_template_HW_plant: please have a look and let me know what you think.

Can you also rename the validation model into Guideline36, or at least suppress Test from the model name?

Also, can you change the size of the plots to match the one of other validation models in the library? Below is how the plots are displayed on a my system.

As for the merge conflicts, best is to resolve them locally by merging `issue2180_BoilerPlant_MainController_oct_2021` into your development branch. (When doing that, and since there has been a lot of back and forth during this development, it's usually useful to check all the files that differ from the master branch and do some necessary cleaning.)

@AntoineGautier Thanks for pointing out the load baseclass in the HydronicConfigurations package. I was able to get the described behavior at low-load conditions. I have also made the other requested changes on #4319. Please review them when you get a chance. Thanks!

[AntoineGautier]

That looks good.
I've updated the load model and reference results.

• It would be good to understand and eliminate the warnings below — non blocking though

  Warning: The following was detected at time: 86400
  In Guideline36.conBoiPri.staSetCon.staDow.extIndSig: The extract index is out of the   range.
  With: index=0
  Failed condition: conBoiPri.staSetCon.staDow.extIndSig.index > 0 and conBoiPri.staSetCon.staDow.extIndSig.index <= 3
  

• Could you fix the CI tests issues

And that would be ready!

[karthikeyad-pnnl]

That looks good. I've updated the load model and reference results.

• It would be good to understand and eliminate the warnings below — non blocking though

  Warning: The following was detected at time: 86400
  In Guideline36.conBoiPri.staSetCon.staDow.extIndSig: The extract index is out of the   range.
  With: index=0
  Failed condition: conBoiPri.staSetCon.staDow.extIndSig.index > 0 and conBoiPri.staSetCon.staDow.extIndSig.index <= 3
  

• Could you fix the CI tests issues

And that would be ready!

@AntoineGautier I have summarized the information about the multiple warnings below. It has to do with the use of the RealExtractor block in the various control modules. When the modules were being setup, the design relied on the then-existing parameter to define the output when the index was outside a pre-defined set of bounds. The feature was primarily used in calculations related to the plant and pump staging by outputting a zero signal when the plant was disabled, indicated by stage 0 (this is a placeholder and not related to the other discussion about stage 0 operation in the boiler plant). Once the feature was removed from the CDL block, the various modules were refactored to restore the previous functionality with the use of the Buildings.Controls.OBC.ASHRAE.G36.Plants.Boilers.Generic.ZeroIndexCorrection block as required. The warnings persist in the latest implementation of the RealExtractor block, and their root cause is summarized below. During the refactoring process, the modules' performance was verified to ensure no impact on design intent.

Instance	Time instances when issue is reported (Each instance reported is when unique state is achieved for the signal. Not exhaustive)	Index input signal	Root cause
conBoiPri.minBoiFloSet1[3].extIndSig4 index > 0 and index <= 3	86400	Staging setpoint+1	Signal is constantly 4 because flow setpoint is calculated for next higher stage (in this case stage-4 doesn't exist and impact calculations)
conBoiPri.staSetCon.staDow.extIndSig index > 0 and index <= 3	86400; 89019.32597823304; 91717.65026802519; 94163.49447427988; 169693.3543601964; 256052.8632797867	Staging setpoint	Signal is 0 when plant is disabled
conBoiPri.upProCon.hotWatSupTemRes.extIndSig index > 0 and index <= 3	86400; 88833.32597823304; 91531.65026797933; 93977.4944742799; 169507.3543601116; 255866.8632797867	Staging setpoint	Signal is 0 when plant is disabled
conBoiPri.hotWatSupTemRes.extIndSig index > 0 and index <= 3	86400; 88833.32597823304; 91531.65026797933; 93977.4944742799; 169507.3543601116; 255866.8632797867	Staging setpoint	Signal is 0 when plant is disabled
conBoiPri.staSetCon.staDow.extIndSig1 index > 0 and index <= 3	86400; 89019.32597823304; 91717.65026802519; 94163.49447427988; 169693.3543601964; 256052.8632797867	Staging setpoint	Signal is 0 when plant is disabled
conBoiPri.priPumCon.lasLagPum index > 0 and index <= 2	86400; 89016.32597823306; 91714.65026797933; 94160.4944742799; 169690.3543601116; 256049.8632799148	No. of pumps enabled	Signal is 0 when all primary pumps are disabled
conPumSec2.nexLagPum index > 0 and index <= 1	87304.50000004354; 89737.82597827794; 92436.15026797939; 94881.99447432737; 188813.3519835187	No. of pumps enabled+1	Signal is 2 when secondary pump is enabled
conPumSec1.nexLagPum index > 0 and index <= 1	87304.50000004354; 89737.82597827794; 92436.15026797939; 94881.99447432737; 188813.3143210534	No. of pumps enabled+1	Signal is 2 when secondary pump is enabled
conBoiPri.priPumCon.nexLagPum index > 0 and index <= 2	104342.4372401533; 105726.5416235401; 107711.8596648953; 121963.1802918463; 124652.6738330294; 195804.6139936947; 196988.4998158395; 198981.9686468744; 201077.8358555062; 203884.0470173713	No. of pumps enabled+1	Signal is 3 when all primary pumps are enabled