.Buildings.Fluid.HeatPumps.ModularReversible.UsersGuide .Buildings.Fluid.HeatPumps.ModularReversible.UsersGuideThe packages Buildings.Fluid.HeatPumps
and Buildings.Fluid.Chillers
contain models for both reversible and non-reversible refrigerant
machines (heat pumps and chillers) based on grey-box approaches.
Either empirical data or physical equations are used to model the
refrigerant cycle. The model for a refrigerant cycle calculates the
electrical power consumption PEle, the condenser heat
flow QCon_flow, and the evaporator heat flow
QEva_flow based on available variables of the sink and
source streams. Thus, this model does not enable closed-loop
simulations of the refrigerant cycle. However, such models are
highly demanding in terms computation time, and commercial
implementations exist. When simulating the refrigerant machine in a
more complex energy system, this modular approach enables detailed
performance and dynamic behaviour and fast computating times.
This user guide will help understand how to use the models associated with the modular approach. The approach was presented at the Modelica Conference 2021, see the section References.
Heat pumps and chillers are versatile machines:
To what extend all these effects need to be modeled depends on the simulation aim. Sometimes a simple Carnot approach is sufficient, sometimes a more detailed performance data and a realistic control behaviour is required.
The modular approach allows to disable any irrelevant features,
select readily made functional modules, and easily add new model
modules. Relevant components are declared as
replaceable. Replaceable models are
constrainedby partial models which one is free to
extend. Thus, new model approaches can be inserted into the
framework of the modular reversible model approach. For users not
familiar with replaceable models, there are readily assembled
models as well.
This section explains the inheritance and model package structure to help navigate through all options and to check out the detailed documentation of each model for further information.
All modular heat pump or chiller models base on the model Buildings.Fluid.HeatPumps.ModularReversible.RefrigerantCycle.BaseClasses.PartialHeatPumpCycle. This partial model declares all common interfaces, parameters, etc.
For heat pumps, the model Buildings.Fluid.HeatPumps.ModularReversible.Modular
extends the partial model and adds the connector hea
to choose between the operation modes of the heat pump:
hea = true: Main operation mode (heating)hea = false: Reversed operation mode
(cooling)Furthermore, the refrigerant cycle is redeclared to use the one for the heat pump Buildings.Fluid.HeatPumps.ModularReversible.BaseClasses.RefrigerantCycle. This refrigerant cycle in turn contains replaceable models for the heating and cooling operation of the heat pump. Available modules can be found in the package: Buildings.Fluid.HeatPumps.ModularReversible.RefrigerantCycle For more information on the refrigerant cycle models, refer to the section Refrigerant cycle models.
There are a number of preconfigured models provided in the package. Please check out the documentation of each approach to check if this approach is suitable.
For chillers, the model Buildings.Fluid.Chillers.ModularReversible.Modular
extends the partial model and adds the connector coo
to choose between the operation mode of the chiller:
coo = true: Main operation mode (cooling)coo = false: Reversed operation mode
(heating)Furthermore, the refrigerant cycle is redeclared to use the one for the chiller Buildings.Fluid.Chillers.ModularReversible.BaseClasses.RefrigerantCycle. This refrigerant cycle in turn contains replaceable models for the cooling and heating operation of the chiller. Available modules can be found in the package: Buildings.Fluid.Chillers.ModularReversible.RefrigerantCycle. For more information on the refrigerant cycle models, refer to the section Refrigerant cycle models.
There are a number of preconfigured models provided in the package. Please check out the documentation of each approach to check if this approach is suitable.
Simulating reversible heat pumps and chillers can get confusing, as the same heat exchanger model has to be used for both condensation and evaporation.
In most cases, heat pumps and chillers extract/exhaust heat from/to an ambient source (air, soil, ground-water, etc.), and, consuming electrical energy, provide heating or cooling on the useful or load side. For building applications, this useful / load side is inside the building. The ambient heat is outside of the building, on the ambient / source side. However, vapor compression machines can also be used to provide heating and cooling simultaneously. In this case, both sides provide utility to the energy system. Hence, both sides are useful / load sides.
What always stays the same is that there is one heated fluid, and one cooled fluid. Thus, specifying the nominal temperatures, users have to specify the temperatures of both heated and cooled fluids, for both cooling and heating operation. Note, that the heated fluid will be the cooled fluid in reversed operation, and vice versa.
Because of this, we decided on a naming scheme which is based on
the main operation of the heat pump or chiller. The main operation
of a heat pump is heating, for a chiller, it is cooling. When
reversed, the condenser becomes the evaporator and vice versa. As
renaming instances after translation is not possible, users always
have to think about the names con and eva
in terms of the main operation of the device. This applies to the
instance and variable names, such as the heat exchangers
con and eva, as well as sensors such as
TConOutMea and TEvaInMea, or nominal
conditions TConHea_nominal and
TConCoo_nominal. As the nominal temperatures may be
used table-based performance data and the operational envelope
model, users also have to think about the useful / load and
ambient / source side and how they translate to heat pumps
and chillers in both main and reversed operation when adding new
datasheets. Thinking about the heated and cooled fluid helps.
The following tables summarizes the possible options.
| Heat pump main | Heat pump reversed | Chiller main | Chiller reversed | |
|---|---|---|---|---|
| Heating / cooling? | heating | cooling | cooling | heating |
| Table-data: column 1: useful / load side | con |
con 1 |
eva |
eva 2 |
| Table-data - row 1: ambient / source side | eva |
eva 2 |
con |
con 1 |
| Operational envelope - column 1: ambient / source side | eva |
eva 2 |
con |
con 1 |
| Operational envelope - column 2: useful / load side | con |
con 1 |
eva |
eva 2 |
1 In reality, the condenser, e.g. a plate heat exchanger, of the main operation is used for evaporation. 2 In reality, the evaporator, e.g. fin-tube heat exchanger, of the main operation is used for condensation.
Aside from the aforementioned Boolean signals hea
and coo, the following connectors are relevant to
understanding how the model works: Compressor speed and the
expandable bus connector. The ambient temperatures
TEvaAmb and TConAmb are only relevant for
the heat losses. The fluid ports are explained in more detail here:
Buildings.Fluid.UsersGuide.
The input ySet represents the relative compressor
speed. To model both on/off and inverter controlled refrigerant
machines, the compressor speed is normalised to a relative value
between 0 and 1. To model heat pumps other than
inverter driven, other signal limits can be used. If data is in Hz
or similar, consider converting the input according to the maximum
allowed value.
We use the notation Set to indicate a set value. It
may be modified by the safety control blocks which produces a
signal with the Mea notation. For example, the
compressor speed ySet is modified by the safety
control block to yMea. If no safety violations occur,
ySet equals yMea.
As the modular approach may require different information to
model the refrigerant cycle depending on configuration, all
available states and outputs are aggregated in the expandable bus
connector sigBus. For instance, in order to control
both chillers and heat pumps, both flow and return temperature are
relevant.
A replaceable refrigerant cycle model for heating or cooling
calculates the electrical power consumption PEle,
condenser heat flow rate QCon_flow and evaporator heat
flow rate QEva_flow based on the values in the
sigBus. Heat pumps models extend
Buildings.Fluid.HeatPumps.ModularReversible.RefrigerantCycle.BaseClasses.PartialHeatPumpCycle
and chiller models extend
Buildings.Fluid.Chillers.ModularReversible.RefrigerantCycle.BaseClasses.PartialChillerCycle.
Currently, two modules for refrigerant cycle are implemented. First, the Buildings.Fluid.HeatPumps.ModularReversible.RefrigerantCycle.ConstantCarnotEffectiveness model uses the same equations as the Carnot models, i.e. Buildings.Fluid.HeatPumps.Carnot_y. Second, the Buildings.Fluid.HeatPumps.ModularReversible.RefrigerantCycle.TableData2D provides performance data based on different condenser outlet and evaporator inlet temperatures using 2D-tables.
Two additional modules exist in the AixLib library. These approaches require the use of the SDF-library, as the compressor speed influences the model output as a third dimension. Currently, tables with more than two dimensions are not supported in the Modelica Standard Library. The first approach is similar to Buildings.Fluid.HeatPumps.ModularReversible.RefrigerantCycle.TableData2D approach buts adds the 3rd dimension of compressor speed. The second approach is based on white-box stationary Python models for closed-loop refrigerant cycles. The model has been empirically validated and can take up to n-dimensions. If your simulation aim requires more detailed data, be sure to check out the models in the AixLib.
The refrigerant cycle models will output varying heat flow rates and electrical power consumptions. This is based on the fact that refrigerant cycle performance depend heavily on the boundary conditions.
Still, the user needs to size the device or the system according to some reference points. Accordingly, we follow the basic Buildings concept for nominal conditions, explained in detail here: Buildings.Fluid.UsersGuide
The nominal heat flow rate of the device is distinct for heat
pumps and chillers. For heat pumps, it is the nominal condenser
heat flow rate QHea_flow_nominal. For chillers, it is
the nominal evaporator heat flow rate
QCoo_flow_nominal (negative). This nominal heat flow
rate is only valid at the nominal conditions. Whether parameters
influence the nominal heat flow rates depends on the model approach
used to estimate the heat flow rate and efficiencies. Typically, at
least nominal source and sink temperatures will influence the
nominal conditions:
TCon_nominal,TEva_nominal,Depending on the model in use, this may be inlet or outlet.
Another example would be inverter driven devices. Here, the
compressor speed influences the refrigerant mass flow rate and
compressor efficiencies. If the performance data is dependent on
the compressor speed, y_nominal influences the nominal
efficiencies. In such cases, specifying additional nominal
parameters will be nessary.
Using the nominal conditions and the specified heat flow rate,
the nominal electrical power consumption PEle_nominal
is calculated. As reversible devices have typically a
four-way-valve and a single compressor, you have to make sure that
the values for PEle_nominal are similar between
heating and cooling. The pre-configured models warn about
deviations if they are too large.
To change the capacity of the model, users should change
QHea_flow_nominal for heating operation and
QCoo_flow_nominal for cooling operation. This will
then also update the electricity use
PEle_nominal.
For models with table-based performance curves, changing these
values will also scale the design mass flow rates and pressure
drops. The documentation of
Buildings.Fluid.HeatPumps.ModularReversible.TableData2D further
explains the scaling.
Refrigerant machines contain internal safety controls,
prohibiting operations in possibly unsafe points. All
ModularReversible models account for those. All
options can be disabled as described in the model description
Buildings.Fluid.HeatPumps.ModularReversible.Controls.Safety.Safety
An important safety control with regard to system interaction is the operation envelope. Read the documentation of Buildings.Fluid.HeatPumps.ModularReversible.Controls.Safety.BaseClasses.PartialOperationalEnvelope for more information on this model and how it affects device operation.
The refrigerant cycle models are based on stationary data
points, any inertia (mass and thermal) of components inside the
refrigerant cycle (compressor, pipes, expansion valve, fluid, etc.)
is neglected. To overcome this issue, replaceable SISO blocks that
are connected to the output of the refrigerant cycle (instance
refCyc) can approximate the refrigerant cycle
inertia.
The package Buildings.Fluid.HeatPumps.ModularReversible.RefrigerantCycle.Inertias contains implemented inertia models. In the contribution, an empirical validation showed that a third-order critical damping element fits the inertia most closely. At the same time, models in literature often use first-order delay blocks. Additionally, higher-order elements require more computation time. At the end, the requirements on the analysis will define the required level of detail of the model.
The effect of the inertia can be removed by setting
NoInertia.
If a user finds in real data that another approach might be better suited (e.g. a deadband), then the model Buildings.Fluid.HeatPumps.ModularReversible.RefrigerantCycle.Inertias.BaseClasses.PartialInertia can be extended to implement a costum model.
To simulate possible icing of the evaporator on air-source
devices, the icing factor iceFac is used to modify the
outputs. The factor models the reduction of heat transfer between
refrigerant and source. Thus, the factor is implemented as
follows:
QEva_flow = iceFac * (QConNoIce_flow - PEle)
With iceFac as a relative value between 0
and 1:
iceFac = kA/kA_noIce
Finally, the energy balance must still hold:
QCon_flow = PEle + QEva_flow
Different options can be selected for the modeling of the icing factor, or a custom model can be implemented by extending Buildings.Fluid.HeatPumps.ModularReversible.RefrigerantCycle.Frosting.BaseClasses.PartialIcingFactor
Note however, that this only simulates the efficiency reduction
due to frost. If a user-provided frost module enables the
simulation of a defrost cycle, the user needs to implement the
corresponding external controls. The iceFac approach
was already used by Vering et al., 2021, to account for reverse
cycle defrost based on validated literature-data. However, as no
empirical validation was performed, the model was not added to the
Buildings library.
Most refrigerant cycle models that calculate PEle,
QCon_flow, and QEva_flow assume the
device to be adiabatic, following the equation:
QCon_flow = PEle + QEva_flow
Depending on the application, one may need to model the heat losses to the ambient, as those may impact the overall efficiency of the heat pump or chiller. Thus, the heat exchangers in the models adds thermal capacities to the adiabatic heat exchanger. The parameterization may be challenging, as datasheets do not contain parameters for the required values. Besides empirical calibration, simplified assumptions (e.g. 2% heat loss) may be used to parameterize the required values. For more information, see the description of Buildings.Fluid.HeatPumps.ModularReversible.BaseClasses.EvaporatorCondenserWithCapacity
Fabian Wuellhorst, David Jansen, Philipp Mehrfeld and Dirk
Müller.
A Modular Model of Reversible Heat Pumps and Chillers for System
Applications.
Proceedings of 14th Modelica Conference 2021. Linköping, Sweden,
September, 2021.
doi:10.3384/ecp21181561.
Christian Vering, Fabian Wüllhorst, Philipp Mehrfeld and Dirk
Müller.
Towards an integrated design of heat pump systems: Application of
process intensification using two-stage optimization.
Energy Conversion and Management, Volume 250, 2021.
doi:10.1016/j.enconman.2021.114888.