EnergyPlus does not update the radiative temperature

[mwetter]

The plot below is from Buildings.ThermalZones.EnergyPlus.Validation.OneZoneInitialTemperature.

TRad.y and zon.TRad should both start at the average surface temperature. This looks like EnergyPlus ignores the initial temerature for the warmup.

The branch is issue1954_spawn_TRad

[mwetter]

@kbenne : Could you easily solve this, or shall I look for a work-around and change the model(s). I would think this is already available as an output variable in E+.

[kbenne]

I think I can solve it easily. This is the next thing I will be working on.

[kbenne]

There is another input "QGaiRad_flow" that is not currently supported by the EnergyPlus FMU. @mwetter do you want to address that now also?

[Helarga]

@kbenne

[kbenne]

@mwetter this is the result after applying https://github.com/NREL/Spawn/commit/b01f0d448bc68c125c4350fe82cc08e90392e9bf. Thank you for testing @Helarga.

@mwetter this addresses the easy part which is adding the zon.TRad output. There is a more difficult aspect to this related to that startup transient. I believe the initial TRad which is around 18C is in fact the average inside surface temperature computed by EnergyPLus. You may ask why the inside surface temperature is not the same as the zone air temperature. Well. It is cold outside, it is warm inside (30C I believe is the starting input zone T). Recall the description about how warmup is currently working. Critically, we are using the traditional EnergyPlus criteria to exit warmup, which is based on finding periodic steady state of the zone temperature. For Spawn's connected zones the initial zone temp is a fixed input so warmup convergence is hit almost immediately. I would like to consider a separate issue to improve the warmup criteria for Spawn such that it is based on finding a periodic steady state for internal wall temperature instead of zone air temperature.

Spawn Warmup In Spawn there can be both connected and unconnected zones defined in the EnergyPlus input file. The key difference is that connected zones have a corresponding zone model defined in Modelica that facilities communication between the EnergyPlus based zone heat balance model and the Modelica based control and HVAC system models. Unconnected zones are unconditioned spaces which are defined entirely within the EnergyPlus input file, and for these zones the conventional EnergyPlus algorithms are used to simulate the zone conditions, including the air temperature and humidity. In contrast connected zones generally have HVAC and control systems defined in Modelica, and the zone air temperature and humidity is not managed by the conventional EnergyPlus algorithms, but instead by a Modelica based algorithm. During the initialization of a new simulation it is necessary to compute beginning values for the zone air conditions as well as the conditions of any thermal mass within the building’s walls. Conventionally, EnergyPlus handles this requirement using a warmup period, and in Spawn the traditional EnergyPlus warmup algorithm is employed to initialize unconnected zones. The EnergyPlus warmup algorithm is described in the EnergyPlus Engineering Reference, https://bigladdersoftware.com/epx/docs/9-3/engineering-reference/warmup-convergence.html#warmup-convergence, and summarized in the following steps.

1. Zone and wall surface temperatures are initialized to 23C
2. Zone humidity ratios are initialized to the outdoor conditions
3. During warmup, the outdoor conditions are determined by the EnergyPlus weather file
4. The first day of the simulation is repeated until warmup convergence, which occurs when the minimum and maximum air temperatures during the warmup day remain nearly the same between two successive iterations

Spawn initializes unconnected zones using the warmup algorithm that was just described, however connected zones are treated differently than in a conventional EnergyPlus simulation, because initial zone air properties are predefined in the Modelica zone model. During Spawn warmup the following steps occur.

1. All wall surface temperatures are initialized to 23C just as they are in a conventional EnergyPlus warmup period, however as in EnergyPlus during the first and subsequent warmup iterations the exterior walls will be subject to the ambient conditions defined by the weather file, therefore exterior surface temperatures will not remain fixed at their 23C initial condition during the warmup process. Similarly, internal wall surfaces will be exposed to the zone air temperature therefore internal surfaces shall approach a quasi-steady state at the conclusion of warmup and will not remain at the initialized value.
2. The air temperatures of unconnected zones are initialized to 23C
3. The humidity ratios of unconnected zones are initialized to the outdoor conditions
4. The air temperatures and humidity ratios of connected zones are initialized to the initial values defined in Modelica, and held fixed during the warmup period
5. During warmup, the outdoor conditions are determined by the EnergyPlus weather file in the same way as a conventional EnergyPlus simulation.
6. The first day of the simulation is repeated until the minimum and maximum air temperatures during the warmup day remain nearly the same between two successive iterations.

The Spawn warmup procedure is still invoked even if there are no unconnected zones defined in the model, however in this case the warmup convergence criteria will be met after only two iterations of the warmup day because all zone temperature and humidity values are fixed to the initial values defined in Modelica. It is possible for startup transients to still exist after Spawn warmup due thermal mass in the wall materials not being fully “soaked” by the initial boundary conditions defined by the outdoor environment and the initial zone air conditions. A future enhancement may define a new warmup convergence criteria that takes into account the internal wall temperature.

[mwetter]

@kbenne : Yes, QGaiRad_flow should be supported for the simulation to be correct.

[mwetter]

Thanks for the description. I will integrate it into the users' guide.

[kbenne]

The binary with this change is already posted

[mwetter]

@kbenne This change being QGaiRad_flow or the output of TRad?

[kbenne]

Trad

[kbenne]

@mwetter I'm reviewing possible implementations to support the input QGaiRad_flow. Can you describe the intended use case a little bit? There are many sources of radiant heat gain within EnergyPlus and how I implement and which variables I connect to will impact how it is reported in the EnergyPlus output. EnergyPlus has accounting for the radiant heat contribution from wall surfaces, as well as from various types of equipment and internal loads. I'm debating hooking into something existing versus maybe adding a new term along the lines of "Radiant heat gain from spawn."

[mwetter]

It should behave as if it were a long wave radiant heat gain from equipment (or people, which physically is the same in E+ I believe). A typical use case is that these heat gains are modeled in Modelica, but as they are distributed to the room-facing surfaces, they need to be fed into the E+ zone model. From a usability point of view, they should not be added to the report variable of say equipment heat gain; because a user may specify some in E+ and some GGaiRad_flow in Modelica. E+ should just add them when it writes them to the room-facing surfaces.

[kbenne]

@mwetter I have added support for QGaiRad_flow in the commit referenced above. I have verified that the input is available and that the simulation completes successfully, but I have not confirmed the results of using this input. I will ask @Helarga to demonstrate this feature and confirm that it is functioning correctly.

[kbenne]

@mwetter do you have a validation model that demonstrates GGaiRad_flow?

[mwetter]

@kbenne : All models in Buildings.ThermalZones.EnergyPlus.Validation have a block called qRadGai_flow that you can use to set a non-zero value during testing.

[kbenne]

can you give a link?

[mwetter]

Just open any model in Buildings.ThermalZones.EnergyPlus.Validation on branch issue1954* and you will see the block called qRadGai_flow in the schematic view.

On Mon, Oct 26, 2020, 4:23 PM Kyle Benne notifications@github.com wrote:

can you give a link?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lbl-srg/modelica-buildings/issues/1954#issuecomment-716878040, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKEPODRXPCB46ST22SAHTDSMYAFLANCNFSM4NFGRDIQ .

[kbenne]

alright I think I see how it works. slightly different topic but related to why I asked you for a link. You have rearranged the structure slightly in the validation cases. Can you merge issue1129_energyplus_zone (aka spawn develop) into the issue1954* branch? I think you will see a tiny merge conflict in the package.order file.

I'm working from issue1129_EP_9_4 which is current with issue1129_energyplus_zone but with the necessary idf updates for 9.4. It would be helpful to have issue1954 current as well. It is a bit stale.

[mwetter]

@kbenne : I updated the branch issue1954_spawn_TRad with issue1129_energyplus_zone and moved the test case Buildings.ThermalZones.EnergyPlus.Validation.OneZoneInitialTemperature to Buildings.ThermalZones/EnergyPlus/Validation/ThermalZone/ZoneTemperatureInitialization.

[kbenne]

Not sure if this is conclusive or not, but here are a couple of results. One with a constant 5 W/m2 radiant heat gain and another with a sinusoidal 5 W/m2. The curve "radHeatPerAreaOutput" corresponds to the EnergyPlus output "Zone Total Internal Radiant Heating Rate".

[kbenne]

@mwetter when you are ready you are going to need new spawn libraries to evaluate the changes for this, and for the Windows fix. I have not published them because they are based on EnergyPlus 9.4. You're going to need the changes on https://github.com/lbl-srg/modelica-buildings/tree/issue1129_EP_9_4 which has updated idf files.

[mwetter]

@kbenne : The magnitude looks good, assuming you can explain the wiggle in the blue line. But it looks like there is a time shift. The output should not be shifted, e.g., see https://lbl-srg.github.io/soep/softwareArchitecture.html#retrieving-output-variables-from-energyplus in particular:

[kbenne]

The above graphs show the total radiant gain on the output side, not just the gain added as input from Modelica. There are other sources of radiant heat in this model. For the type of comparison you are talking about it is better to show an output variable corresponding to just the radiant load added by Modelica. Here is that.

[mwetter]

@kbenne : To update to the new E+ binary, which route do you suggest? Shall we

1. Test them on https://github.com/lbl-srg/modelica-buildings/tree/issue1129_EP_9_4,
2. Then address https://github.com/lbl-srg/modelica-buildings/issues/1954 and then
3. https://github.com/lbl-srg/modelica-buildings/issues/2132 or do you suggest an other order?

And when do you think the binaries are ready to be pulled down and tested, which will probably take me a few hours total.

[kbenne]

The commits that address #1954 and #2132 are already in the https://github.com/lbl-srg/modelica-buildings/tree/issue1129_EP_9_4 branch. I would just work from that branch.

I published binaries earlier today.