.Buildings.ThermalZones.EnergyPlus_9_6_0.ThermalZone

Information

Model for a thermal zone that is implemented in EnergyPlus.

This model instantiates the FMU with the name idfName and connects to the thermal zone with name zoneName. The idfName needs to be specified in an instance of Buildings.ThermalZones.EnergyPlus_9_6_0.Building that is named building, and that is placed at this or at a higher hierarchy-level of the model. If the FMU is already instantiated by another instance of this model, it will use the already instantiated FMU. Hence, for each thermal zone in an EnergyPlus FMU, one instance of this model needs to be used. See Buildings.ThermalZones.EnergyPlus_9_6_0.UsersGuide for how zones are simulated that are declared in the EnergyPlus input data file but not in Modelica.

If there are two instances that declare the same zoneName and have in the model hierarchy the same instance of Buildings.ThermalZones.EnergyPlus_9_6_0.Building, then the simulation will stop with an error.

Main Equations

This model computes in Modelica the air energy, mass and species balance. Outside air infiltration needs to be modeled in Modelica, because any infiltration that the EnergyPlus model may specify is ignored. The convective heat transfer with the building fabric, the long-wave and the short-wave radiation are computed by EnergyPlus.

Heat and mass balance

The zone uses a volume of air that is fully mixed. The size of this volume, and its floor area, which is used to scale the heat gains q_flow, are obtained from the EnergyPlus model.

The zone has a fluid port fluPor that can be used to connect one or several HVAC inlets, flow paths for air infiltration and exfiltration, or for interzonal air exchange, using for example models from Buildings.Airflow.Multizone.

The model also has a heat port heaPorAir that connects to the sensible heat balance of the room air, and a heat port heaPorRad that connects to the radiative heat balance of the room inside surfaces. If heat is added to heaPorRad.Q_flow, then this heat is sent to EnergyPlus as if it were a radiant heat gain of the zone. The heat port temperature heaPorRad.T is the radiant temperature of the room. Hence, these two ports heatPorAir and heaPorRad could be used to connect a radiator. Note, however, that such a coupling is an approximation as the surface temperature of the radiator will not be reflected in the radiative temperature of the room. Also, read to section Notes about modeling components that are connected to the radiative heat port below.

Contaminant balance

The model has a parameter use_C_flow. If set to true, then an input connector C_flow is enabled, which allows adding trace substances to the room air. Note that this requires a medium model that has trace substances enabled.

Heat gains and CO2 added by people

If the EnergyPlus model computes internal heat gains such as from people or equipment, then their sensible convective and latent heat gains are automatically added to this room model, and the radiant fraction is added to the EnergyPlus envelope and thus treated correctly. In addition, if desired, radiant, convective and latent heat gains in units of W/m2 can be added using the input connector qGai_flow.

Similarly, if people are modeled in EnergyPlus (using the EnergyPlus People object), and if the Modelica Medium contains CO2 (e.g., if Medium.nC > 0 and there is a Medium.substanceName = "CO2"), then the CO2 emitted by the people is automatically added to this volume. However, the "Generic Contaminant" modeled in EnergyPlus is not added to the air volume. (Because EnergyPlus does not declare the name of the species or its molar mass and hence it cannot be matched to species in Modelica or converted to emitted mass flow rate.)

Also, note that while CO2 emitted from people simulated in EnergyPlus is added automatically to the air balance of this model, there is no CO2 added automatically for the heat gain specified through the input connector qGai_flow. Hence, if qGai_flow accounts for people and CO2 should be modelled, then the CO2 emitted by the people specified in qGai_flow needs to be added manually to the input connector C_flow. (This manual addition is needed because qGai_flow can also contain heat gains not caused by people.)

Notes about modeling components that are connected to the radiative heat port

Models in which a component is connected to the radiative heat port heaPorRad may cause convergence problems during the initialization of the simulation if that component computes the radiative heat exchange heaPorRad.Q_flow based on the temperature heaPorRad.T, and if the parameter building.setInitialRadiativeHeatGainToZero is changed from its default value true. It is therefore recommended to leave the parameter setInitialRadiativeHeatGainToZero at its default value true. This sets the radiative heat flow rate sent from Modelica to EnergyPlus to zero during the initialization of the model, thereby avoiding a potential nonlinear system of equations that may give convergence problems. This only affects the initialization of the model but not the time integration, hence the error should be small for typical models.

If you decide to set setInitialRadiativeHeatGainToZero = false, you need to be aware of the following: If setInitialRadiativeHeatGainToZero = false, then the radiative heat gain from the model input is being used. If this radiative heat gain depends on the radiative temperature that is an output of the EnergyPlus model, a nonlinear equation is formed. Because in EnergyPlus, computing the radiative temperature involves an iterative solution, this can cause convergence problems due to having two nested solvers, the outer being the Modelica solver that solves for the radiative heat flow rate QGaiRad_flow, and the innner being the EnergyPlus solver that solves for the radiative temperature TRad. Hence, we recommend to leave building.setInitialRadiativeHeatGainToZero = true.

If you decide to set building.setInitialRadiativeHeatGainToZero = false, you may need to also tighten the tolerance of the EnergyPlus solver by tightening building.relativeSurfaceTolerance, but one cannot assure that the nested nonlinear equations converge.

Because a Modelica model does not have knowledge of the solver tolerance, automatically tightening building.relativeSurfaceTolerance as a function of the Modelica solver tolerance is not possible.

Contents

NameDescription
MediumMedium in the component

Revisions


Generated at 2024-04-28T18:16:21Z by OpenModelicaOpenModelica 1.22.3 using GenerateDoc.mos