Feature enhancement of BuildingTimeSeries

[AntoineGautier]

The feature branch is issue2302_timeSeries.

This issue will address the following:

• Provide a generic formulation suited for loads at the ETS level or computed by decoupled whole-building simulations (e.g., EnergyPlus), see below for the detailed requirements.
• Compute the scaling parameters in BuildingTimeSeries based on the peak loads.
• Relocation of BuildingTimeSeries (currently under DHC/Loads/Examples/BaseClasses) and proper documentation so that the model can be used as a generic model from now on.
• Allow for specifying a recirculation flow rate at minimum pump speed in Buildings.Experimental.DHC.Loads.FlowDistribution.
• Use signed real values for nominal heat flow rates and Delta-T.
• Bug fix in PartialTerminalUnit, see https://github.com/lbl-srg/modelica-buildings/pull/2269#issuecomment-741963606: This is no more a bug as the scaling mechanism implemented in #2291 is now consistent with the former option have_scaLoa=true. See the documentation of PartialTerminalUnit for a precise description.

Requirements for a generic formulation of the coupling with time series

1. The refactoring must allow for using either

   • mass flow rate and Delta-T,

     • this should be the preferred option for a loose coupling with URBANopt-SDK EnergyPlus simulation. TODO: further specify the modeling requirements on the SDK side, cf. feedback from Christopher Mackey

       Some of the ~80 HVAC templates (within the openstudio-standards gem, see https://docs.google.com/document/d/1xg20cckHsQ6s0z4QUEodQIko9SDK41ejyNezXnBfMDY/edit) have district heating/cooling while others do not. So the ability to integrate with DHC is going to be on a template-by-template basis.

       We are not currently using the building-level key for HVAC templates in our exported geoJSONs because we are exposing the ability to assign these HVAC templates to different portions of a building within our own honeybee schema JSONs that are referenced by this geoJSON. So, if you want to build something that works from the name of the HVAC template and the vintage of it (eg. ASHRAE 90.1 2013) as you see in the geoJSON schema, we should still be able to get it to work from either the geoJSON schema or the honeybee JSON schema with a little work. Maybe it's just that I write some code that makes the whole building have one HVAC if we are using the DHC workflows (ignoring the systems with the smallest footprint) or we make an option in the geoJSON schema to specify a list of HVAC templates instead of a single HVAC for the whole building. In any case, if you need more detail than just the name of the HVAC template, you will have to start from the OSM or IDF. Otherwise, we should find a way to make it work from JSON/geoJSON.

   • or change in enthalpy flow rate.

     • In case of a cooling load, it must correspond to the total load (latent + sensible). TODO: validate this requirement as it is currently not compatible with https://github.com/urbanopt/openstudio-prototype-loads that provides only the sensible load. More often than not, data available from BEM correspond to sensible load (at the room level).

2. An ETS model shall be used systematically for interfacing with the DHC system model.

   • So the interface of the model shall remain consistent with the PartialEnergyTransferStation and PartialBuilding base classes currently on the master.

   • This also implies that the coupling mechanism must provide a fluid stream characterized by its flow rate and return temperature to the ETS.

     • We could use an exponential correlation between the load and the mass flow rate, which coefficients get assigned based on the building type, climate and standard from https://github.com/urbanopt/openstudio-prototype-loads (the coefficient identification being done independently and the coefficients provided in a static resource file). Using this database also provides a means to quantify the standard error of the correlation approach. TODO: check compatibility with template and building_type in https://docs.urbanopt.net/urbanopt-geojson-gem/schemas/building-properties.html. What about system_type?
       • QUESTIONS to @nllong: do the templates represent variable flow distribution systems (two-way valves at terminal units and variable speed pump) or rather constant flow (three-way valves and constant speed pump)? It is possible to update the measure and add the mass flow rate, supply and return temperatures of chilled water and heating hot water in a new directory?

3. The requirement regarding how the actual heating or cooling capacity is computed pertain to the ETS models, they are out scope for this development. However, the issue of the steady-state coupling must be addressed, i.e., if the time series load cannot be met transiently by the ETS (for instance because of the dynamics of a control loop, valve, pump, fluid transport delay, etc.) how to integrate this mismatch so that on an averaged time basis the load is met or a warning is issued if it indeed exceeds the system capacity.

   • Include an assert statement to check that the load is met and output a violation rate (if using a moving average, check the impact on simulation time).
   • We could include a correction of the correlation between Q_flow and m_flow based on the difference between the set point and the actual supply temperature.

4. The refactoring must be compatible with all ETS layouts:

   • Direct or indirect connection
   • In-building pumping or not (so the flow rate should be imposed either by a mover or a variable flow resistance such as the pressure-independent valve model).

5. The refactoring should provide an option for a simpler (and more computationally efficient) modeling approach of the in-building systems that serve the loads, considering that

   • the corresponding states currently dominate the error in DHC simulations, see https://github.com/lbl-srg/modelica-buildings/issues/1769#issuecomment-780937436,
   • the current modeling approach may require some PI tuning.

6. The power drawn by in-building distribution pump motors is not computed.

[Helarga]

The timeSeries model refactor will close

https://github.com/lbl-srg/modelica-buildings/issues/2201

https://github.com/lbl-srg/modelica-buildings/issues/2202

[dhblum]

After discussion with @AntoineGautier this issue will focus on bullet 2 of the initial comment: "Compute the scaling parameters in BuildingTimeSeries based on the peak loads." It will do this by:

In BuildingTimeSeries:

• make facMul=1 and final since it is not used and inherited from Buildings.Experimental.DHC.Loads.BaseClasses.PartialBuilding.
• add scaling of facMulHea and facMulCoo based on Q_flow nominals for each (but don't make final). For this, use expressions in BuildingTimeSeriesWithETS. Then, let BuildingTimeSeriesWithETS use defaults.