This model distinguishes between internal
- thermal masses and exterior walls. While exterior walls contribute to heat
- transfer to the ambient, adiabatic conditions apply to internal masses.
- Parameters for the internal wall element are the length of the RC-chain
- nInt, the vector of the capacities
- CInt[nInt] and the vector of the resistances RInt[nInt].
- This approach allows considering the dynamic behaviour induced by internal
- heat storage.
-
-
- This model distinguishes between internal thermal masses and exterior
- walls. While exterior walls contribute to heat transfer to the
- ambient, adiabatic conditions apply to internal masses. Parameters
- for the internal wall element are the length of the RC-chain
- nInt, the vector of the capacities
- CInt[nInt] and the vector of the resistances
- RInt[nInt]. This approach allows considering the dynamic
- behaviour induced by internal heat storage.
-
- attribute "align" not allowed for HTML5
----- AixLib/Utilities/Math/Functions/biquadratic.mo ----
+---- AixLib/Fluid/Movers/Data/Pumps/Wilo/Stratos25slash1to6.mo ----
-------- HTML Code --------
- This function computes
-
+ The nominal rpm is arbitrarily chosen as the rpm of the pump curve
+ in the data sheet that has the highest rpm,
+ without being limited by the maximum power limitation
+ (see dotted curve on figure below).
+ Pump curves (H(m_flow) and P(m_flow)) from the data sheets
+ are digitized using
+ web plot digitizer.
+
+ attribute "align" not allowed for HTML5
-
-
----- AixLib/Utilities/Math/Polynomial.mo ----
--------- HTML Code --------
-
-
This block computes a polynomial of arbitrary order. The polynomial has the form
-
+ The nominal rpm is arbitrarily chosen as the rpm of the pump curve in
+ the data sheet that has the highest rpm, without being limited by the
+ maximum power limitation (see dotted curve on figure below). Pump
+ curves (H(m_flow) and P(m_flow)) from the data sheets are digitized
+ using web plot
+ digitizer.
+
+ attribute "align" not allowed for HTML5
----- AixLib/Utilities/Math/QuadraticLinear.mo ----
+---- AixLib/Utilities/Math/Functions/bicubic.mo ----
-------- HTML Code --------
-
attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/BaseClasses/HANaturalCylinder.mo ----
+---- AixLib/Fluid/FixedResistances/HydraulicDiameter.mo ----
-------- HTML Code --------
-
- Fundamentals of Heat and Mass Transfer (Fourth Edition), Frank Incropera and David
- DeWitt, John Wiley and Sons, 1996
-
-
-
+ For more detailed models that compute the actual flow friction,
+ models from the package
+
+ Modelica.Fluid
+ can be used and combined with models from the
+ AixLib library.
+
+
+ To decouple the energy equation from the mass equations,
+ the pressure drop is a function of the mass flow rate,
+ and not the volume flow rate.
+ This leads to simpler equations.
+
+
+
- Fundamentals of Heat and Mass Transfer (Fourth Edition), Frank
- Incropera and David DeWitt, John Wiley and Sons, 1996
+ For more detailed models that compute the actual flow friction,
+ models from the package Modelica.Fluid can be used and
+ combined with models from the AixLib library.
-
+ To decouple the energy equation from the mass equations, the pressure
+ drop is a function of the mass flow rate, and not the volume flow
+ rate. This leads to simpler equations.
+
+ attribute "align" not allowed for HTML5
----- AixLib/Utilities/IO/SignalExchange/SignalTypes/SignalsForKPIs.mo ----
+---- AixLib/Fluid/HeatPumps/Carnot_y.mo ----
-------- HTML Code --------
- This enumeration defines the signal types that are used by BOPTEST
- to compute the key performance indices (KPI).
+ This is model of a heat pump whose coefficient of performance COP changes
+ with temperatures in the same way as the Carnot efficiency changes.
+ The input signal y is the control signal for the compressor.
- The following signal types are supported.
+ The model allows to either specify the Carnot effectivness
+ ηCarnot,0, or
+ a COP0
+ at the nominal conditions, together with
+ the evaporator temperature Teva,0 and
+ the condenser temperature Tcon,0, in which
+ case the model computes the Carnot effectivness as
+
+
+ When using this component, make sure that the evaporator and the condenser have sufficient mass flow rate.
+ Based on the mass flow rates, the compressor power, temperature difference and the efficiencies,
+ the model computes how much heat will be added to the condenser and removed at the evaporator.
+ If the mass flow rates are too small, very high temperature differences can result.
+
+
+ The coefficient of performance depends on the
+ evaporator and condenser leaving temperature
+ since otherwise the second law of thermodynamics may be violated.
+
+
- This enumeration defines the signal types that are used by BOPTEST to
- compute the key performance indices (KPI).
+ This is model of a heat pump whose coefficient of performance COP
+ changes with temperatures in the same way as the Carnot efficiency
+ changes. The input signal y is the control signal for the
+ compressor.
- The following signal types are supported.
+ The model allows to either specify the Carnot effectivness
+ ηCarnot,0, or a COP0 at the
+ nominal conditions, together with the evaporator temperature
+ Teva,0 and the condenser temperature
+ Tcon,0, in which case the model computes the Carnot
+ effectivness as
- element is obsolete in HTML5
-
-
----- AixLib/BoundaryConditions/UsersGuide.mo ----
--------- HTML Code --------
-
-This package contains models to read or compute boundary conditions, such as weather data, solar irradition and sky temperatures.
-The calculations follow the description in Wetter (2004), Appendix A.4.2.
-Accessing weather data
-
-The model
-
-AixLib.BoundaryConditions.WeatherData.ReaderTMY3
-can read TMY3 weather data for different locations.
-The documentation of that model explains how to add
-weather data for locations that are not distributed with the
-AixLib library.
+
+ ηCarnot,0 = COP0 ⁄ (Tcon,0 ⁄
+ (Tcon,0-Teva,0)).
-To access these weather data from the graphical model editor,
-proceed as follows:
+ The heat pump COP is computed as the product
+
+
+ COP = ηCarnot,0 COPCarnot ηPL,
-
--
-Create an instance of
-
-AixLib.BoundaryConditions.WeatherData.ReaderTMY3.
+ where COPCarnot is the Carnot efficiency and
+ ηPL is a polynomial in the heating part load ratio
+ yPL that can be used to take into account a change
+ in COP at part load conditions. This polynomial has the form
+
+
+ ηPL = a1 + a2 yPL +
+ a3 yPL2 + ...
-
--
-Create an instance of
-
-AixLib.BoundaryConditions.WeatherData.Bus.
+ where the coefficients ai are declared by the
+ parameter a.
-
--
-Draw a connection between these two instances.
+ On the Dynamics tag, the model can be parametrized to
+ compute a transient or steady-state response. The transient response
+ of the model is computed using a first order differential equation
+ for the evaporator and condenser fluid volumes. The heat pump outlet
+ temperatures are equal to the temperatures of these lumped volumes.
-
--
+
+ Typical use and important parameters
+
-Finally, to send weather data to an input connector of a model,
-connect the input connector of that model with the instance of
-
-AixLib.BoundaryConditions.WeatherData.Bus.
-Some models connect to the whole weather data bus, such as
-
-AixLib.BoundaryConditions.SolarGeometry.Examples.IncidenceAngle,
-in which case the connection will directly be drawn.
-Other models require only an individual signal from the weather data bus,
-such as
-
-AixLib.BoundaryConditions.SkyTemperature.Examples.BlackBody.
-In this situation, Modelica modeling environments typically show a window that allows you to
-select what data from this weather data bus you want to connect
-with your model.
+ When using this component, make sure that the evaporator and the
+ condenser have sufficient mass flow rate. Based on the mass flow
+ rates, the compressor power, temperature difference and the
+ efficiencies, the model computes how much heat will be added to the
+ condenser and removed at the evaporator. If the mass flow rates are
+ too small, very high temperature differences can result.
-
-
-Conventions for surface azimuth and tilt
-To compute the solar irradiation, parameters such as the surface azimuth and the surface tilt are defined as shown in the following three figures.
-![\"image\"](\"modelica://AixLib/Resources/Images/BoundaryConditions/ear_ray.png\"/)
-![\"image\"](\"modelica://AixLib/Resources/Images/BoundaryConditions/zen_sun.png\"/)
-![\"image\"](\"modelica://AixLib/Resources/Images/BoundaryConditions/zen_pla.png\"/)
-For the surface azimuth and tilt, the enumerations
-
-AixLib.Types.Azimuth
-and
-
-AixLib.Types.Tilt
-can be used.
+ The condenser heat flow rate QCon_flow_nominal is used
+ to assign the default value for the mass flow rates, which are used
+ for the pressure drop calculations. It is also used to compute the
+ part load efficiency. Hence, make sure that
+ QCon_flow_nominal is set to a reasonable value.
-Note that a ceiling has a tilt of 0
-
-if they are facing straight upwards.
-This is correct because
-the solar irradiation on a ceiling construction is on the other-side surface,
-which faces upwards toward the sky. Hence, a construction is considered
-a ceiling from the view point of a person standing inside a room.
+ The maximum heating capacity is set by the parameter
+ QCon_flow_max, which is by default set to infinity.
-
-References
-
-
--------- Corrected Code --------
- This package contains models to read or compute boundary conditions,
- such as weather data, solar irradition and sky temperatures. The
- calculations follow the description in Wetter (2004), Appendix A.4.2.
+ The coefficient of performance depends on the evaporator and
+ condenser leaving temperature since otherwise the second law of
+ thermodynamics may be violated.
- Accessing weather data
+ Notes
- The model AixLib.BoundaryConditions.WeatherData.ReaderTMY3
- can read TMY3 weather data for different locations. The documentation
- of that model explains how to add weather data for locations that are
- not distributed with the AixLib library.
-
-
- To access these weather data from the graphical model editor, proceed
- as follows:
+ For a similar model that can be used as a chiller, see AixLib.Fluid.Chillers.Carnot_y.
-
- -
-
- Create an instance of AixLib.BoundaryConditions.WeatherData.ReaderTMY3.
-
+
+ - January 3, 2017, by Michael Wetter:
+ Removed parameters effInpEva and
+ effInpCon and updated documentation. This is for
+ issue
+ 497.
- -
-
- Create an instance of AixLib.BoundaryConditions.WeatherData.Bus.
-
+ - August 8, 2016, by Michael Wetter:
+ Changed default temperature to compute COP to be the leaving
+ temperature as use of the entering temperature can violate the 2nd
+ law if the temperature lift is small.
+ This is for Annex 60,
+ issue 497.
- -
-
- Draw a connection between these two instances.
-
+ - January 26, 2016, by Michael Wetter:
+ Refactored model to use the same base class as AixLib.Fluid.Chillers.Carnot_y.
+
+ Changed part load efficiency to depend on heating part load ratio
+ rather than on the compressor part load ratio.
- -
-
- Finally, to send weather data to an input connector of a model,
- connect the input connector of that model with the instance of
- AixLib.BoundaryConditions.WeatherData.Bus.
- Some models connect to the whole weather data bus, such as
-
- AixLib.BoundaryConditions.SolarGeometry.Examples.IncidenceAngle,
- in which case the connection will directly be drawn. Other models
- require only an individual signal from the weather data bus, such
- as
- AixLib.BoundaryConditions.SkyTemperature.Examples.BlackBody.
- In this situation, Modelica modeling environments typically show
- a window that allows you to select what data from this weather
- data bus you want to connect with your model.
-
+ - January 20, 2015, by Damien Picard:
+ Add Carnot model to Annex 60 from the Buildings library.
+ Removed the flow direction dependency of staA1,
+ staB1, staA2 and staB2 as
+ the efficiency of the Carnot machine should only be computed in the
+ design flow direction.
-
-
- Conventions for surface azimuth and tilt
-
-
- To compute the solar irradiation, parameters such as the surface
- azimuth and the surface tilt are defined as shown in the following
- three figures.
-
-
- 
-
-
-
-
-
-
-
-
- For the surface azimuth and tilt, the enumerations AixLib.Types.Azimuth and
- AixLib.Types.Tilt can be
- used.
-
-
- Note that a ceiling has a tilt of 0
- if they are facing straight upwards. This is correct because the
- solar irradiation on a ceiling construction is on the other-side
- surface, which faces upwards toward the sky. Hence, a construction is
- considered a ceiling from the view point of a person standing inside
- a room.
-
-
- References
-
-
- - Michael Wetter.
+ - December 18, 2015, by Michael Wetter:
+ Corrected wrong computation of staB1 and
+ staB2 which mistakenly used the inStream
+ operator for the configuration without flow reversal. This is for
Simulation-based
- Building Energy Optimization.
- Dissertation. University of California at Berkeley. 2004.
+ \"https://github.com/lbl-srg/modelica-buildings/issues/476\">issue
+ 476.
+
+ - November 25, 2015 by Michael Wetter:
+ Changed sign convention for dTEva_nominal to be
+ consistent with other models. The model will still work with the
+ old values for dTEva_nominal, but it will write a
+ warning so that users can transition their models.
+ Corrected assert statement for the efficiency curve.
+ This is for issue
+ 468.
+
+ - September 3, 2015 by Michael Wetter:
+ Expanded documentation.
+
+ - May 6, 2015 by Michael Wetter:
+ Added prescribedHeatFlowRate=true for
+ vol2.
+
+ - October 9, 2013 by Michael Wetter:
+ Reimplemented the computation of the port states to avoid using the
+ conditionally removed variables sta_a1,
+ sta_a2, sta_b1 and sta_b2.
+
+ - May 10, 2013 by Michael Wetter:
+ Added electric power P as an output signal.
+
+ - October 11, 2010 by Michael Wetter:
+ Fixed bug in energy balance.
+
+ - March 3, 2009 by Michael Wetter:
+ First implementation.
-------- Errors --------
-line 60 column 1 - Warning: attribute "align" not allowed for HTML5
-line 61 column 1 - Warning:
attribute "align" not allowed for HTML5
-line 62 column 1 - Warning:
attribute "align" not allowed for HTML5
+line 16 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 24 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 34 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/ThermalZones/ReducedOrder/RC/BaseClasses/InteriorWall.mo ----
+---- AixLib/ThermalZones/ReducedOrder/RC/OneElement.mo ----
-------- HTML Code --------
-
InteriorWall represents heat storage within walls. It links a
- variable number n of thermal resistances and capacities to a
- series connection. n thus defines the spatial discretization of
- thermal effects within the wall. All effects are considered as one-dimensional
- normal to the wall's surface. This model is thought for interior wall
- elements that only serve as heat storage elements. The RC-chain is defined via
- a vector of capacities CInt[n] and a vector of resistances
- RInt[n].
- Resistances and capacities are connected alternately, starting with the first
- resistance RInt[1], from heat port_a into the wall.
-
- ![\"image\"/](\"modelica://AixLib/Resources/Images/ThermalZones/ReducedOrder/RC/BaseClasses/IntMassVarRC/IntMassVarRC.png\")
+
+ This model merges all thermal masses into one
+ element, parameterized by the length of the RC-chain
+ nExt, the vector of the capacities CExt[nExt] that is
+ connected via the vector of resistances RExt[nExt] and
+ RExtRem to the ambient and indoor air.
+ By default, the model neglects all
+ internal thermal masses that are not directly connected to the ambient.
+ However, the thermal capacity of the room air can be increased by
+ using the parameter mSenFac.
+
+
+ The image below shows the RC-network of this model.
+
+
+ ![\"image\"/](\"modelica://AixLib/Resources/Images/ThermalZones/ReducedOrder/RC/OneElement.png\")
+
-
+
+ -
+ March 7, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for
+ #1542.
+
+ -
+ October 9, 2019, by Michael Wetter:
+ Refactored addition of moisture to also account for the energy content of the
+ water vapor.
+ This is for IBPSA, issue 1209.
+
-
- April 27, 2016, by Michael Wetter:
- Added graphical connections.
+ September 24, 2019, by Martin Kremer:
+ Added possibility to consider moisture balance.
+ Defined volAir conditional. Added conditional volMoistAir and corresponding in- and output connectors.
+
+ -
+ July 11, 2019, by Katharina Brinkmann:
+ Renamed alphaRad to hRad,
+ alphaWin to hConWin,
+ alphaExt to hConExt,
+ alphaExtWallConst to hConExtWall_const,
+ alphaWinConst to hConWin_const
+
+ -
+ January 25, 2019, by Michael Wetter:
+ Added start value to avoid warning in JModelica.
+
+ -
+ September 26, 2016, by Moritz Lauster:
+ Added conditional statements to solar radiation part.
+ Deleted conditional statements of
+ splitFactor and splitFactorSolRad.
-
April 17, 2015, by Moritz Lauster:
- Implemented.
+ First implementation.
-
-
+
+
-------- Corrected Code --------
- InteriorWall represents heat storage within walls. It
- links a variable number n of thermal resistances and
- capacities to a series connection. n thus defines the
- spatial discretization of thermal effects within the wall. All
- effects are considered as one-dimensional normal to the wall's
- surface. This model is thought for interior wall elements that only
- serve as heat storage elements. The RC-chain is defined via a vector
- of capacities CInt[n] and a vector of resistances
- RInt[n]. Resistances and capacities are connected
- alternately, starting with the first resistance RInt[1],
- from heat port_a into the wall.
+ This model merges all thermal masses into one element, parameterized
+ by the length of the RC-chain nExt, the vector of the
+ capacities CExt[nExt] that is connected via the vector
+ of resistances RExt[nExt] and RExtRem to
+ the ambient and indoor air. By default, the model neglects all
+ internal thermal masses that are not directly connected to the
+ ambient. However, the thermal capacity of the room air can be
+ increased by using the parameter mSenFac.
+
+
+ The image below shows the RC-network of this model.
- - April 27, 2016, by Michael Wetter:
- Added graphical connections.
-
- - April 17, 2015, by Moritz Lauster:
- Implemented.
+ - March 7, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for #1542.
-
-
--------- Errors --------
-line 13 column 4 - Warning: attribute "align" not allowed for HTML5
+
October 9, 2019, by Michael Wetter:
+ Refactored addition of moisture to also account for the energy
+ content of the water vapor.
+ This is for IBPSA, issue
+ 1209.
+
+ September 24, 2019, by Martin Kremer:
+ Added possibility to consider moisture balance.
+ Defined volAir conditional. Added conditional
+ volMoistAir and corresponding in- and output
+ connectors.
+
+ July 11, 2019, by Katharina Brinkmann:
+ Renamed alphaRad to hRad,
+ alphaWin to hConWin,
+ alphaExt to hConExt,
+ alphaExtWallConst to hConExtWall_const,
+ alphaWinConst to hConWin_const
+
+ January 25, 2019, by Michael Wetter:
+ Added start value to avoid warning in JModelica.
+
+ September 26, 2016, by Moritz Lauster:
+ Added conditional statements to solar radiation part.
+ Deleted conditional statements of splitFactor and
+ splitFactorSolRad.
+
+ April 17, 2015, by Moritz Lauster:
+ First implementation.
+
+
+-------- Errors --------
+line 16 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/ActiveBeams/UsersGuide.mo ----
--------- HTML Code --------
-
-This package contains models of active beams.
-Active beams are devices used for heating, cooling and ventilation of spaces.
-A schematic diagram of an active beam unit is given below.
-
-
-![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/HeatExchangers/ActiveBeams/schematicAB.png\")
-
-
-The active beam unit consists of a primary air plenum, a mixing chamber, a heat exchanger (coil) and several nozzles.
-Typically, an air-handling unit supplies primary air to the active beams.
-The primary air is discharged to the mixing chamber through the nozzles.
-This generates a low-pressure region which induces air from the room up through the heat exchanger,
-where hot or cold water is circulating.
-The conditioned induced air is then mixed with primary air, and the mixture descents back to the space.
-
-
-This package contains two models. The model
-
-AixLib.Fluid.HeatExchangers.ActiveBeams.Cooling
-is for cooling only, while the model
-
-AixLib.Fluid.HeatExchangers.ActiveBeams.CoolingAndHeating
-has two water streams, one for heating and one for cooling.
-
+---- AixLib/Fluid/FixedResistances/CheckValve.mo ----
+-------- HTML Code --------
-Model equations for cooling
+
+ Implementation of a hydraulic check valve.
+ Note that the small reverse flows can still occur with this model.
+
+ Main equations
+
+ The basic flow function
+
+
+ m = sign(Δp) k √ Δp ,
+
+
+ with regularization near the origin, is used to compute the pressure drop.
+ The flow coefficient
+
+
+ k = m ⁄ √ Δp
+
+
+ is increased from l*KV_Si to KV_Si,
+ where KV_Si is equal to Kv but in SI units.
+ Therefore, the flow coefficient k is set to a value close to zero for negative pressure differences, thereby
+ restricting reverse flow to a small value.
+ The flow coefficient k saturates to its maximum value at the pressure dpValve_closing.
+ For larger pressure drops, the pressure drop is a quadratic function of the flow rate.
+
+ Typical use and important parameters
+
+ The parameters m_flow_nominal and dpValve_nominal
+ determine the flow coefficient of the check valve when it is fully opened.
+ A typical value for a nominal flow rate of 1 m/s is
+ dpValve_nominal = 3400 Pa.
+ The leakage ratio l determines the minimum flow coefficient,
+ for negative pressure differences.
+ The parameter dpFixed_nominal allows to include a series
+ pressure drop with a fixed flow coefficient into the model.
+ The parameter dpValve_closing determines when the
+ flow coefficient starts to increase,
+ which is typically in the order of dpValve_nominal.
+
+ Implementation
+
+ The check valve implementation approximates the physics
+ where a forward pressure difference opens the valve such that
+ the valve opening increases, causing a growing orifice area
+ and thus increasing the flow coefficient.
+ Near dp=dpValve_closing, the valve is fully open and the flow coefficient saturates
+ to the flow coefficient value determined by dpValve_nominal and m_flow_nominal.
+ For typical valve diameters, the check valve is only fully open
+ near nominal mass flow rate. Therefore, the model sets dpValve_closing=dpValve_nominal/2
+ by default.
+
+
+
+ -
+ September 16, 2019, by Kristoff Six and Filip Jorissen:
+ Implementation of a hydraulic check valve. This is for
+ issue 1198.
+
+
+
+-------- Corrected Code --------
-The performance of the model
-
-AixLib.Fluid.HeatExchangers.ActiveBeams.Cooling
-is computed based on manufacturer data
-specified in the package
-
-AixLib.Fluid.HeatExchangers.ActiveBeams.Data.
+ Implementation of a hydraulic check valve. Note that the small
+ reverse flows can still occur with this model.
+
+ Main equations
+
-For off-design conditions, the performance is adjusted using modification factors
-that account for changes in water flow rate,
-primary air flow rate and temperature difference.
-The total heat flow rate of the active beam unit is the sum of the heat flow rate provided by the primary air supply
-Qsa and the cooling heat flow rate provided by the beam convector Qc,Beam
-which injects room air and mixes it with the primary air.
+ The basic flow function
-
-The heat flow rate
-Qsa is delivered to a thermal zone
-through the fluid ports, while the heat flow rate from the convector Qc,Beam
-is coupled directly to the heat port.
-See for example
-
-AixLib.Fluid.HeatExchangers.ActiveBeams.Examples.CoolingOnly
-for how to connect these heat flow rates to a control volume.
+
+ m = sign(Δp) k √ Δp
+ ,
-The primary air contribution is
+ with regularization near the origin, is used to compute the pressure
+ drop. The flow coefficient
- Qsa = ṁsa cp,sa (Tsa-Tz)
+ k = m ⁄ √ Δp
+
-where ṁsa is the primary air mass flow rate,
-cp,sa is the air specific heat capacity,
-Tsa is the primary air temperature
-and Tz is the zone air temperature.
+ is increased from l*KV_Si to KV_Si, where
+ KV_Si is equal to Kv but in SI units.
+ Therefore, the flow coefficient k is set to a value
+ close to zero for negative pressure differences, thereby restricting
+ reverse flow to a small value. The flow coefficient k
+ saturates to its maximum value at the pressure
+ dpValve_closing. For larger pressure drops, the pressure
+ drop is a quadratic function of the flow rate.
+
+ Typical use and important parameters
+
-The heat flow rate of the beam convector Qc,Beam is determined using
-the rated capacity which is modified by three separate functions as
-
-
- Qc,Beam = Qc,nominal
-fΔT ( ΔTc ⁄ ΔTc,nominal )
-fsa( ṁsa ⁄ ṁsa,nominal )
-fw( ṁc,w ),
+ The parameters m_flow_nominal and
+ dpValve_nominal determine the flow coefficient of the
+ check valve when it is fully opened. A typical value for a nominal
+ flow rate of 1 m/s is dpValve_nominal = 3400 Pa.
+ The leakage ratio l determines the minimum flow
+ coefficient, for negative pressure differences. The parameter
+ dpFixed_nominal allows to include a series pressure drop
+ with a fixed flow coefficient into the model. The parameter
+ dpValve_closing determines when the flow coefficient
+ starts to increase, which is typically in the order of
+ dpValve_nominal.
+
+ Implementation
+
-the modification factors are as follows:
-The modification factor fΔT(·)
-describes how the capacity is adjusted to account for the temperature difference
-between the zone air and the water entering the convector.
-The independent variable is the ratio between the current temperature difference
-ΔTc and the temperature difference used to rate beam performance ΔTc,nominal.
-The temperature difference is
-
-
- ΔTc = Tcw-Tz,
+ The check valve implementation approximates the physics where a
+ forward pressure difference opens the valve such that the valve
+ opening increases, causing a growing orifice area and thus increasing
+ the flow coefficient. Near dp=dpValve_closing, the valve
+ is fully open and the flow coefficient saturates to the flow
+ coefficient value determined by dpValve_nominal and
+ m_flow_nominal. For typical valve diameters, the check
+ valve is only fully open near nominal mass flow rate. Therefore, the
+ model sets dpValve_closing=dpValve_nominal/2 by default.
-
-where Tcw is the chilled water temperature entering the convector.
+
+ - September 16, 2019, by Kristoff Six and Filip Jorissen:
+ Implementation of a hydraulic check valve. This is for issue
+ 1198.
+
+
-The modification factor fsa(·) adjusts the cooling capacity to account for varying primary air flow rate.
-The independent variable is the ratio between the current primary air flow rate ṁsa
-and the nominal air flow rate used to rate the beam performance.
+-------- Errors --------
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+line 17 column 2 - Warning:
attribute "align" not allowed for HTML5
-The modification factor fw(·) adjusts the cooling capacity for changes in water flow rate through the convector.
-The independent variable is the ratio between the current water flow rate ṁw
-and the nominal water flow rate used to rate the beam performance.
-
-Model equations for heating
-
-The performance of the model
-
-AixLib.Fluid.HeatExchangers.ActiveBeams.CoolingAndHeating
-is computed identical to the above described model that only provides cooling,
-with the exception that this model contains an additional water stream that
-can be used to provide heating.
-
-
-For the heating water stream, the temperature difference ΔTh
-used for the calculation of the modification factor fΔT(·) is
-
-
-ΔTh = Thw-Tz,
-
-
-where Thw is the hot water temperature entering the convector in heating mode
-and Tz is the zone air temperature.
-
-
-Dynamics
-
-The model can be configured to be steady-state or dynamic.
-If configured as dynamic, then a dynamic conservation equation is applied to the water streams
-for heating and for cooling.
-However, because the capacity of the beam depends on its inlet temperature, and is independent of the
-outlet temperature, the heat transferred
-to the room at the port heaPor.Q_flow, as well as the heat added to or removed from the
-water streams, will instantaneously change.
-The only dynamic responses are the water outlet temperatures, which change with a first
-order response, parameterized with the time constant tau.
-
-
-Energy balance
-
-All heat flow rate that is added to or extracted from the room is transmitted through the heat port
-heaPor. Hence, this model does not cool the supply air between the ports
-air_a and air_b. Rather, it adds this heat flow rate
-to the heat port heaPor.
-The rationale for this implementation is that the beam transfers heat by convection directly to the room, and
-by induction of room air into the supply air. As this split of heat flow rate is generally not known,
-and because the amount of inducted air is also unknown,
-it was decided to transfer all heat through the heat port heaPor.
-This also avoids having to add an extra air flow path for the air induced from the room.
-
+---- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/PlugFlowAIT.mo ----
+-------- HTML Code --------
+
+ The example contains
+ experimental data from a real district heating network.
+
+ The pipes' temperatures are not initialized. Therefore, results of
+ outflow temperature before approximately the first 10000 seconds should not be
+ considered.
+
+
+ Note that these three models are identical, except for the pipe model that is used:
+
+
+
+ This comparison between different discretization levels and pipe models is made
+ to check the influence of the discretization and pipe model on computation time
+ and simulation accuracy.
+
+ Test bench schematic
+ ![\"Schematic](\"modelica://AixLib/Resources/Images/Fluid/FixedResistances/Validation/PlugFlowPipes/AITTestBench.png\"/)
+
+ Calibration
+ To calculate the length specific thermal resistance R of the pipe,
+ the thermal resistance of the surrounding ground is added, which yields
+
+ R=1/(0.208)+1/(2 lambda_g Modelica.Constants.pi) log(1/0.18),
+ where the thermal conductivity of the ground lambda_g = 2.4 W/(m K).
+
+
+
+ -
+ March 7, 2020, by Michael Wetter:
+ Replaced measured data from specification in Modelica file to external table,
+ as this reduces the computing time.
+ This is for
+ #1289.
+
+ -
+ May 15, 2019, by Jianjun Hu:
+ Replaced fluid source. This is for
+ #1072.
+
+ - July 4, 2016 by Bram van der Heijde:
Added parameters to test the
+ influence of allowFlowReversal and the presence of explicit volumes in the pipe.
+
+ - January 26, 2016 by Carles Ribas:
First implementation.
+
+
-------- Corrected Code --------
- This package contains models of active beams. Active beams are
- devices used for heating, cooling and ventilation of spaces. A
- schematic diagram of an active beam unit is given below.
+ The example contains experimental data from a real district heating
+ network.
-
-
+
+ The pipes' temperatures are not initialized. Therefore, results of
+ outflow temperature before approximately the first 10000 seconds
+ should not be considered.
- The active beam unit consists of a primary air plenum, a mixing
- chamber, a heat exchanger (coil) and several nozzles. Typically, an
- air-handling unit supplies primary air to the active beams. The
- primary air is discharged to the mixing chamber through the nozzles.
- This generates a low-pressure region which induces air from the room
- up through the heat exchanger, where hot or cold water is
- circulating. The conditioned induced air is then mixed with primary
- air, and the mixture descents back to the space.
+ Note that these three models are identical, except for the pipe model
+ that is used:
+
- This package contains two models. The model AixLib.Fluid.HeatExchangers.ActiveBeams.Cooling
- is for cooling only, while the model
- AixLib.Fluid.HeatExchangers.ActiveBeams.CoolingAndHeating has two
- water streams, one for heating and one for cooling.
+ This comparison between different discretization levels and pipe
+ models is made to check the influence of the discretization and pipe
+ model on computation time and simulation accuracy.
- Model equations for cooling
+ Test bench schematic
- The performance of the model AixLib.Fluid.HeatExchangers.ActiveBeams.Cooling
- is computed based on manufacturer data specified in the package
- AixLib.Fluid.HeatExchangers.ActiveBeams.Data.
-
-
- For off-design conditions, the performance is adjusted using
- modification factors that account for changes in water flow rate,
- primary air flow rate and temperature difference. The total heat flow
- rate of the active beam unit is the sum of the heat flow rate
- provided by the primary air supply Qsa and the
- cooling heat flow rate provided by the beam convector
- Qc,Beam which injects room air and mixes it with
- the primary air.
-
-
- The heat flow rate Qsa is delivered to a thermal
- zone through the fluid ports, while the heat flow rate from the
- convector Qc,Beam is coupled directly to the heat
- port. See for example
- AixLib.Fluid.HeatExchangers.ActiveBeams.Examples.CoolingOnly for
- how to connect these heat flow rates to a control volume.
-
-
- The primary air contribution is
-
-
- Qsa = ṁsa cp,sa
- (Tsa-Tz)
-
-
- where ṁsa is the primary air mass flow rate,
- cp,sa is the air specific heat capacity,
- Tsa is the primary air temperature and
- Tz is the zone air temperature.
-
-
- The heat flow rate of the beam convector Qc,Beam is
- determined using the rated capacity which is modified by three
- separate functions as
-
-
- Qc,Beam = Qc,nominal fΔT (
- ΔTc ⁄ ΔTc,nominal ) fsa(
- ṁsa ⁄ ṁsa,nominal ) fw(
- ṁc,w ),
-
-
- the modification factors are as follows: The modification factor
- fΔT(·) describes how the capacity is adjusted to
- account for the temperature difference between the zone air and the
- water entering the convector. The independent variable is the ratio
- between the current temperature difference ΔTc and
- the temperature difference used to rate beam performance
- ΔTc,nominal. The temperature difference is
-
-
- ΔTc = Tcw-Tz,
-
-
- where Tcw is the chilled water temperature entering
- the convector. The modification factor fsa(·)
- adjusts the cooling capacity to account for varying primary air flow
- rate. The independent variable is the ratio between the current
- primary air flow rate ṁsa and the nominal air flow
- rate used to rate the beam performance. The modification factor
- fw(·) adjusts the cooling capacity for changes in
- water flow rate through the convector. The independent variable is
- the ratio between the current water flow rate ṁw
- and the nominal water flow rate used to rate the beam performance.
+ 
- Model equations for heating
+ Calibration
- The performance of the model
- AixLib.Fluid.HeatExchangers.ActiveBeams.CoolingAndHeating is
- computed identical to the above described model that only provides
- cooling, with the exception that this model contains an additional
- water stream that can be used to provide heating.
-
-
- For the heating water stream, the temperature difference
- ΔTh used for the calculation of the
- modification factor fΔT(·) is
+ To calculate the length specific thermal resistance R of
+ the pipe, the thermal resistance of the surrounding ground is added,
+ which yields
- ΔTh = Thw-Tz,
+ R=1/(0.208)+1/(2 lambda_g Modelica.Constants.pi)
+ log(1/0.18),
- where Thw is the hot water temperature entering the
- convector in heating mode and Tz is the zone air
- temperature.
-
-
- Dynamics
-
-
- The model can be configured to be steady-state or dynamic. If
- configured as dynamic, then a dynamic conservation equation is
- applied to the water streams for heating and for cooling. However,
- because the capacity of the beam depends on its inlet temperature,
- and is independent of the outlet temperature, the heat transferred to
- the room at the port heaPor.Q_flow, as well as the heat
- added to or removed from the water streams, will instantaneously
- change. The only dynamic responses are the water outlet temperatures,
- which change with a first order response, parameterized with the time
- constant tau.
-
-
- Energy balance
-
-
- All heat flow rate that is added to or extracted from the room is
- transmitted through the heat port heaPor. Hence, this
- model does not cool the supply air between the ports
- air_a and air_b. Rather, it adds this heat
- flow rate to the heat port heaPor. The rationale for
- this implementation is that the beam transfers heat by convection
- directly to the room, and by induction of room air into the supply
- air. As this split of heat flow rate is generally not known, and
- because the amount of inducted air is also unknown, it was decided to
- transfer all heat through the heat port heaPor. This
- also avoids having to add an extra air flow path for the air induced
- from the room.
+ where the thermal conductivity of the ground lambda_g =
+ 2.4 W/(m K).
+
+ - March 7, 2020, by Michael Wetter:
+ Replaced measured data from specification in Modelica file to
+ external table, as this reduces the computing time.
+ This is for #1289.
+
+ - May 15, 2019, by Jianjun Hu:
+ Replaced fluid source. This is for #1072.
+
+ - July 4, 2016 by Bram van der Heijde:
+ Added parameters to test the influence of allowFlowReversal and the
+ presence of explicit volumes in the pipe.
+
+ - January 26, 2016 by Carles Ribas:
+ First implementation.
+
+
-------- Errors --------
-line 7 column 1 - Warning: attribute "align" not allowed for HTML5
-line 59 column 1 - Warning:
attribute "align" not allowed for HTML5
-line 72 column 1 - Warning:
attribute "align" not allowed for HTML5
-line 87 column 1 - Warning:
attribute "align" not allowed for HTML5
-line 115 column 1 - Warning:
attribute "align" not allowed for HTML5
+line 48 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/HydraulicDiameter.mo ----
+---- AixLib/Utilities/Math/Functions/Examples/CubicHermite.mo ----
-------- HTML Code --------
- This is a model of a flow resistance with a fixed flow coefficient.
- The mass flow rate is computed as
-
-
- ṁ = k
- √ΔP,
-
-
- where
- k is a constant and
- ΔP is the pressure drop.
- The constant k is equal to
- k=m_flow_nominal/sqrt(dp_nominal),
- where m_flow_nominal is a parameter.
-
- Assumptions
-
- In the region
- abs(m_flow) < m_flow_turbulent,
- the square root is replaced by a differentiable function
- with finite slope.
- The value of m_flow_turbulent is
- computed as
- m_flow_turbulent = eta_nominal*dh/4*π*ReC,
- where
- eta_nominal is the dynamic viscosity, obtained from
- the medium model. The parameter
- dh is the hydraulic diameter and
- ReC=4000 is the critical Reynolds number, which both
- can be set by the user.
-
- Important parameters
-
- By default, the pressure drop at nominal flow rate is computed as
-
-
- dp_nominal = fac * dpStraightPipe_nominal,
-
-
- where dpStraightPipe_nominal is a parameter that is automatically computed
- based on the
- nominal mass flow rate, hydraulic diameter, pipe roughness and medium properties.
- The hydraulic diameter dh is by default
- computed based on the flow velocity v_nominal and the nominal
- mass flow rate m_flow_nominal. Hence, users should change the
- default values of dh or v_nominal
- if they are not applicable for their model.
-
-
- The factor fac takes into account additional resistances such as
- for bends. The default value of 2 can be changed by the user.
-
-
- The parameter from_dp is used to determine
- whether the mass flow rate is computed as a function of the
- pressure drop (if from_dp=true), or vice versa.
- This setting can affect the size of the nonlinear system of equations.
-
-
- If the parameter linearized is set to true,
- then the pressure drop is computed as a linear function of the
- mass flow rate.
-
-
- Setting allowFlowReversal=false can lead to simpler
- equations. However, this should only be set to false
- if one can guarantee that the flow never reverses its direction.
- This can be difficult to guarantee, as pressure imbalance after
- the initialization, or due to medium expansion and contraction,
- can lead to reverse flow.
-
-
- If the parameter
- show_T is set to true,
- then the model will compute the
- temperature at its ports. Note that this can lead to state events
- when the mass flow rate approaches zero,
- which can increase computing time.
-
- Notes
-
- For more detailed models that compute the actual flow friction,
- models from the package
-
- Modelica.Fluid
- can be used and combined with models from the
- AixLib library.
+ This example demonstrates the use of the function for cubic hermite interpolation
+ and linear extrapolation.
+ The example use interpolation with two different settings: One settings
+ produces a monotone cubic hermite, whereas the other setting
+ does not enforce monotonicity.
+ The resulting plot should look as shown below, where for better visibility, the support points have been marked with black dots.
+ Notice that the red curve is monotone increasing.
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Utilities/Math/Functions/Examples/cubicHermite.png\"/)
+
+
+ -
+ March 8, 2013, by Michael Wetter:
+ First implementation.
+
+
+
+-------- Corrected Code --------
+
+ This example demonstrates the use of the function for cubic hermite
+ interpolation and linear extrapolation. The example use interpolation
+ with two different settings: One settings produces a monotone cubic
+ hermite, whereas the other setting does not enforce monotonicity. The
+ resulting plot should look as shown below, where for better
+ visibility, the support points have been marked with black dots.
+ Notice that the red curve is monotone increasing.
+
+
+
+
+
+ - March 8, 2013, by Michael Wetter:
+ First implementation.
+
+
+
+-------- Errors --------
+line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/HeatExchangers/ConstantEffectiveness.mo ----
+-------- HTML Code --------
+
- For a model that uses dp_nominal as a parameter rather than
- geoemetric data, use
-
- AixLib.Fluid.FixedResistances.PressureDrop.
+ Model for a heat exchanger with constant effectiveness.
- Implementation
- The pressure drop is computed by calling a function in the package
-
- AixLib.Fluid.BaseClasses.FlowModels,
- This package contains regularized implementations of the equation
+ This model transfers heat in the amount of
- m = sign(Δp) k √ Δp
+ Q = Qmax ε,
- and its inverse function.
+ where ε is a constant effectiveness and
+ Qmax is the maximum heat that can be transferred.
- To decouple the energy equation from the mass equations,
- the pressure drop is a function of the mass flow rate,
- and not the volume flow rate.
- This leads to simpler equations.
+ For a heat and moisture exchanger, use
+
+ AixLib.Fluid.MassExchangers.ConstantEffectiveness
+ instead of this model.
-
- September 21, 2021, by Michael Wetter:
- Corrected typo in comments.
- This is for
- #1525.
+ August 13, 2013 by Michael Wetter:
+ Corrected error in the documentation.
-
- December 1, 2016, by Michael Wetter:
- First implementation for
- #480.
+ July 30, 2013 by Michael Wetter:
+ Updated model to use new variable mWat_flow
+ in the base class.
+
+ -
+ January 28, 2010, by Michael Wetter:
+ Added regularization near zero flow.
+
+ -
+ October 2, 2009, by Michael Wetter:
+ Changed computation of inlet temperatures to use
+ state_*_inflow which is already known in base class.
+
+ -
+ April 28, 2008, by Michael Wetter:
+ First implementation.
-------- Corrected Code --------
- This is a model of a flow resistance with a fixed flow coefficient.
- The mass flow rate is computed as
+ Model for a heat exchanger with constant effectiveness.
+
+
+ This model transfers heat in the amount of
- ṁ = k √ΔP,
+ Q = Qmax ε,
- where k is a constant and ΔP is the pressure drop. The
- constant k is equal to
- k=m_flow_nominal/sqrt(dp_nominal), where
- m_flow_nominal is a parameter.
+ where ε is a constant effectiveness and Qmax
+ is the maximum heat that can be transferred.
-
- Assumptions
-
- In the region abs(m_flow) < m_flow_turbulent, the
- square root is replaced by a differentiable function with finite
- slope. The value of m_flow_turbulent is computed as
- m_flow_turbulent = eta_nominal*dh/4*π*ReC, where
- eta_nominal is the dynamic viscosity, obtained from the
- medium model. The parameter dh is the hydraulic diameter
- and ReC=4000 is the critical Reynolds number, which both
- can be set by the user.
-
-
- Important parameters
-
-
- By default, the pressure drop at nominal flow rate is computed as
-
-
- dp_nominal = fac * dpStraightPipe_nominal,
-
-
- where dpStraightPipe_nominal is a parameter that is
- automatically computed based on the nominal mass flow rate, hydraulic
- diameter, pipe roughness and medium properties. The hydraulic
- diameter dh is by default computed based on the flow
- velocity v_nominal and the nominal mass flow rate
- m_flow_nominal. Hence, users should change the default
- values of dh or v_nominal if they are not
- applicable for their model.
-
-
- The factor fac takes into account additional resistances
- such as for bends. The default value of 2 can be changed
- by the user.
-
-
- The parameter from_dp is used to determine whether the
- mass flow rate is computed as a function of the pressure drop (if
- from_dp=true), or vice versa. This setting can affect
- the size of the nonlinear system of equations.
-
-
- If the parameter linearized is set to true,
- then the pressure drop is computed as a linear function of the mass
- flow rate.
-
-
- Setting allowFlowReversal=false can lead to simpler
- equations. However, this should only be set to false if
- one can guarantee that the flow never reverses its direction. This
- can be difficult to guarantee, as pressure imbalance after the
- initialization, or due to medium expansion and contraction, can lead
- to reverse flow.
-
-
- If the parameter show_T is set to true,
- then the model will compute the temperature at its ports. Note that
- this can lead to state events when the mass flow rate approaches
- zero, which can increase computing time.
-
-
- Notes
-
-
- For more detailed models that compute the actual flow friction,
- models from the package Modelica.Fluid can be used and
- combined with models from the AixLib library.
-
-
- For a model that uses dp_nominal as a parameter rather
- than geoemetric data, use AixLib.Fluid.FixedResistances.PressureDrop.
-
-
- Implementation
-
-
- The pressure drop is computed by calling a function in the package
- AixLib.Fluid.BaseClasses.FlowModels,
- This package contains regularized implementations of the equation
-
-
- m = sign(Δp) k √ Δp
-
-
-
- and its inverse function.
-
-
- To decouple the energy equation from the mass equations, the pressure
- drop is a function of the mass flow rate, and not the volume flow
- rate. This leads to simpler equations.
+ For a heat and moisture exchanger, use AixLib.Fluid.MassExchangers.ConstantEffectiveness
+ instead of this model.
- - September 21, 2021, by Michael Wetter:
- Corrected typo in comments.
- This is for #1525.
+ - August 13, 2013 by Michael Wetter:
+ Corrected error in the documentation.
- - December 1, 2016, by Michael Wetter:
- First implementation for #480.
+ - July 30, 2013 by Michael Wetter:
+ Updated model to use new variable mWat_flow in the
+ base class.
+
+ - January 28, 2010, by Michael Wetter:
+ Added regularization near zero flow.
+
+ - October 2, 2009, by Michael Wetter:
+ Changed computation of inlet temperatures to use
+ state_*_inflow which is already known in base class.
+
+ - April 28, 2008, by Michael Wetter:
+ First implementation.
-------- Errors --------
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
-line 104 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 8 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/BaseClasses/PlugFlowHeatLoss.mo ----
+---- AixLib/Fluid/HeatPumps/ReciprocatingWaterToWater.mo ----
-------- HTML Code --------
- Component that calculates the heat losses at the end of a plug flow pipe
- when the flow goes in the design direction.
+ Model for a water to water heat pump with a reciprocating compressor, as
+ described in Jin (2002). The thermodynamic heat pump cycle is represented below.
+
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/HeatPumps/WaterToWater_Cycle.png\")
- Main equations
- The governing equations are
+ The rate of heat transferred to the evaporator is given by:
- Tout = Tb + (Tin - Tb)
- exp((tout - tin)/tauchar)
+ Q̇Eva = ṁref ( hVap(TEva) - hLiq(TCon) ).
- with
+ The power consumed by the compressor is given by a linear efficiency relation:
- tauchar = R C
+ P = PTheoretical / η + PLoss,constant.
- Assumptions and limitations
- This model is based on the following assumptions:
+ Heat transfer in the evaporator and condenser is calculated using an
+ ε-NTU method, assuming constant refrigerant temperature and constant heat
+ transfer coefficient between fluid and refrigerant.
-
- - The water temperature is uniform in the cross section.
- - There is no axial heat transfer in the water or surrounding.
- - The boundary temperature along the pipe is uniform.
- - Heat losses are steady-state.
-
- Implementation
- Heat losses are only considered in design flow direction.
- For heat loss consideration in both directions, use one of these models at
- both ends of a
-
- AixLib.Fluid.FixedResistances.BaseClasses.PlugFlow model.
- The outlet temperature is calculated as in the equation above,
- using the inlet temperature at port_a and the instantaneous
- time delay and boundary temperature.
- The boundary temperature can be either the air temperature
- or the undisturbed ground temperature, depending on the definition of the
- thermal resistance R.
+ Variable speed is acheived by multiplying the full load piston displacement
+ by the normalized compressor speed. The power and heat transfer rates are forced
+ to zero if the resulting heat pump state has higher evaporating pressure than
+ condensing pressure.
+ Options
- This component requires the delay time and the instantaneous ambient temperature
- as an input.
- This component is to be used in single pipes or in more advanced configurations
- where no influence from other pipes is considered.
+ Parameters TConMax and TEvaMin
+ may be used to set an upper or lower bound for the
+ condenser and evaporator.
+ The compressor is disabled when these conditions
+ are not satisfied, or when the
+ evaporator temperature is larger
+ than the condenser temperature.
+ This mimics the temperature protection
+ of heat pumps and moreover it avoids
+ non-converging algebraic loops of equations,
+ or freezing of evaporator medium.
+ This option can be disabled by setting
+ enable_temperature_protection = false.
+
+ Assumptions and limitations
+
+ The compression process is assumed isentropic. The thermal energy
+ of superheating is ignored in the evaluation of the heat transferred to the refrigerant
+ in the evaporator. There is no supercooling.
+
+ References
+
+ H. Jin.
+
+ Parameter estimation based models of water source heat pumps.
+
+ PhD Thesis. Oklahoma State University. Stillwater, Oklahoma, USA. 2002.
+
-
- December 6, 2017, by Michael Wetter:
- Reformulated call to medium function.
- This is for
-
- issue 869.
-
- -
- October 20, 2017, by Michael Wetter:
- Revised implementation to avoid graphical and textual modeling.
- Revised variable names and documentation to follow guidelines.
+ May 30, 2017, by Filip Jorissen:
+ Revised documentation for temperature protection.
+ See #769.
-
- November 6, 2015 by Bram van der Heijde:
- Make time delay input instead of calculation inside this model.
+ November 14, 2016, by Massimo Cimmino:
+ First implementation.
- -
- September, 2015 by Marcus Fuchs:
- First implementation.
-------- Corrected Code --------
- Component that calculates the heat losses at the end of a plug flow
- pipe when the flow goes in the design direction.
+ Model for a water to water heat pump with a reciprocating compressor,
+ as described in Jin (2002). The thermodynamic heat pump cycle is
+ represented below.
+
+
+
-
- Main equations
-
- The governing equations are
+ The rate of heat transferred to the evaporator is given by:
- Tout = Tb + (Tin - Tb)
- exp((tout - tin)/tauchar)
+ Q̇Eva = ṁref (
+ hVap(TEva) - hLiq(TCon)
+ ).
- with
+ The power consumed by the compressor is given by a linear efficiency
+ relation:
- tauchar = R C
+ P = PTheoretical / η + PLoss,constant.
+
+
+ Heat transfer in the evaporator and condenser is calculated using an
+ ε-NTU method, assuming constant refrigerant temperature and constant
+ heat transfer coefficient between fluid and refrigerant.
+
+
+ Variable speed is acheived by multiplying the full load piston
+ displacement by the normalized compressor speed. The power and heat
+ transfer rates are forced to zero if the resulting heat pump state
+ has higher evaporating pressure than condensing pressure.
- Assumptions and limitations
+ Options
- This model is based on the following assumptions:
-
-
- - The water temperature is uniform in the cross section.
-
- - There is no axial heat transfer in the water or surrounding.
-
- - The boundary temperature along the pipe is uniform.
-
- - Heat losses are steady-state.
-
-
+ Parameters TConMax and TEvaMin may be used
+ to set an upper or lower bound for the condenser and evaporator. The
+ compressor is disabled when these conditions are not satisfied, or
+ when the evaporator temperature is larger than the condenser
+ temperature. This mimics the temperature protection of heat pumps and
+ moreover it avoids non-converging algebraic loops of equations, or
+ freezing of evaporator medium. This option can be disabled by setting
+ enable_temperature_protection = false.
+
- Implementation
+ Assumptions and limitations
- Heat losses are only considered in design flow direction. For heat
- loss consideration in both directions, use one of these models at
- both ends of a AixLib.Fluid.FixedResistances.BaseClasses.PlugFlow
- model. The outlet temperature is calculated as in the equation above,
- using the inlet temperature at port_a and the
- instantaneous time delay and boundary temperature. The boundary
- temperature can be either the air temperature or the undisturbed
- ground temperature, depending on the definition of the thermal
- resistance R.
+ The compression process is assumed isentropic. The thermal energy of
+ superheating is ignored in the evaluation of the heat transferred to
+ the refrigerant in the evaporator. There is no supercooling.
+
+ References
+
- This component requires the delay time and the instantaneous ambient
- temperature as an input. This component is to be used in single pipes
- or in more advanced configurations where no influence from other
- pipes is considered.
+ H. Jin. Parameter estimation based models of water source heat
+ pumps. PhD Thesis. Oklahoma State University. Stillwater,
+ Oklahoma, USA. 2002.
- - December 6, 2017, by Michael Wetter:
- Reformulated call to medium function.
- This is for issue 869.
-
- - October 20, 2017, by Michael Wetter:
- Revised implementation to avoid graphical and textual modeling.
- Revised variable names and documentation to follow guidelines.
-
- - November 6, 2015 by Bram van der Heijde:
- Make time delay input instead of calculation inside this model.
+ - May 30, 2017, by Filip Jorissen:
+ Revised documentation for temperature protection. See #769.
- - September, 2015 by Marcus Fuchs:
+ - November 14, 2016, by Massimo Cimmino:
First implementation.
-------- Errors --------
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
-line 17 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 6 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 12 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 18 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/SensibleCooler_T.mo ----
+---- AixLib/Utilities/Math/Functions/biquadratic.mo ----
-------- HTML Code --------
-
- Model for an ideal sensible-only cooler that controls its outlet temperature to
- a prescribed outlet temperature.
-
-
- This model forces the outlet temperature at port_b to be
- no higher than the temperature of the input signal
- TSet, subject to optional limits on the
- capacity.
- By default, the model has unlimited cooling capacity.
-
-
- The output signal Q_flow ≤ 0 is the heat added
- to the medium if the mass flow rate is from port_a to port_b.
- If the flow is reversed, then Q_flow=0.
-
-
- The outlet conditions at port_a are not affected by this model,
- other than for a possible pressure difference due to flow friction.
-
-
- If the parameter energyDynamics is different from
- Modelica.Fluid.Types.Dynamics.SteadyState,
- the component models the dynamic response using a first order differential equation.
- The time constant of the component is equal to the parameter tau.
- This time constant is adjusted based on the mass flow rate using
-
+ This function computes
- τeff = τ |ṁ| ⁄ ṁnom
+ y = a1 + a2 x1
+ + a3 x12
+ + a4 x2 + a5 x22
+ + a6 x1 x2
+
+
+ -
+ Sep 8, 2010 by Michael Wetter:
+ First implementation.
+
+
+
+-------- Corrected Code --------
+This function computes
+
+ y = a1 + a2 x1 + a3
+ x12 + a4 x2 +
+ a5 x22 + a6 x1
+ x2
+
+
+ - Sep 8, 2010 by Michael Wetter:
+ First implementation.
+
+
+
+-------- Errors --------
+line 3 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/FixedResistances/BaseClasses/PlugFlowTransportDelay.mo ----
+-------- HTML Code --------
+
- where
- τeff is the effective time constant for the given mass flow rate
- ṁ and
- τ is the time constant at the nominal mass flow rate
- ṁnom.
- This type of dynamics is equal to the dynamics that a completely mixed
- control volume would have.
+ Calculates time delay at both sides of the pipe as the difference between the
+ current simulation time and the inlet time of the fluid at both ends of the pipe.
-
- Optionally, this model can have a flow resistance.
- Set dp_nominal = 0 to disable the flow friction calculation.
+
Main equation
+
+ ∂z(x,t)/∂t + v(t) ∂z(x,t)/∂x = 0,
- For a similar model that is a heater, use
-
- AixLib.Fluid.HeatExchangers.Heater_T.
- For a model that uses a control signal u ∈ [0, 1] and multiplies
- this with the nominal heating or cooling power, use
-
- AixLib.Fluid.HeatExchangers.HeaterCooler_u.
+ where z(x,t) is the spatial distribution as a function of time of any
+ property z of the fluid. For the inlet time propagation, z will
+ be replaced by the inlet time of the fluid tin.
- Limitations
+ Implementation
- If the flow is from port_b to port_a,
- then the enthalpy of the medium is not affected by this model.
+ The inlet time is approached as a fluid property and its propagation follows
+ the one-dimensional wave equation, implemented using the spatialDistribution
+ function. This components requires the mass flow through the pipe and the pipe
+ dimensions in order to derive information about the fluid propagation.
- This model does not affect the humidity of the air. Therefore,
- if used to cool air below the dew point temperature, the water mass fraction
- will not change.
+ The component calculates the delay time at the inlet and the outlet port of the pipe.
+ For the forward flow, the time delay is exposed at the output tau,
+ and for the backward flow, the time delay is exposed at the output tauRev.
- Validation
+ Assumption
- The model has been validated against the analytical solution in
- the examples
-
- AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet
- and
-
- AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet_dynamic.
+ No axial mixing takes place in the pipe.
-
- September 10, 2018, by Michael Wetter:
- Corrected missing propagation of initial conditions.
+ December 2, 2020, by Philipp Mehrfeld:
+ Corrected calculation of tau and tauRev to be be
+ only positive.
This is for
-
- AixLib, #1016.
+ #1427.
-
- May 3, 2017, by Michael Wetter:
- First implementation.
+ December 14, 2018, by Michael Wetter:
+ Corrected argument of spatialDistribution operator to be a parameter
+ expression.
This is for
-
- AixLib, #763.
+ #1055.
+
+ -
+ September 9, 2016 by Bram van der Heijde:
+ Rename from PDETime_massFlowMod to PlugFlowTransportDelayMod
+
+ -
+ December 2015 by Carles Ribas Tugores:
+ Modification in delay calculation to fix issues.
+
+ -
+ November 6, 2015 by Bram van der Heijde:
+ Adapted flow parameter to mass flow rate instead of velocity.
+ This change should also fix the reverse and zero flow issues.
+
+ -
+ October 13, 2015 by Marcus Fuchs:
+ Use abs() of normalized velocity input in order to avoid negative
+ delay times.
+
+ -
+ July 2015 by Arnout Aertgeerts:
+ First implementation.
-------- Corrected Code --------
- Model for an ideal sensible-only cooler that controls its outlet
- temperature to a prescribed outlet temperature.
+ Calculates time delay at both sides of the pipe as the difference
+ between the current simulation time and the inlet time of the fluid
+ at both ends of the pipe.
+
+
+ Main equation
+
+
+ ∂z(x,t)/∂t + v(t) ∂z(x,t)/∂x = 0,
- This model forces the outlet temperature at port_b to be
- no higher than the temperature of the input signal TSet,
- subject to optional limits on the capacity. By default, the model has
- unlimited cooling capacity.
+ where z(x,t) is the spatial distribution as a function of time
+ of any property z of the fluid. For the inlet time
+ propagation, z will be replaced by the inlet time of the fluid
+ tin.
+
+ Implementation
+
- The output signal Q_flow ≤ 0 is the heat added to the
- medium if the mass flow rate is from port_a to
- port_b. If the flow is reversed, then
- Q_flow=0.
+ The inlet time is approached as a fluid property and its propagation
+ follows the one-dimensional wave equation, implemented using the
+ spatialDistribution function. This components requires the mass flow
+ through the pipe and the pipe dimensions in order to derive
+ information about the fluid propagation.
- The outlet conditions at port_a are not affected by this
- model, other than for a possible pressure difference due to flow
- friction.
+ The component calculates the delay time at the inlet and the outlet
+ port of the pipe. For the forward flow, the time delay is exposed at
+ the output tau, and for the backward flow, the time
+ delay is exposed at the output tauRev.
+
+ Assumption
+
- If the parameter energyDynamics is different from
- Modelica.Fluid.Types.Dynamics.SteadyState, the component
- models the dynamic response using a first order differential
- equation. The time constant of the component is equal to the
- parameter tau. This time constant is adjusted based on
- the mass flow rate using
-
-
- τeff = τ |ṁ| ⁄ ṁnom
-
-
- where τeff is the effective time constant for the
- given mass flow rate ṁ and τ is the time constant at
- the nominal mass flow rate ṁnom. This type of
- dynamics is equal to the dynamics that a completely mixed control
- volume would have.
-
-
- Optionally, this model can have a flow resistance. Set
- dp_nominal = 0 to disable the flow friction calculation.
-
-
- For a similar model that is a heater, use AixLib.Fluid.HeatExchangers.Heater_T.
- For a model that uses a control signal u ∈ [0, 1] and
- multiplies this with the nominal heating or cooling power, use
- AixLib.Fluid.HeatExchangers.HeaterCooler_u.
-
-
- Limitations
-
-
- If the flow is from port_b to port_a, then
- the enthalpy of the medium is not affected by this model.
-
-
- This model does not affect the humidity of the air. Therefore, if
- used to cool air below the dew point temperature, the water mass
- fraction will not change.
-
-
- Validation
-
-
- The model has been validated against the analytical solution in the
- examples AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet
- and
- AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet_dynamic.
+ No axial mixing takes place in the pipe.
- - September 10, 2018, by Michael Wetter:
- Corrected missing propagation of initial conditions.
+ - December 2, 2020, by Philipp Mehrfeld:
+ Corrected calculation of tau and tauRev
+ to be be only positive.
This is for AixLib,
- #1016.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/1427\">#1427.
- - May 3, 2017, by Michael Wetter:
- First implementation.
+ - December 14, 2018, by Michael Wetter:
+ Corrected argument of spatialDistribution operator to
+ be a parameter expression.
This is for AixLib,
- #763.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/1055\">#1055.
+
+ - September 9, 2016 by Bram van der Heijde:
+ Rename from PDETime_massFlowMod to PlugFlowTransportDelayMod
+
+ - December 2015 by Carles Ribas Tugores:
+ Modification in delay calculation to fix issues.
+
+ - November 6, 2015 by Bram van der Heijde:
+ Adapted flow parameter to mass flow rate instead of velocity. This
+ change should also fix the reverse and zero flow issues.
+
+ - October 13, 2015 by Marcus Fuchs:
+ Use abs() of normalized velocity input in order to
+ avoid negative delay times.
+
+ - July 2015 by Arnout Aertgeerts:
+ First implementation.
-------- Errors --------
-line 29 column 2 - Warning: attribute "align" not allowed for HTML5
+line 7 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/EvaporatorCondenser.mo ----
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/GroundTemperatureResponse.mo ----
-------- HTML Code --------
- Model for a constant temperature evaporator or condenser based on a ε-NTU
- heat exchanger model.
+ This model calculates the ground temperature response to obtain the temperature
+ at the borehole wall in a geothermal system where heat is being injected into or
+ extracted from the ground.
- The heat exchanger effectiveness is calculated from the number of transfer units
- (NTU):
+ A load-aggregation scheme based on that developed by Claesson and Javed (2012) is
+ used to calculate the borehole wall temperature response with the temporal superposition
+ of ground thermal loads. In its base form, the
+ load-aggregation scheme uses fixed-length aggregation cells to agglomerate
+ thermal load history together, with more distant cells (denoted with a higher cell and vector index)
+ representing more distant thermal history. The more distant the thermal load, the
+ less impactful it is on the borehole wall temperature change at the current time step.
+ Each cell has an aggregation time associated to it denoted by nu,
+ which corresponds to the simulation time (since the beginning of heat injection or
+ extraction) at which the cell will begin shifting its thermal load to more distant
+ cells. To determine nu, cells have a temporal size rcel
+ (rcel in this model)
+ which follows the exponential growth
-
- ε = 1 - exp(UA ⁄ (ṁ cp))
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_02.png\")
- Optionally, this model can have a flow resistance.
- If no flow resistance is requested, set dp_nominal=0.
+ where nCel is the number of consecutive cells which can have the same size.
+ Decreasing rcel will generally decrease calculation times, at the cost of
+ precision in the temporal superposition. rcel is expressed in multiples
+ of the aggregation time resolution (via the parameter tLoaAgg).
+ Then, nu may be expressed as the sum of all rcel values
+ (multiplied by the aggregation time resolution) up to and including that cell in question.
- Limitations
- This model does not consider any superheating or supercooling on the refrigerant
- side. The refrigerant is considered to exchange heat at a constant temperature
- throughout the heat exchanger.
+ To determine the weighting factors, the borefield's temperature
+ step response at the borefield wall is determined as
+
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_03.png\")
-
-
- -
- March 7, 2022, by Michael Wetter:
- Removed massDynamics.
- This is for
- #1542.
-
- -
- May 27, 2017, by Filip Jorissen:
- Regularised heat transfer around zero flow.
- This is for
- #769.
-
- -
- April 12, 2017, by Michael Wetter:
- Corrected invalid syntax for computing the specific heat capacity.
- This is for
- #707.
-
- -
- October 11, 2016, by Massimo Cimmino:
- First implementation.
-
-
-
--------- Corrected Code --------
-
- Model for a constant temperature evaporator or condenser based on a
- ε-NTU heat exchanger model.
-
-
- The heat exchanger effectiveness is calculated from the number of
- transfer units (NTU):
-
-
- ε = 1 - exp(UA ⁄ (ṁ cp))
-
-
- Optionally, this model can have a flow resistance. If no flow
- resistance is requested, set dp_nominal=0.
-
-
- Limitations
-
-
- This model does not consider any superheating or supercooling on the
- refrigerant side. The refrigerant is considered to exchange heat at a
- constant temperature throughout the heat exchanger.
-
-
- - March 7, 2022, by Michael Wetter:
- Removed massDynamics.
- This is for #1542.
-
- - May 27, 2017, by Filip Jorissen:
- Regularised heat transfer around zero flow.
- This is for #769.
-
- - April 12, 2017, by Michael Wetter:
- Corrected invalid syntax for computing the specific heat
- capacity.
- This is for #707.
-
- - October 11, 2016, by Massimo Cimmino:
- First implementation.
-
-
-
--------- Errors --------
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/FixedResistances/Junction.mo ----
--------- HTML Code --------
-
- Model of a flow junction with an optional fixed resistance in each flow leg
- and an optional mixing volume at the junction.
+ where g(·) is the borefield's thermal response factor known as the g-function,
+ H is the total length of all boreholes and ks is the thermal
+ conductivity of the soil. The weighting factors kappa (κ in the equation below)
+ for a given cell i are then expressed as follows.
+
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_04.png\")
- The pressure drop is implemented using the model
-
- AixLib.Fluid.FixedResistances.PressureDrop.
- If its nominal pressure drop is set to zero, then the pressure drop
- model will be removed.
- For example, the pressure drop declaration
+ where ν refers to the vector nu in this model and
+ Tstep(ν0)=0.
-
- m_flow_nominal={ 0.1, 0.1, -0.2},
- dp_nominal = {500, 0, -6000}
-
- would model a flow mixer that has the nominal flow rates and associated pressure drops
- as shown in the figure below. Note that port_3 is set to negative values.
- The negative values indicate that at the nominal conditions, fluid is leaving the component.
+ At every aggregation time step, a time event is generated to perform the load aggregation steps.
+ First, the thermal load is shifted. When shifting between cells of different size, total
+ energy is conserved. This operation is illustred in the figure below by Cimmino (2014).
- ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/FixedResistances/Junction.png\"/)
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_01.png\")
- If
- energyDynamics <> Modelica.Fluid.Types.Dynamics.SteadyState,
- then at the flow junction, a fluid volume is modeled.
- The fluid volume is implemented using the model
-
- AixLib.Fluid.Delays.DelayFirstOrder.
- The fluid volume has the size
+ After the cell-shifting operation is performed, the first aggregation cell has its
+ value set to the average thermal load since the last aggregation step.
+ Temporal superposition is then applied by means
+ of a scalar product between the aggregated thermal loads QAgg_flow and the
+ weighting factors κ.
-
- V = sum(abs(m_flow_nominal[:])/3)*tau/rho_nominal
-
- where tau is a parameter and rho_nominal is the density
- of the medium in the volume at nominal condition.
- Setting energyDynamics=Modelica.Fluid.Types.Dynamics.FixedInitial
- can help reducing the size of the nonlinear
- system of equations.
+ Due to Modelica's variable time steps, the load aggregation scheme is modified by separating
+ the thermal response between the current aggregation time step and everything preceding it.
+ This is done according to
+
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_05.png\")
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_06.png\")
+
+
+ where Tb is the borehole wall temperature,
+ Tg
+ is the undisturbed ground temperature,
+ Q is the ground thermal load per borehole length and h = g/(2 π ks)
+ is a temperature response factor based on the g-function. tk
+ is the last discrete aggregation time step, meaning that the current time t
+ satisfies tk≤t≤tk+1.
+ Δtagg(=tk+1-tk) is the
+ parameter tLoaAgg in the present model.
+
+
+ Thus,
+ ΔTb*(t)
+ is the borehole wall temperature change due to the thermal history prior to the current
+ aggregation step. At every aggregation time step, load aggregation and temporal superposition
+ are used to calculate its discrete value. Assuming no heat injection or extraction until
+ tk+1, this term is assumed to have a linear
+ time derivative, which is given by the difference between ΔTb*(tk+1)
+ (the temperature change from load history at the next discrete aggregation time step, which
+ is constant over the duration of the ongoing aggregation time step) and the total
+ temperature change at the last aggregation time step, ΔTb(t).
+
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_09.png\")
+
+
+ The second term ΔTb,q(t) concerns the ongoing aggregation time step.
+ To obtain the time derivative of this term, the thermal response factor h is assumed
+ to vary linearly over the course of an aggregation time step. Therefore, because
+ the ongoing aggregation time step always concerns the first aggregation cell, its derivative (denoted
+ by the parameter dTStepdt in this model) can be calculated as
+ kappa[1], the first value in the kappa vector,
+ divided by the aggregation time step Δt.
+ The derivative of the temperature change at the borehole wall is then expressed
+ as the multiplication of dTStepdt (which only needs to be
+ calculated once at the start of the simulation) and the heat flow Q at
+ the borehole wall.
+
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_10.png\")
+
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_11.png\")
+
+
+ With the two terms in the expression of ΔTb(t) expressed
+ as time derivatives, ΔTb(t) can itself also be
+ expressed as its time derivative and implemented as such directly in the Modelica
+ equations block with the der() operator.
+
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_07.png\")
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_08.png\")
+
+
+ This load aggregation scheme is validated in
+
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.Validation.Analytic_20Years.
+
+ References
+
+ Cimmino, M. 2014. Développement et validation expérimentale de facteurs de réponse
+ thermique pour champs de puits géothermiques,
+ Ph.D. Thesis, École Polytechnique de Montréal.
+
+
+ Claesson, J. and Javed, S. 2012. A load-aggregation method to calculate extraction temperatures of borehole heat exchangers. ASHRAE Transactions 118(1): 530-539.
-
- April 14, 2020, by Michael Wetter:
- Changed homotopyInitialization to a constant.
- This is for
- IBPSA, #1341.
-
- -
- February 26, 2020, by Michael Wetter:
- Changed icon to display its operating state.
- This is for
- #1294.
-
- -
- March 26, 2018 by Filip Jorissen:
- Removed final allowFlowReversal=true from all resistances
- since this overrides the default simplification when the flow
- is not bidirectional.
- This change can lead to smaller algebraic loops.
- This is for
- issue 898.
-
- -
- December 1, 2016, by Michael Wetter:
- Renamed model from SplitterFixedResistanceDpM to
- FlowJunction and removed the parameters
- use_dh, dh and ReC.
- This is for
- issue 451.
-
- -
- October 14, 2016 by Michael Wetter:
- Added to Annex 60 library.
- Updated comment for parameter use_dh.
- This is for
- issue 451.
-
- -
- Removed parameter
dynamicBalance that overwrote the setting
- of energyDynamics and massDynamics.
- This is for
-
- Annex 60, issue 411.
-
- -
- February 1, 2012 by Michael Wetter:
- Expanded documentation.
-
- -
- August 4, 2011 by Michael Wetter:
- Added final allowFlowReversal=true to all resistances since it is impractical
- to avoid flow reversal in large flow networks where such a setting may be useful.
-
- -
- June 11, 2008 by Michael Wetter:
- Based class on
-
- AixLib.Fluid.BaseClasses.PartialThreeWayFixedResistance.
+ August 30, 2018, by Michael Wetter:
+ Refactored model to compute the temperature difference relative to the initial temperature,
+ because the model is independent of the initial temperature.
-
- July 20, 2007 by Michael Wetter:
+ April 5, 2018, by Alex Laferrière:
First implementation.
-------- Corrected Code --------
- Model of a flow junction with an optional fixed resistance in each
- flow leg and an optional mixing volume at the junction.
+ This model calculates the ground temperature response to obtain the
+ temperature at the borehole wall in a geothermal system where heat is
+ being injected into or extracted from the ground.
- The pressure drop is implemented using the model AixLib.Fluid.FixedResistances.PressureDrop.
- If its nominal pressure drop is set to zero, then the pressure drop
- model will be removed. For example, the pressure drop declaration
+ A load-aggregation scheme based on that developed by Claesson and
+ Javed (2012) is used to calculate the borehole wall temperature
+ response with the temporal superposition of ground thermal loads. In
+ its base form, the load-aggregation scheme uses fixed-length
+ aggregation cells to agglomerate thermal load history together, with
+ more distant cells (denoted with a higher cell and vector index)
+ representing more distant thermal history. The more distant the
+ thermal load, the less impactful it is on the borehole wall
+ temperature change at the current time step. Each cell has an
+ aggregation time associated to it denoted by
+ nu, which corresponds to the simulation time (since the
+ beginning of heat injection or extraction) at which the cell will
+ begin shifting its thermal load to more distant cells. To determine
+ nu, cells have a temporal size rcel
+ (rcel in this model) which follows the exponential
+ growth
+
+
+
-
- m_flow_nominal={ 0.1, 0.1, -0.2},
- dp_nominal = {500, 0, -6000}
-
- would model a flow mixer that has the nominal flow rates and
- associated pressure drops as shown in the figure below. Note that
- port_3 is set to negative values. The negative values
- indicate that at the nominal conditions, fluid is leaving the
- component.
+ where nCel is the number of consecutive cells which
+ can have the same size. Decreasing rcel will
+ generally decrease calculation times, at the cost of precision in the
+ temporal superposition. rcel is expressed in multiples
+ of the aggregation time resolution (via the parameter
+ tLoaAgg). Then, nu may be expressed as the
+ sum of all rcel values (multiplied by the aggregation
+ time resolution) up to and including that cell in question.
+
+
+ To determine the weighting factors, the borefield's temperature step
+ response at the borefield wall is determined as
+ \"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_03.png\">
- If energyDynamics <>
- Modelica.Fluid.Types.Dynamics.SteadyState, then at the flow
- junction, a fluid volume is modeled. The fluid volume is implemented
- using the model AixLib.Fluid.Delays.DelayFirstOrder.
- The fluid volume has the size
+ where g(·) is the borefield's thermal response factor known as
+ the g-function, H is the total length of all
+ boreholes and ks is the thermal conductivity of the
+ soil. The weighting factors kappa (κ in the
+ equation below) for a given cell i are then expressed as
+ follows.
+
+
+
-
- V = sum(abs(m_flow_nominal[:])/3)*tau/rho_nominal
-
- where tau is a parameter and rho_nominal is
- the density of the medium in the volume at nominal condition. Setting
- energyDynamics=Modelica.Fluid.Types.Dynamics.FixedInitial
- can help reducing the size of the nonlinear system of equations.
+ where ν refers to the vector nu in this model and
+ Tstep(ν0)=0.
-
- - April 14, 2020, by Michael Wetter:
- Changed homotopyInitialization to a constant.
- This is for IBPSA,
- #1341.
-
- - February 26, 2020, by Michael Wetter:
- Changed icon to display its operating state.
- This is for #1294.
-
- - March 26, 2018 by Filip Jorissen:
- Removed final allowFlowReversal=true from all
- resistances since this overrides the default simplification when
- the flow is not bidirectional. This change can lead to smaller
- algebraic loops. This is for issue 898.
-
- - December 1, 2016, by Michael Wetter:
- Renamed model from SplitterFixedResistanceDpM to
- FlowJunction and removed the parameters
- use_dh, dh and ReC.
- This is for issue 451.
-
- - October 14, 2016 by Michael Wetter:
- Added to Annex 60 library.
- Updated comment for parameter use_dh.
- This is for issue 451.
-
- - Removed parameter
dynamicBalance that overwrote the
- setting of energyDynamics and massDynamics.
- This is for Annex 60, issue
- 411.
-
- - February 1, 2012 by Michael Wetter:
- Expanded documentation.
-
- - August 4, 2011 by Michael Wetter:
- Added final allowFlowReversal=true to all resistances
- since it is impractical to avoid flow reversal in large flow
- networks where such a setting may be useful.
-
- - June 11, 2008 by Michael Wetter:
- Based class on
- AixLib.Fluid.BaseClasses.PartialThreeWayFixedResistance.
+
+ At every aggregation time step, a time event is generated to perform
+ the load aggregation steps. First, the thermal load is shifted. When
+ shifting between cells of different size, total energy is conserved.
+ This operation is illustred in the figure below by Cimmino (2014).
+
+
+
+
+
+ After the cell-shifting operation is performed, the first aggregation
+ cell has its value set to the average thermal load since the last
+ aggregation step. Temporal superposition is then applied by means of
+ a scalar product between the aggregated thermal loads
+ QAgg_flow and the weighting factors κ.
+
+
+ Due to Modelica's variable time steps, the load aggregation scheme is
+ modified by separating the thermal response between the current
+ aggregation time step and everything preceding it. This is done
+ according to
+
+
+
+
+
+
+
+ where Tb is the borehole wall temperature,
+ Tg is the undisturbed ground temperature, Q
+ is the ground thermal load per borehole length and h = g/(2 π
+ ks) is a temperature response factor based on the
+ g-function. tk is the last discrete aggregation
+ time step, meaning that the current time t satisfies
+ tk≤t≤tk+1.
+ Δtagg(=tk+1-tk) is the
+ parameter tLoaAgg in the present model.
+
+
+ Thus, ΔTb*(t) is the borehole wall temperature
+ change due to the thermal history prior to the current aggregation
+ step. At every aggregation time step, load aggregation and temporal
+ superposition are used to calculate its discrete value. Assuming no
+ heat injection or extraction until tk+1, this term
+ is assumed to have a linear time derivative, which is given by the
+ difference between ΔTb*(tk+1) (the
+ temperature change from load history at the next discrete aggregation
+ time step, which is constant over the duration of the ongoing
+ aggregation time step) and the total temperature change at the last
+ aggregation time step, ΔTb(t).
+
+
+
+
+
+ The second term ΔTb,q(t) concerns the ongoing
+ aggregation time step. To obtain the time derivative of this term,
+ the thermal response factor h is assumed to vary linearly over
+ the course of an aggregation time step. Therefore, because the
+ ongoing aggregation time step always concerns the first aggregation
+ cell, its derivative (denoted by the parameter dTStepdt
+ in this model) can be calculated as kappa[1], the first
+ value in the kappa vector, divided by the aggregation
+ time step Δt. The derivative of the temperature change at the
+ borehole wall is then expressed as the multiplication of
+ dTStepdt (which only needs to be calculated once at the
+ start of the simulation) and the heat flow Q at the borehole
+ wall.
+
+
+
+
+
+
+
+
+ With the two terms in the expression of ΔTb(t)
+ expressed as time derivatives, ΔTb(t) can itself
+ also be expressed as its time derivative and implemented as such
+ directly in the Modelica equations block with the der()
+ operator.
+
+
+
+
+
+
+
+ This load aggregation scheme is validated in
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.Validation.Analytic_20Years.
+
+
+ References
+
+
+ Cimmino, M. 2014. Développement et validation expérimentale de
+ facteurs de réponse thermique pour champs de puits géothermiques,
+ Ph.D. Thesis, École Polytechnique de Montréal.
+
+
+ Claesson, J. and Javed, S. 2012. A load-aggregation method to
+ calculate extraction temperatures of borehole heat exchangers.
+ ASHRAE Transactions 118(1): 530-539.
+
+
+ - August 30, 2018, by Michael Wetter:
+ Refactored model to compute the temperature difference relative to
+ the initial temperature, because the model is independent of the
+ initial temperature.
- - July 20, 2007 by Michael Wetter:
+ - April 5, 2018, by Alex Laferrière:
First implementation.
-------- Errors --------
-line 23 column 2 - Warning: attribute "align" not allowed for HTML5
+line 22 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 37 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 46 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 58 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 73 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 101 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 117 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 120 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 129 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/Movers/Validation/PowerSimplified.mo ----
+---- AixLib/Utilities/Math/Bicubic.mo ----
-------- HTML Code --------
- This example compares the power consumed by pumps that
- take three different control signals.
- Each pump has identical mass flow rate and pressure rise.
-
-
- Note that for the instances
-
- AixLib.Fluid.Movers.FlowControlled_dp
- and
-
- AixLib.Fluid.Movers.FlowControlled_m_flow,
- we had to assign the efficiencies (otherwise the default constant
- efficiency of 0.7 would have been used).
- In these models, the power consumption is computed
- using similarity laws, but using the mass flow rate as opposed
- to the speed, because speed is not known in these two models.
- This is an approximation at operating points in which
- the speed is different from the nominal speed N_nominal
- because similarity laws are valid for speed and not for
- mass flow rate.
-
-
- The figure below shows the approximation error for the
- power calculation where the speed Nrpm differs from
- the nominal speed Nnominal.
+ This block computes
-
- ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Movers/Validation/PowerSimplified.png\"/)
+
+ y = a1
+ + a2 x1 + a3 x12
+ + a4 x2 + a5 x22
+ + a6 x1 x2
+ + a7 x1^3
+ + a8 x2^3
+ + a9 x12 x2
+ + a10 x1 x22
-
- October 15, 2021, by Hongxiang Fu:
- Fixed the image in the documentation which was cut off
- at the y-axis. This is for
- IBPSA, #1533.
-
- -
- March 11, 2016, by Michael Wetter:
- Revised implementation by assigning the data record directly in the
- instances pump_dp and pump_m_flow, because
- using a parameter and assigning this parameter leads
- in OpenModelica to the error message
- expected subtype of record AixLib.Fluid.Movers.Data.Generic.
-
- -
- March 2, 2016, by Filip Jorissen:
- Revised implementation for
- #417.
-
- -
- November 5, 2015, by Michael Wetter:
- Changed parameters since the power is no longer a parameter for the movers
- that take mass flow rate or head as an input.
- This is for
- issue 457.
-
- -
- November 22, 2014, by Michael Wetter:
- Revised implementation.
+ Sep 17, 2010 by Michael Wetter:
+ First implementation.
-------- Corrected Code --------
- This example compares the power consumed by pumps that take three
- different control signals. Each pump has identical mass flow rate and
- pressure rise.
-
-
- Note that for the instances AixLib.Fluid.Movers.FlowControlled_dp
- and AixLib.Fluid.Movers.FlowControlled_m_flow,
- we had to assign the efficiencies (otherwise the default constant
- efficiency of 0.7 would have been used). In these models, the
- power consumption is computed using similarity laws, but using the
- mass flow rate as opposed to the speed, because speed is not known in
- these two models. This is an approximation at operating points in
- which the speed is different from the nominal speed
- N_nominal because similarity laws are valid for speed
- and not for mass flow rate.
-
-
- The figure below shows the approximation error for the power
- calculation where the speed Nrpm differs from the
- nominal speed Nnominal.
+ This block computes
-
-
+
+ y = a1 + a2 x1 + a3
+ x12 + a4 x2 +
+ a5 x22 + a6 x1
+ x2 + a7 x1^3 + a8
+ x2^3 + a9 x12
+ x2 + a10 x1
+ x22
- - October 15, 2021, by Hongxiang Fu:
- Fixed the image in the documentation which was cut off at the
- y-axis. This is for IBPSA,
- #1533.
-
- - March 11, 2016, by Michael Wetter:
- Revised implementation by assigning the data record directly in the
- instances pump_dp and pump_m_flow,
- because using a parameter and assigning this
- parameter leads in OpenModelica to the error message
- expected subtype of record
- AixLib.Fluid.Movers.Data.Generic.
-
- - March 2, 2016, by Filip Jorissen:
- Revised implementation for #417.
-
- - November 5, 2015, by Michael Wetter:
- Changed parameters since the power is no longer a parameter for the
- movers that take mass flow rate or head as an input. This is for
- issue
- 457.
-
- - November 22, 2014, by Michael Wetter:
- Revised implementation.
+ - Sep 17, 2010 by Michael Wetter:
+ First implementation.
-------- Errors --------
-line 29 column 2 - Warning: attribute "align" not allowed for HTML5
+line 5 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/ActiveBeams/Data/BaseClasses/TemperatureDifference.mo ----
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/Cylindrical.mo ----
-------- HTML Code --------
- Data record for performance data that describe the normalized
- temperature difference
- versus the change in the rate of heating or cooling.
- The normalized temperature difference is defined as
+ Model for radial heat transfer in a hollow cylinder.
+
+
+ If the heat capacity of the material is non-zero, then this model computes transient heat conduction, i.e., it
+ computes a numerical approximation to the solution of the heat equation
- rΔTi=
- ΔTi ⁄ ΔTnominal
- =
- (Twi-Tz)
- ⁄
- (Tw,nominal-Tz),
+ ρ c ( ∂ T(r,t) ⁄ ∂t ) =
+ k ( ∂² T(r,t) ⁄ ∂r² + 1 ⁄ r ∂ T(r,t) ⁄ ∂r ),
+
+
+ where
+ ρ
+ is the mass density,
+ c
+ is the specific heat capacity per unit mass,
+ T
+ is the temperature at location r and time t and
+ k is the heat conductivity.
+ At the locations r=ra and r=rb,
+ the temperature and heat flow rate are equal to the
+ temperature and heat flow rate of the heat ports.
+
+
+ If the heat capacity of the material is set to zero, then steady-state heat flow is computed using
+
+
+ Q = 2 π k (Ta-Tb)⁄ ln(ra ⁄ rb),
where
- Twi is the water inlet temperature,
- Tz is the zone air temperature and
- Tw,nominal is the nominal water inlet temperature.
+ ra is the internal radius,
+ rb is the external radius,
+ Ta is the temperature at port a and
+ Tb is the temperature at port b.
+ Implementation
- The normalized temperature difference rΔT must be strictly increasing, i.e.,
- rΔTi < rΔTi+1.
- Both vectors, rΔT and f
- must have the same size.
+ To spatially discretize the heat equation, the construction is
+ divided into compartments with nSta ≥ 1 state variables.
+ The state variables are connected to each other through thermal conductors.
+ There is also a thermal conductor
+ between the surfaces and the outermost state variables. Thus, to obtain
+ the surface temperature, use port_a.T (or port_b.T)
+ and not the variable T[1].
-
- June 13, 2016, by Michael Wetter:
- Revised implementation.
+ January, 2014, by Damien Picard:
+ Modify the discretization of the cilindrical layer so that the first three layers have an equal thickness the following an exponentionally growing thickness.
+ This follows the guidelines of Eskilson (P. Eskilson. Thermal analysis of heat extraction
+ boreholes. PhD thesis, Dep. of Mathematical
+ Physics, University of Lund, Sweden, 1987).
-
- May 20, 2016, by Alessandro Maccarini:
+ March 9, 2012, by Michael Wetter:
+ Removed protected variable der_T as it is not required.
+
+ -
+ April 14 2011, by Pierre Vigouroux:
First implementation.
-------- Corrected Code --------
- Data record for performance data that describe the normalized
- temperature difference versus the change in the rate of heating or
- cooling. The normalized temperature difference is defined as
+ Model for radial heat transfer in a hollow cylinder.
+
+
+ If the heat capacity of the material is non-zero, then this model
+ computes transient heat conduction, i.e., it computes a numerical
+ approximation to the solution of the heat equation
- rΔTi= ΔTi ⁄ ΔTnominal =
- (Twi-Tz) ⁄
- (Tw,nominal-Tz),
+ ρ c ( ∂ T(r,t) ⁄ ∂t ) = k ( ∂² T(r,t) ⁄ ∂r² + 1 ⁄ r ∂ T(r,t) ⁄
+ ∂r ),
- where Twi is the water inlet
- temperature, Tz is the zone air temperature and
- Tw,nominal is the nominal water inlet temperature.
+ where ρ is the mass density, c is the specific heat
+ capacity per unit mass, T is the temperature at location
+ r and time t and k is the heat conductivity. At
+ the locations r=ra and r=rb, the
+ temperature and heat flow rate are equal to the temperature and heat
+ flow rate of the heat ports.
- The normalized temperature difference rΔT must be
- strictly increasing, i.e., rΔTi <
- rΔTi+1. Both vectors, rΔT
- and f must have the same size.
+ If the heat capacity of the material is set to zero, then
+ steady-state heat flow is computed using
+
+
+ Q = 2 π k (Ta-Tb)⁄ ln(ra ⁄
+ rb),
+
+
+ where ra is the internal radius,
+ rb is the external radius, Ta is
+ the temperature at port a and Tb is the temperature
+ at port b.
+
+
+ Implementation
+
+
+ To spatially discretize the heat equation, the construction is
+ divided into compartments with nSta ≥ 1 state variables.
+ The state variables are connected to each other through thermal
+ conductors. There is also a thermal conductor between the surfaces
+ and the outermost state variables. Thus, to obtain the surface
+ temperature, use port_a.T (or port_b.T) and
+ not the variable T[1].
- - June 13, 2016, by Michael Wetter:
- Revised implementation.
+ - January, 2014, by Damien Picard:
+ Modify the discretization of the cilindrical layer so that the
+ first three layers have an equal thickness the following an
+ exponentionally growing thickness. This follows the guidelines of
+ Eskilson (P. Eskilson. Thermal analysis of heat extraction
+ boreholes. PhD thesis, Dep. of Mathematical Physics, University of
+ Lund, Sweden, 1987).
- - May 20, 2016, by Alessandro Maccarini:
+ - March 9, 2012, by Michael Wetter:
+ Removed protected variable der_T as it is not
+ required.
+
+ - April 14 2011, by Pierre Vigouroux:
First implementation.
-------- Errors --------
-line 8 column 2 - Warning: attribute "align" not allowed for HTML5
+line 9 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 29 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Controls/Discrete/BooleanDelay.mo ----
+---- AixLib/Fluid/HeatExchangers/BaseClasses/PartialEffectivenessNTU.mo ----
-------- HTML Code --------
- Block that delays the boolean input signal by
- one sampling interval.
- For example,
- if u denotes the input,
- y denotes the output, and
- ti and ti+1
- denote subsequent sampling
- instants, then the model outputs
+ Partial model of a heat exchanger without humidity condensation.
+ This model transfers heat in the amount of
- y(ti+1) = u(ti).
+ Q = Qmax ε
+ ε = f(NTU, Z, flowRegime),
+
+
+ where
+ Qmax is the maximum heat that can be transferred,
+ ε is the heat transfer effectiveness,
+ NTU is the Number of Transfer Units,
+ Z is the ratio of minimum to maximum capacity flow rate and
+ flowRegime is the heat exchanger flow regime.
+ such as
+ parallel flow, cross flow or counter flow.
+
+
+ The flow regimes depend on the heat exchanger configuration. All configurations
+ defined in
+
+ AixLib.Fluid.Types.HeatExchangerConfiguration
+ are supported.
+
+
+ Models that extend from this partial model need to provide an assignment
+ for UA.
-
- June 6, 2015, by Michael Wetter:
- Set start value and fixed attribute
- for firstTrigger
- to avoid a translation warning in pedantic mode
- in Dymola 2016.
+ February 25, 2021 by Baptiste Ravache:
+ Added a warning for when Q_flow_nominal is specified with the wrong sign.
+
+ -
+ January 10, 2018 by Michael Wetter:
+ Removed variable Z that is not used.
This is for
- #266.
+ issue 1328.
-
- November 21, 2011, by Michael Wetter:
- Improved documentation.
+ January 10, 2018 by Filip Jorissen:
+ Corrected an error where the value of NTU was assigned to Z.
+ This is for
+ issue 1328.
-
- November 26, 2008, by Michael Wetter:
+ February 27, 2016 by Michael Wetter:
+ Introduced sta1_default and sta2_default
+ to enable translation under OpenModelica.
+ Removed max=1 attribute for Z. This is needed as near
+ zero flow, Z can be larger than one due to the regularization.
+ As Z is not used in this model other than for reporting, this bound
+ need not be enforced (and the calculation of eps is fine at these small flow rates).
+ This is for
+ issue 490.
+
+ -
+ April 29, 2014 by Michael Wetter:
+ Changed assert statement to avoid comparing
+ enumeration with an integer, which triggers a warning
+ in Dymola 2015.
+
+ -
+ July 30, 2013 by Michael Wetter:
+ Updated model to use new variable mWat_flow
+ in the base class.
+
+ -
+ February 12, 2010, by Michael Wetter:
First implementation.
-------- Corrected Code --------
- Block that delays the boolean input signal by one sampling interval.
- For example, if u denotes the input, y denotes the
- output, and ti and ti+1 denote
- subsequent sampling instants, then the model outputs
+ Partial model of a heat exchanger without humidity condensation. This
+ model transfers heat in the amount of
- y(ti+1) = u(ti).
+ Q = Qmax ε
+ ε = f(NTU, Z, flowRegime),
-
- - June 6, 2015, by Michael Wetter:
- Set start value and fixed attribute for
- firstTrigger to avoid a translation warning in
- pedantic mode in Dymola 2016. This is for #266.
-
- - November 21, 2011, by Michael Wetter:
- Improved documentation.
-
- - November 26, 2008, by Michael Wetter:
+
+ where Qmax is the maximum heat that can be
+ transferred, ε is the heat transfer effectiveness, NTU
+ is the Number of Transfer Units, Z is the ratio of minimum to
+ maximum capacity flow rate and flowRegime is the heat
+ exchanger flow regime. such as parallel flow, cross flow or counter
+ flow.
+
+
+ The flow regimes depend on the heat exchanger configuration. All
+ configurations defined in AixLib.Fluid.Types.HeatExchangerConfiguration
+ are supported.
+
+
+ Models that extend from this partial model need to provide an
+ assignment for UA.
+
+
+ - February 25, 2021 by Baptiste Ravache:
+ Added a warning for when Q_flow_nominal is specified with the wrong
+ sign.
+
+ - January 10, 2018 by Michael Wetter:
+ Removed variable Z that is not used. This is for
+ issue
+ 1328.
+
+ - January 10, 2018 by Filip Jorissen:
+ Corrected an error where the value of NTU was assigned to Z. This
+ is for issue
+ 1328.
+
+ - February 27, 2016 by Michael Wetter:
+ Introduced sta1_default and sta2_default
+ to enable translation under OpenModelica. Removed
+ max=1 attribute for Z. This is needed as
+ near zero flow, Z can be larger than one due to the
+ regularization. As Z is not used in this model other
+ than for reporting, this bound need not be enforced (and the
+ calculation of eps is fine at these small flow rates).
+ This is for issue
+ 490.
+
+ - April 29, 2014 by Michael Wetter:
+ Changed assert statement to avoid comparing
+ enumeration with an integer, which triggers a warning in Dymola
+ 2015.
+
+ - July 30, 2013 by Michael Wetter:
+ Updated model to use new variable mWat_flow in the
+ base class.
+
+ - February 12, 2010, by Michael Wetter:
First implementation.
-------- Errors --------
-line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+line 6 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Utilities/Math/Functions/quadraticLinear.mo ----
+---- AixLib/Fluid/HeatExchangers/ActiveBeams/BaseClasses/Convector.mo ----
-------- HTML Code --------
- This function computes
+
+ In cooling mode, this model adds heat to the water stream. The heat added is equal to:
+
- y = a1 + a2 x1
- + a3 x12
- + (a4 + a5 x1
- + a6 x12) x2
+ QBeam = Qrated fΔT fSA fW
+
+
+ In heating mode, the heat is removed from the water stream.
-
- February 29, 2009 by Michael Wetter:
+ March 3, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for
+ issue 1542.
+
+ -
+ April 14, 2020, by Michael Wetter:
+ Changed homotopyInitialization to a constant.
+ This is for
+ IBPSA, #1341.
+
+ -
+ November 2, 2016, by Michael Wetter:
+ Made assignment of senTem.y final.
+
+ -
+ June 13, 2016, by Michael Wetter:
+ Revised implementation.
+
+ -
+ May 20, 2016, by Alessandro Maccarini:
First implementation.
-------- Corrected Code --------
-This function computes
+
+ In cooling mode, this model adds heat to the water stream. The heat
+ added is equal to:
+
- y = a1 + a2 x1 + a3
- x12 + (a4 + a5
- x1 + a6 x12)
- x2
+ QBeam = Qrated fΔT
+ fSA fW
+
+
+ In heating mode, the heat is removed from the water stream.
- - February 29, 2009 by Michael Wetter:
+ - March 3, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for issue
+ 1542.
+
+ - April 14, 2020, by Michael Wetter:
+ Changed homotopyInitialization to a constant.
+ This is for IBPSA,
+ #1341.
+
+ - November 2, 2016, by Michael Wetter:
+ Made assignment of senTem.y final.
+
+ - June 13, 2016, by Michael Wetter:
+ Revised implementation.
+
+ - May 20, 2016, by Alessandro Maccarini:
First implementation.
-------- Errors --------
-line 3 column 2 - Warning: attribute "align" not allowed for HTML5
+line 5 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Media/Air.mo ----
+---- AixLib/Fluid/FixedResistances/Junction.mo ----
-------- HTML Code --------
- Model with basic thermodynamic properties.
+ Model of a flow junction with an optional fixed resistance in each flow leg
+ and an optional mixing volume at the junction.
- This model provides equation for the following thermodynamic properties:
+ The pressure drop is implemented using the model
+
+ AixLib.Fluid.FixedResistances.PressureDrop.
+ If its nominal pressure drop is set to zero, then the pressure drop
+ model will be removed.
+ For example, the pressure drop declaration
-
- | Variable |
- Unit |
- Description |
- | T |
- K |
- temperature |
- | p |
- Pa |
- absolute pressure |
- | d |
- kg/m3 |
- density |
- | h |
- J/kg |
- specific enthalpy |
- | u |
- J/kg |
- specific internal energy |
- | Xi[nXi] |
- kg/kg |
- independent mass fractions m_i/m |
- | R |
- J/kg.K |
- gas constant |
- | M |
- kg/mol |
- molar mass |
-
-
-
- -
- September 22, 2020, by Michael Wetter:
- First implementation based on Modelica Standard Library,
- but with noEvent added to check of bounds.
-
-
-
- Density is computed from pressure, temperature and composition in the thermodynamic state record applying the ideal gas law.
-
+
+ m_flow_nominal={ 0.1, 0.1, -0.2},
+ dp_nominal = {500, 0, -6000}
+
- This function returns the dynamic viscosity.
+ would model a flow mixer that has the nominal flow rates and associated pressure drops
+ as shown in the figure below. Note that port_3 is set to negative values.
+ The negative values indicate that at the nominal conditions, fluid is leaving the component.
- Implementation
-
- The function is based on the 5th order polynomial
- of
-
- Modelica.Media.Air.MoistAir.dynamicViscosity.
- However, for the typical range of temperatures encountered
- in building applications, a linear function sufficies.
- This implementation is therefore the above 5th order polynomial,
- linearized around 20°C.
- The relative error of this linearization is
- 0.4% at -20°C,
- and less then
- 0.2% between -5°C and +50°C.
+
+
-
-
- -
- December 19, 2013, by Michael Wetter:
- First implementation.
-
-
-
- The ideal gas constant for moist air is computed from thermodynamic state assuming that all water is in the gas phase.
-
- Pressure is returned from the thermodynamic state record input as a simple assignment.
-
- This function returns the isobaric expansion coefficient at constant pressure,
- which is zero for this medium.
- The isobaric expansion coefficient at constant pressure is
-
-
- βp = - 1 ⁄ v (∂ v ⁄ ∂ T)p = 0,
+ If
+ energyDynamics <> Modelica.Fluid.Types.Dynamics.SteadyState,
+ then at the flow junction, a fluid volume is modeled.
+ The fluid volume is implemented using the model
+
+ AixLib.Fluid.Delays.DelayFirstOrder.
+ The fluid volume has the size
+
+ V = sum(abs(m_flow_nominal[:])/3)*tau/rho_nominal
+
- where
- v is the specific volume,
- T is the temperature and
- p is the pressure.
+ where tau is a parameter and rho_nominal is the density
+ of the medium in the volume at nominal condition.
+ Setting energyDynamics=Modelica.Fluid.Types.Dynamics.FixedInitial
+ can help reducing the size of the nonlinear
+ system of equations.
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ April 14, 2020, by Michael Wetter:
+ Changed homotopyInitialization to a constant.
+ This is for
+ IBPSA, #1341.
-
-
-
- This function returns the isothermal compressibility coefficient.
- The isothermal compressibility is
-
-
- κT = -1 ⁄ v (∂ v ⁄ ∂ p)T
- = -1 ⁄ p,
-
-
- where
- v is the specific volume,
- T is the temperature and
- p is the pressure.
-
-
-
- -
- December 18, 2013, by Michael Wetter:
- First implementation.
-
-
-
-
- This function computes the specific entropy.
-
-
- The specific entropy of the mixture is obtained from
-
-
- s = ss + sm,
-
-
- where
- ss is the entropy change due to the state change
- (relative to the reference temperature) and
- sm is the entropy change due to mixing
- of the dry air and water vapor.
-
-
- The entropy change due to change in state is obtained from
-
-
- ss = cv ln(T/T0) + R ln(v/v0)
- = cv ln(T/T0) + R ln(ρ0/ρ)
-
- If we assume ρ = p0/(R T),
- and because cp = cv + R,
- we can write
-
-
- ss = cv ln(T/T0) + R ln(T/T0)
- =cp ln(T/T0).
-
-
- Next, the entropy of mixing is obtained from a reversible isothermal
- expansion process. Hence,
-
-
- sm = -R ∑i( Xi ⁄ Mi
- ln(Yi p/p0)),
-
-
- where R is the gas constant,
- X is the mass fraction,
- M is the molar mass, and
- Y is the mole fraction.
-
-
- To obtain the state for a given pressure, entropy and mass fraction, use
-
- AixLib.Media.Air.setState_psX.
-
- Limitations
-
- This function is only valid for a relative humidity below 100%.
-
-
-
- -
- November 27, 2013, by Michael Wetter:
- First implementation.
-
-
-
-
- This function returns the partial derivative of density
- with respect to pressure at constant temperature.
-
-
-
- -
- December 18, 2013, by Michael Wetter:
- First implementation.
-
-
-
-
- This function computes the derivative of density with respect to temperature
- at constant pressure.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ February 26, 2020, by Michael Wetter:
+ Changed icon to display its operating state.
+ This is for
+ #1294.
-
-
-
- This function returns the partial derivative of density
- with respect to mass fraction.
- This value is zero because in this medium, density is proportional
- to pressure, but independent of the species concentration.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ March 26, 2018 by Filip Jorissen:
+ Removed final allowFlowReversal=true from all resistances
+ since this overrides the default simplification when the flow
+ is not bidirectional.
+ This change can lead to smaller algebraic loops.
+ This is for
+ issue 898.
-
-
-
- The thermodynamic state record
- is computed from density d, temperature T and composition X.
-
-
- The
- thermodynamic state record is computed from pressure p, specific enthalpy h and composition X.
-
- The
- thermodynamic state record is computed from pressure p, temperature T and composition X.
-
-
- This function returns the thermodynamic state based on pressure,
- specific entropy and mass fraction.
-
-
- The state is computed by symbolically solving
-
- AixLib.Media.Air.specificEntropy
- for temperature.
-
-
-
-
- November 27, 2013, by Michael Wetter:
- First implementation.
+ December 1, 2016, by Michael Wetter:
+ Renamed model from SplitterFixedResistanceDpM to
+ FlowJunction and removed the parameters
+ use_dh, dh and ReC.
+ This is for
+ issue 451.
-
-
- Specific enthalpy as a function of temperature and species concentration.
- The pressure is input for compatibility with the medium models, but the specific enthalpy
- is independent of the pressure.
-
-
-
- April 30, 2015, by Filip Jorissen and Michael Wetter:
- Added Inline=true for
-
- issue 227.
+ October 14, 2016 by Michael Wetter:
+ Added to Annex 60 library.
+ Updated comment for parameter use_dh.
+ This is for
+ issue 451.
-
-
-
- This function computes the specific enthalpy for
- an isentropic state change from the temperature
- that corresponds to the state refState
- to reference_T.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ Removed parameter dynamicBalance that overwrote the setting
+ of energyDynamics and massDynamics.
+ This is for
+
+ Annex 60, issue 411.
-
-
- Temperature is returned from the thermodynamic state record input as a simple assignment.
-
-
- This function returns the molar mass.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ February 1, 2012 by Michael Wetter:
+ Expanded documentation.
-
-
- Temperature as a function of specific enthalpy and species concentration.
- The pressure is input for compatibility with the medium models, but the temperature
- is independent of the pressure.
-
-
-
- April 30, 2015, by Filip Jorissen and Michael Wetter:
- Added Inline=true for
-
- issue 227.
+ August 4, 2011 by Michael Wetter:
+ Added final allowFlowReversal=true to all resistances since it is impractical
+ to avoid flow reversal in large flow networks where such a setting may be useful.
-
-
-
- This data record contains the coefficients for perfect gases.
-
-
-
-
- September 12, 2014, by Michael Wetter:
- Corrected the wrong location of the preferredView
- and the revisions annotation.
+ June 11, 2008 by Michael Wetter:
+ Based class on
+
+ AixLib.Fluid.BaseClasses.PartialThreeWayFixedResistance.
-
- November 21, 2013, by Michael Wetter:
+ July 20, 2007 by Michael Wetter:
First implementation.
+-------- Corrected Code --------
+
+ Model of a flow junction with an optional fixed resistance in each
+ flow leg and an optional mixing volume at the junction.
+
+
+ The pressure drop is implemented using the model AixLib.Fluid.FixedResistances.PressureDrop.
+ If its nominal pressure drop is set to zero, then the pressure drop
+ model will be removed. For example, the pressure drop declaration
+
+
+ m_flow_nominal={ 0.1, 0.1, -0.2},
+ dp_nominal = {500, 0, -6000}
+
+
+ would model a flow mixer that has the nominal flow rates and
+ associated pressure drops as shown in the figure below. Note that
+ port_3 is set to negative values. The negative values
+ indicate that at the nominal conditions, fluid is leaving the
+ component.
+
+
+
+
+
+ If energyDynamics <>
+ Modelica.Fluid.Types.Dynamics.SteadyState, then at the flow
+ junction, a fluid volume is modeled. The fluid volume is implemented
+ using the model AixLib.Fluid.Delays.DelayFirstOrder.
+ The fluid volume has the size
+
+
+ V = sum(abs(m_flow_nominal[:])/3)*tau/rho_nominal
+
+
+ where tau is a parameter and rho_nominal is
+ the density of the medium in the volume at nominal condition. Setting
+ energyDynamics=Modelica.Fluid.Types.Dynamics.FixedInitial
+ can help reducing the size of the nonlinear system of equations.
+
+
+ - April 14, 2020, by Michael Wetter:
+ Changed homotopyInitialization to a constant.
+ This is for IBPSA,
+ #1341.
+
+ - February 26, 2020, by Michael Wetter:
+ Changed icon to display its operating state.
+ This is for #1294.
+
+ - March 26, 2018 by Filip Jorissen:
+ Removed final allowFlowReversal=true from all
+ resistances since this overrides the default simplification when
+ the flow is not bidirectional. This change can lead to smaller
+ algebraic loops. This is for issue 898.
+
+ - December 1, 2016, by Michael Wetter:
+ Renamed model from SplitterFixedResistanceDpM to
+ FlowJunction and removed the parameters
+ use_dh, dh and ReC.
+ This is for issue 451.
+
+ - October 14, 2016 by Michael Wetter:
+ Added to Annex 60 library.
+ Updated comment for parameter use_dh.
+ This is for issue 451.
+
+ - Removed parameter
dynamicBalance that overwrote the
+ setting of energyDynamics and massDynamics.
+ This is for Annex 60, issue
+ 411.
+
+ - February 1, 2012 by Michael Wetter:
+ Expanded documentation.
+
+ - August 4, 2011 by Michael Wetter:
+ Added final allowFlowReversal=true to all resistances
+ since it is impractical to avoid flow reversal in large flow
+ networks where such a setting may be useful.
+
+ - June 11, 2008 by Michael Wetter:
+ Based class on
+ AixLib.Fluid.BaseClasses.PartialThreeWayFixedResistance.
+
+ - July 20, 2007 by Michael Wetter:
+ First implementation.
+
+
+
+-------- Errors --------
+line 23 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Media/Water.mo ----
+-------- HTML Code --------
+
- This medium package models moist air using a gas law in which pressure and temperature
- are independent, which often leads to significantly faster and more robust computations.
- The specific heat capacities at constant pressure and at constant volume are constant.
- The air is assumed to be not saturated.
-
-
- This medium uses the gas law
-
-
- ρ/ρstp = p/pstp,
-
-
- where
- pstd and ρstp are constant reference
- temperature and density, rathern than the ideal gas law
-
-
- ρ = p ⁄(R T),
-
-
- where R is the gas constant and T is the temperature.
-
-
- This formulation often leads to smaller systems of nonlinear equations
- because equations for pressure and temperature are decoupled.
- Therefore, if air inside a control volume such as room air is heated, it
- does not increase its specific volume. Consequently, merely heating or cooling
- a control volume does not affect the air flow calculations in a duct network
- that may be connected to that volume.
- Note that multizone air exchange simulation in which buoyancy drives the
- air flow is still possible as the models in
-
- AixLib.Airflow.Multizone compute the mass density using the function
-
- AixLib.Utilities.Psychrometrics.Functions.density_pTX in which density
- is a function of temperature.
-
-
- Note that models in this package implement the equation for the internal energy as
+ Model with basic thermodynamic properties.
-
- u = h - pstp ⁄ ρstp,
+
+ This base properties model is identical to
+
+ Modelica.Media.Water.ConstantPropertyLiquidWater,
+ except that the equation
+ u = cv_const*(T - reference_T)
+ has been replaced by u=h because
+ cp_const=cv_const.
- where
- u is the internal energy per unit mass,
- h is the enthalpy per unit mass,
- pstp is the static pressure and
- ρstp is the mass density at standard pressure and temperature.
- The reason for this implementation is that in general,
+ This model provides equation for the following thermodynamic properties:
-
- h = u + p v,
+
+ | Variable |
+ Unit |
+ Description |
+ | T |
+ K |
+ temperature |
+ | p |
+ Pa |
+ absolute pressure |
+ | d |
+ kg/m3 |
+ density |
+ | h |
+ J/kg |
+ specific enthalpy |
+ | u |
+ J/kg |
+ specific internal energy |
+ | Xi[nXi] |
+ kg/kg |
+ independent mass fractions m_i/m |
+ | R |
+ J/kg.K |
+ gas constant |
+ | M |
+ kg/mol |
+ molar mass |
+
+
+
+ Enthalpy of the water.
+
+
+
- from which follows that
+ This medium package models liquid water.
-
- u = h - p v = h - p ⁄ ρ = h - pstp ⁄ ρstd,
+
+ The mass density is computed using a constant value of 995.586 kg/s.
+ For a medium model in which the density is a function of temperature, use
+
+ AixLib.Media.Specialized.Water.TemperatureDependentDensity which may have considerably higher computing time.
- because p ⁄ ρ = pstp ⁄ ρstp in this medium model.
+ For the specific heat capacities at constant pressure and at constant volume,
+ a constant value of 4184 J/(kg K), which corresponds to 20°C
+ is used.
+ The figure below shows the relative error of the specific heat capacity that
+ is introduced by this simplification.
+
+
+ ![\"Relative](\"modelica://AixLib/Resources/Images/Media/Water/plotCp.png\")
The enthalpy is computed using the convention that h=0
- if T=0 °C and no water vapor is present.
+ if T=0 °C.
+
+ Limitations
+
+ Density, specific heat capacity, thermal conductivity and viscosity are constant.
+ Water is modeled as an incompressible liquid.
+ There are no phase changes.
-
- January 11, 2019 by Michael Wetter:
- Reforulated assignment of X_int in setState_psX.
- This is for
- #1079.
-
- -
October 26, 2018, by Filip Jorissen and Michael Wetter:
Now printing different messages if temperature is above or below its limit,
and adding instance name as JModelica does not print the full instance name in the assertion.
@@ -4526,24 +4249,31 @@ line 3 column 2 - Warning: attribute "align" not allowed for HTML5
#1045.
-
- November 4, 2016, by Michael Wetter:
- Set default value for dT.start in base properties.
- This is for
- #575.
-
- -
June 6, 2015, by Michael Wetter:
Set AbsolutePressure(start=p_default) to avoid
a translation error if
AixLib.Fluid.Sources.Examples.TraceSubstancesFlowSource
+ (if used with water instead of air)
is translated in pedantic mode in Dymola 2016.
The reason is that pressures use Medium.p_default as start values,
but
Modelica.Media.Interfaces.Types
sets a default value of 1E-5.
- A similar change has been done for pressure.
+ A similar change has been done for pressure and density.
+ This fixes
+ #266.
+
+ -
+ June 6, 2015, by Michael Wetter:
+ Changed type of BaseProperties.T from
+ Modelica.Units.SI.Temperature to Temperature.
+ Otherwise, it has a different start value than Medium.T, which
+ causes an error if
+
+ AixLib.Media.Examples.WaterProperties
+ is translated in pedantic mode.
This fixes
#266.
@@ -4553,102 +4283,43 @@ line 3 column 2 - Warning: attribute "align" not allowed for HTML5
to allow correct use of preferredMediumState as
described in
- Modelica.Media.Interfaces.PartialMedium.
- Note that the default is preferredMediumState=false
- and hence the same states are used as were used before.
+ Modelica.Media.Interfaces.PartialMedium,
+ and set preferredMediumState=false
+ to keep the same states as were used before.
This is for
#260.
-
- May 11, 2015, by Michael Wetter:
- Removed
- p(stateSelect=if preferredMediumStates then StateSelect.prefer else StateSelect.default)
- in declaration of BaseProperties.
- Otherwise, when models that contain a fluid volume
- are exported as an FMU, their pressure would be
- differentiated with respect to time. This would require
- the time derivative of the inlet pressure, which is not available,
- causing the translation to stop with an error.
-
- -
- May 1, 2015, by Michael Wetter:
+ June 5, 2015, by Michael Wetter:
+ Removed ThermodynamicState declaration as this lead to
+ the error
+ \"Attempting to redeclare record ThermodynamicState when the original was not replaceable.\"
+ in Dymola 2016 using the pedantic model check.
+
+ -
+ May 1, 2015, by Michael Wetter:
Added Inline=true for
issue 227.
-
- March 20, 2015, by Michael Wetter:
- Added missing term state.p/reference_p in function
- specificEntropy.
- #193.
-
- -
- February 3, 2015, by Michael Wetter:
- Removed stateSelect.prefer for temperature.
- This is for
- #160.
-
- -
- July 24, 2014, by Michael Wetter:
- Changed implementation to use
-
- AixLib.Utilities.Psychrometrics.Constants.
- This was done to use consistent values throughout the library.
-
- -
- November 16, 2013, by Michael Wetter:
- Revised and simplified the implementation.
-
- -
- November 14, 2013, by Michael Wetter:
- Removed function
- HeatCapacityOfWater
- which is neither needed nor implemented in the
- Modelica Standard Library.
-
- -
- November 13, 2013, by Michael Wetter:
- Removed non-used computations in specificEnthalpy_pTX and
- in temperature_phX.
-
- -
- March 29, 2013, by Michael Wetter:
- Added final standardOrderComponents=true in the
- BaseProperties declaration. This avoids an error
- when models are checked in Dymola 2014 in the pedenatic mode.
-
- -
- April 12, 2012, by Michael Wetter:
- Added keyword each to Xi(stateSelect=...).
-
- -
- April 4, 2012, by Michael Wetter:
- Added redeclaration of ThermodynamicState to avoid a warning
- during model check and translation.
-
- -
- August 3, 2011, by Michael Wetter:
- Fixed bug in u=h-R*T, which is only valid for ideal gases.
- For this medium, the function is u=h-pStd/dStp.
-
- -
- January 27, 2010, by Michael Wetter:
- Fixed bug in else branch of function setState_phX
- that lead to a run-time error when the constructor of this function was called.
-
- -
- January 22, 2010, by Michael Wetter:
- Added implementation of function
-
- enthalpyOfNonCondensingGas and its derivative.
+ February 25, 2015, by Michael Wetter:
+ Removed stateSelect attribute on pressure as this caused
+
+ AixLib.Examples.Tutorial.SpaceCooling.System3
+ to fail with the error message
+ \"differentiated if-then-else was not continuous\".
-
- January 13, 2010, by Michael Wetter:
- Fixed implementation of derivative functions.
+ October 15, 2014, by Michael Wetter:
+ Reimplemented media based on
+ 446aa83.
-
- August 28, 2008, by Michael Wetter:
- First implementation.
+ November 15, 2013, by Michael Wetter:
+ Complete new reimplementation because the previous version
+ had the option to add a compressibility to the medium, which
+ has never been used.
@@ -4656,6 +4327,13 @@ line 3 column 2 - Warning: attribute "align" not allowed for HTML5
Model with basic thermodynamic properties.
+
+ This base properties model is identical to Modelica.Media.Water.ConstantPropertyLiquidWater,
+ except that the equation u = cv_const*(T - reference_T)
+ has been replaced by u=h because
+ cp_const=cv_const.
+
This model provides equation for the following thermodynamic
properties:
@@ -4762,2985 +4440,2880 @@ line 3 column 2 - Warning:
attribute "align" not allowed for HTML5
-
- This function returns the isobaric expansion coefficient at constant
- pressure, which is zero for this medium. The isobaric expansion
- coefficient at constant pressure is
-
-
- This function returns the isothermal compressibility coefficient. The
- isothermal compressibility is
-
-
- Next, the entropy of mixing is obtained from a reversible isothermal
- expansion process. Hence,
-
-
- This function returns the partial derivative of density with respect
- to pressure at constant temperature.
+ Density, specific heat capacity, thermal conductivity and viscosity
+ are constant. Water is modeled as an incompressible liquid. There are
+ no phase changes.
- This function computes the derivative of density with respect to
- temperature at constant pressure.
-
-
- This function returns the partial derivative of density with respect
- to mass fraction. This value is zero because in this medium, density
- is proportional to pressure, but independent of the species
- concentration.
-
-
- This function returns the thermodynamic state based on pressure,
- specific entropy and mass fraction.
-
-
- This function computes the specific enthalpy for an isentropic state
- change from the temperature that corresponds to the state
- refState to reference_T.
-
- element is obsolete in HTML5
+
+
+line 18 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Actuators/BaseClasses/exponentialDamper.mo ----
+-------- HTML Code --------
+
+
+ This function computes the opening characteristics of an exponential damper.
+
+ The function is used by the model
+
+ AixLib.Fluid.Actuators.Dampers.Exponential.
+
+ For yL < y < yU, the damper characteristics is
+
+
+ kd(y) = exp(a+b (1-y)).
+
+
+ Outside this range, the damper characteristic is defined by a quadratic polynomial.
+
+
+ Note that this implementation returns sqrt(kd(y)) instead of kd(y).
+ This is done for numerical reason since otherwise kd(y) may be an iteration
+ variable, which may cause a lot of warnings and slower convergence if the solver
+ attempts kd(y) < 0 during the iterative solution procedure.
+
+
+
+ -
+ April 14, 2014 by Michael Wetter:
+ Improved documentation.
+
+ -
+ July 1, 2011 by Michael Wetter:
+ Added constraint to control input to avoid using a number outside
+ 0 and 1 in case that the control input
+ has a numerical integration error.
+
+ -
+ April 4, 2010 by Michael Wetter:
+ Reformulated implementation. The new implementation computes
+ sqrt(kTheta). This avoid having kTheta in
+ the iteration variables, which caused warnings when the solver attempted
+ kTheta < 0.
+
+ -
+ June 22, 2008 by Michael Wetter:
+ First implementation.
+
+
+
+-------- Corrected Code --------
- This medium package models moist air using a gas law in which
- pressure and temperature are independent, which often leads to
- significantly faster and more robust computations. The specific heat
- capacities at constant pressure and at constant volume are constant.
- The air is assumed to be not saturated.
-
-
- This medium uses the gas law
-
-
- ρ/ρstp = p/pstp,
-
-
- where pstd and ρstp are constant
- reference temperature and density, rathern than the ideal gas law
-
-
- ρ = p ⁄(R T),
-
-
- where R is the gas constant and T is the temperature.
-
-
- This formulation often leads to smaller systems of nonlinear
- equations because equations for pressure and temperature are
- decoupled. Therefore, if air inside a control volume such as room air
- is heated, it does not increase its specific volume. Consequently,
- merely heating or cooling a control volume does not affect the air
- flow calculations in a duct network that may be connected to that
- volume. Note that multizone air exchange simulation in which buoyancy
- drives the air flow is still possible as the models in AixLib.Airflow.Multizone
- compute the mass density using the function AixLib.Utilities.Psychrometrics.Functions.density_pTX
- in which density is a function of temperature.
-
-
- Note that models in this package implement the equation for the
- internal energy as
-
-
- u = h - pstp ⁄ ρstp,
+ This function computes the opening characteristics of an exponential
+ damper.
- where u is the internal energy per unit mass, h is the
- enthalpy per unit mass, pstp is the static pressure
- and ρstp is the mass density at standard pressure
- and temperature. The reason for this implementation is that in
- general,
-
-
- h = u + p v,
+ The function is used by the model AixLib.Fluid.Actuators.Dampers.Exponential.
- from which follows that
+ For yL < y < yU, the damper characteristics is
- u = h - p v = h - p ⁄ ρ = h - pstp ⁄ ρstd,
+ kd(y) = exp(a+b (1-y)).
- because p ⁄ ρ = pstp ⁄ ρstp in this
- medium model.
+ Outside this range, the damper characteristic is defined by a
+ quadratic polynomial.
- The enthalpy is computed using the convention that h=0 if
- T=0 °C and no water vapor is present.
+ Note that this implementation returns sqrt(kd(y))
+ instead of kd(y). This is done for numerical reason
+ since otherwise kd(y) may be an iteration variable,
+ which may cause a lot of warnings and slower convergence if the
+ solver attempts kd(y) < 0 during the iterative
+ solution procedure.
- - September 28, 2020, by Michael Wetter:
- Reformulated BaseProperties to avoid event-triggering
- assertions.
- This is for #1401.
-
- - January 11, 2019 by Michael Wetter:
- Reforulated assignment of X_int in
- setState_psX.
- This is for #1079.
-
- - October 26, 2018, by Filip Jorissen and Michael Wetter:
- Now printing different messages if temperature is above or below
- its limit, and adding instance name as JModelica does not print the
- full instance name in the assertion. This is for #1045.
-
- - November 4, 2016, by Michael Wetter:
- Set default value for dT.start in base properties.
- This is for #575.
-
- - June 6, 2015, by Michael Wetter:
- Set AbsolutePressure(start=p_default) to avoid a
- translation error if
- AixLib.Fluid.Sources.Examples.TraceSubstancesFlowSource is
- translated in pedantic mode in Dymola 2016. The reason is that
- pressures use Medium.p_default as start values, but
- Modelica.Media.Interfaces.Types
- sets a default value of 1E-5. A similar change has been done
- for pressure. This fixes #266.
-
- - June 5, 2015, by Michael Wetter:
- Added stateSelect attribute in
- BaseProperties.T to allow correct use of
- preferredMediumState as described in Modelica.Media.Interfaces.PartialMedium.
- Note that the default is preferredMediumState=false
- and hence the same states are used as were used before. This is for
- #260.
-
- - May 11, 2015, by Michael Wetter:
- Removed p(stateSelect=if preferredMediumStates then
- StateSelect.prefer else StateSelect.default) in declaration
- of BaseProperties. Otherwise, when models that contain
- a fluid volume are exported as an FMU, their pressure would be
- differentiated with respect to time. This would require the time
- derivative of the inlet pressure, which is not available, causing
- the translation to stop with an error.
-
- - May 1, 2015, by Michael Wetter:
- Added Inline=true for issue 227.
-
- - March 20, 2015, by Michael Wetter:
- Added missing term state.p/reference_p in function
- specificEntropy. #193.
-
- - February 3, 2015, by Michael Wetter:
- Removed stateSelect.prefer for temperature. This is
- for #160.
-
- - July 24, 2014, by Michael Wetter:
- Changed implementation to use AixLib.Utilities.Psychrometrics.Constants.
- This was done to use consistent values throughout the library.
-
- - November 16, 2013, by Michael Wetter:
- Revised and simplified the implementation.
-
- - November 14, 2013, by Michael Wetter:
- Removed function HeatCapacityOfWater which is neither
- needed nor implemented in the Modelica Standard Library.
-
- - November 13, 2013, by Michael Wetter:
- Removed non-used computations in specificEnthalpy_pTX
- and in temperature_phX.
-
- - March 29, 2013, by Michael Wetter:
- Added final standardOrderComponents=true in the
- BaseProperties declaration. This avoids an error when
- models are checked in Dymola 2014 in the pedenatic mode.
-
- - April 12, 2012, by Michael Wetter:
- Added keyword each to
- Xi(stateSelect=...).
-
- - April 4, 2012, by Michael Wetter:
- Added redeclaration of ThermodynamicState to avoid a
- warning during model check and translation.
-
- - August 3, 2011, by Michael Wetter:
- Fixed bug in u=h-R*T, which is only valid for ideal
- gases. For this medium, the function is u=h-pStd/dStp.
-
- - January 27, 2010, by Michael Wetter:
- Fixed bug in else branch of function
- setState_phX that lead to a run-time error when the
- constructor of this function was called.
+ - April 14, 2014 by Michael Wetter:
+ Improved documentation.
- - January 22, 2010, by Michael Wetter:
- Added implementation of function
- enthalpyOfNonCondensingGas and its derivative.
+ - July 1, 2011 by Michael Wetter:
+ Added constraint to control input to avoid using a number outside
+ 0 and 1 in case that the control input
+ has a numerical integration error.
- - January 13, 2010, by Michael Wetter:
- Fixed implementation of derivative functions.
+ - April 4, 2010 by Michael Wetter:
+ Reformulated implementation. The new implementation computes
+ sqrt(kTheta). This avoid having kTheta in
+ the iteration variables, which caused warnings when the solver
+ attempted kTheta < 0.
- - August 28, 2008, by Michael Wetter:
+ - June 22, 2008 by Michael Wetter:
First implementation.
-------- Errors --------
-line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-
-
-line 7 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
-line 6 column 2 - Warning:
attribute "align" not allowed for HTML5
-
-
-line 8 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 21 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 29 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 37 column 2 - Warning:
attribute "align" not allowed for HTML5
-
-
line 11 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 19 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 43 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 54 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 60 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/BaseClasses/WetCoilWetRegime.mo ----
+---- AixLib/Fluid/Movers/BaseClasses/Characteristics/efficiency.mo ----
-------- HTML Code --------
-
- -
- Jan 21, 2021, by Donghun Kim:
First implementation.
-
-
-
-
- This model implements the calculation for a 100% wet coil.
-
-
- The equations from Braun (1988) and Mitchell and Braun (2012a and b),
- which are essentially the extension of the ε-NTU approach to
- simultaneous sensible and latent heat transfer, are utilized.
-
-
- The mathematical equations are analogous to that of the sensible heat exchanger.
- However, the key distinction is that the heat transfer is driven by an enthalpy difference
- not by an temperature difference. This change in the driving potential results in re-defining
- capacitances and heat transfer coefficients accordingly.
-
-
-
- The total heat transfer rate is expressed as
-
-
- Qtot=ε* C*min
- (hair,in-hsat(Twat,in)),
-
-
- where ε*=f(Cr*,NTU*) and f is the same ε-NTU relationships
- (depending on the heat exchanger configuration) for the sensible heat exchanger.
-
-
- hair,in and hsat(Twat,in) are
- the specific enthalpies of the incoming moist air and saturated moist air
- at the water inlet temperature.
-
-
- The capacitances of water and air streams are defined as
-
- C*air=mair and
- C*wat=mwatcp,wat/csat,
-
-
- where csat is an specific heat capacity, which indicates the sensitivity
- of the enthalpy of the staturated moist air w.r.t. the temperature, and is defined
- here as csat=(hsat(Twat,out)-hsat(Twat,in))
- /(Twat,out-Twat,in).
-
- The capacitance ratio and minimum capacitance are naturally defined as
-
- Cr*=min(C*air,C*wat)/max(C*air,C*wat)
- and C*min=min(C*air,C*wat).
-
-
- The number of transfer unit for the wet-coil is defined as NTU*=UA*/C*min, where
-
-
- UA*=1/(1/(UAair/cp,air)+1/(UAwat/csat).
+ This function computes the fan or pump efficiency for given normalized volume flow rate
+ and performance data. The efficiency is
-
- References
-
- Braun, James E. 1988.
- "Methodologies for the Design and Control of Central Cooling Plants".
- PhD Thesis. University of Wisconsin - Madison.
- Available
-
- online.
+
+ η = s(V̇/rN, d),
- Mitchell, John W., and James E. Braun. 2012a.
- Principles of heating, ventilation, and air conditioning in buildings.
- Hoboken, N.J.: Wiley.
+ where
+ η is the efficiency,
+ rN is the normalized fan speed,
+ V̇ is the volume flow rate, and
+ d are performance data for fan or pump efficiency.
+ Implementation
- Mitchell, John W., and James E. Braun. 2012b.
- "Supplementary Material Chapter 2: Heat Exchangers for Cooling Applications".
- Excerpt from Principles of heating, ventilation, and air conditioning in buildings.
- Hoboken, N.J.: Wiley.
- Available
-
- online.
+ The function s(·, ·) is a cubic hermite spline.
+ If the data d define a monotone decreasing sequence, then
+ s(·, d) is a monotone decreasing function.
--------- Corrected Code --------
-
- - Jan 21, 2021, by Donghun Kim:
- First implementation.
-
-
-
- This model implements the calculation for a 100% wet coil.
-
-
- The equations from Braun (1988) and Mitchell and Braun (2012a and b),
- which are essentially the extension of the ε-NTU approach to
- simultaneous sensible and latent heat transfer, are utilized.
-
-
- The mathematical equations are analogous to that of the sensible heat
- exchanger. However, the key distinction is that the heat transfer is
- driven by an enthalpy difference not by an temperature difference.
- This change in the driving potential results in re-defining
- capacitances and heat transfer coefficients accordingly.
-
-
- The total heat transfer rate is expressed as
-
-
- Qtot=ε* C*min
- (hair,in-hsat(Twat,in)),
-
-
- where ε*=f(Cr*,NTU*) and f is the same ε-NTU
- relationships (depending on the heat exchanger configuration) for the
- sensible heat exchanger.
-
-
- hair,in and
- hsat(Twat,in) are the specific
- enthalpies of the incoming moist air and saturated moist air at the
- water inlet temperature.
-
-
- The capacitances of water and air streams are defined as
-
-
- C*air=mair and
- C*wat=mwatcp,wat/csat,
-
-
- where csat is an specific heat capacity, which indicates the
- sensitivity of the enthalpy of the staturated moist air w.r.t. the
- temperature, and is defined here as
- csat=(hsat(Twat,out)-hsat(Twat,in))
- /(Twat,out-Twat,in).
-
+
+ -
+ December 2, 2016, by Michael Wetter:
+ Removed min attribute as otherwise numerical noise can cause
+ the assertion on the limit to fail.
+ This is for
+ #606.
+
+ -
+ November 22, 2014, by Michael Wetter:
+ Corrected documentation as curve uses V̇
+ as an independent variable.
+
+ -
+ September 30, 2014, by Filip Jorissen:
+ Changed polynomial to be evaluated at V_flow
+ instead of r_V.
+
+ -
+ April 19, 2014, by Filip Jorissen:
+ Changed polynomial to be evaluated at r_V/r_N
+ instead of r_V to properly account for the
+ scaling law. See
+ #202
+ for a discussion and validation.
+
+ -
+ September 28, 2011, by Michael Wetter:
+ First implementation.
+
+
+
+-------- Corrected Code --------
- The capacitance ratio and minimum capacitance are naturally defined
- as
+ This function computes the fan or pump efficiency for given
+ normalized volume flow rate and performance data. The efficiency is
-
- Cr*=min(C*air,C*wat)/max(C*air,C*wat)
- and C*min=min(C*air,C*wat).
+
+ η = s(V̇/rN, d),
-
- The number of transfer unit for the wet-coil is defined as
- NTU*=UA*/C*min, where
-
-
- UA*=1/(1/(UAair/cp,air)+1/(UAwat/csat).
+ where η is the efficiency, rN is the
+ normalized fan speed, V̇ is the volume flow rate, and d
+ are performance data for fan or pump efficiency.
- References
+ Implementation
- Braun, James E. 1988. \"Methodologies for the Design and Control of
- Central Cooling Plants\". PhD Thesis. University of Wisconsin -
- Madison. Available online.
-
-
- Mitchell, John W., and James E. Braun. 2012a. Principles of heating,
- ventilation, and air conditioning in buildings. Hoboken, N.J.: Wiley.
-
-
- Mitchell, John W., and James E. Braun. 2012b. \"Supplementary Material
- Chapter 2: Heat Exchangers for Cooling Applications\". Excerpt from
- Principles of heating, ventilation, and air conditioning in
- buildings. Hoboken, N.J.: Wiley. Available
- online.
+ The function s(·, ·) is a cubic hermite spline. If the data
+ d define a monotone decreasing sequence, then s(·, d)
+ is a monotone decreasing function.
+
+ - December 2, 2016, by Michael Wetter:
+ Removed min attribute as otherwise numerical noise can
+ cause the assertion on the limit to fail.
+ This is for #606.
+
+ - November 22, 2014, by Michael Wetter:
+ Corrected documentation as curve uses V̇ as an independent
+ variable.
+
+ - September 30, 2014, by Filip Jorissen:
+ Changed polynomial to be evaluated at V_flow instead
+ of r_V.
+
+ - April 19, 2014, by Filip Jorissen:
+ Changed polynomial to be evaluated at r_V/r_N instead
+ of r_V to properly account for the scaling law. See
+ #202
+ for a discussion and validation.
+
+ - September 28, 2011, by Michael Wetter:
+ First implementation.
+
+
-------- Errors --------
-line 20 column 2 - Warning: attribute "align" not allowed for HTML5
-line 36 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 48 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 54 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 6 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/Humidifiers/Humidifier_u.mo ----
+---- AixLib/Fluid/HeatExchangers/ActiveBeams/Data/BaseClasses/TemperatureDifference.mo ----
-------- HTML Code --------
- Model for an air humidifier or dehumidifier.
-
-
- This model adds (or removes) moisture from the air stream.
- The amount of exchanged moisture is equal to
+ Data record for performance data that describe the normalized
+ temperature difference
+ versus the change in the rate of heating or cooling.
+ The normalized temperature difference is defined as
- ṁwat = u ṁwat,nom,
+ rΔTi=
+ ΔTi ⁄ ΔTnominal
+ =
+ (Twi-Tz)
+ ⁄
+ (Tw,nominal-Tz),
- where u is the control input signal and
- ṁwat,nom is equal to the parameter mWat_flow_nominal.
- The parameter mWat_flow_nominal can be positive or negative.
- If ṁwat is positive, then moisture is added
- to the air stream, otherwise it is removed.
+ where
+ Twi is the water inlet temperature,
+ Tz is the zone air temperature and
+ Tw,nominal is the nominal water inlet temperature.
- If the heat port heatPort is unconnected, then the enthalpy of the
- air that flows through the device remains unchanged, e.g., the humidification
- is adiabatic. To change the enthalpy of the air, add heat flow to the connector
- heatPort.
+ The normalized temperature difference rΔT must be strictly increasing, i.e.,
+ rΔTi < rΔTi+1.
+ Both vectors, rΔT and f
+ must have the same size.
-
- March 7, 2022, by Michael Wetter:
- Removed massDynamics.
- This is for
- #1542.
-
- -
- April 12, 2017, by Michael Wetter:
- Removed parameters use_T_in and T.
- This removes the optional specification of temperature through the parameter T
- or the input connector T_in.
- Exposed the heat port of the control volume to allow adding heat,
- for example, to use the model as a steam humidifier.
- This is for issue
-
- Buildings #704.
-
- -
- May 6, 2015, by Michael Wetter:
- Set prescribedHeatFlowRate=true.
- This is for issue
-
- #412.
-
- -
- May 29, 2014, by Michael Wetter:
- Removed undesirable annotation Evaluate=true.
-
- -
- February 11, 2014 by Michael Wetter:
- Corrected issue #197
- which led to twice the amount of latent heat being added to the fluid stream.
-
- -
- October 14, 2013 by Michael Wetter:
- Constrained medium to be a subclass of
- Modelica.Media.Interfaces.PartialCondensingGases,
- as this base class declares the function
- enthalpyOfCondensingGas.
-
- -
- July 30, 2013 by Michael Wetter:
- Updated model to use new variable mWat_flow
- in the base class.
-
- -
- May 24, 2011, by Michael Wetter:
- Changed base class to allow using the model as a dynamic or a steady-state model.
-
- -
- April 14, 2010, by Michael Wetter:
- Converted temperature input to a conditional connector.
+ June 13, 2016, by Michael Wetter:
+ Revised implementation.
-
- April 17, 2008, by Michael Wetter:
+ May 20, 2016, by Alessandro Maccarini:
First implementation.
-------- Corrected Code --------
- Model for an air humidifier or dehumidifier.
-
-
- This model adds (or removes) moisture from the air stream. The amount
- of exchanged moisture is equal to
+ Data record for performance data that describe the normalized
+ temperature difference versus the change in the rate of heating or
+ cooling. The normalized temperature difference is defined as
- ṁwat = u ṁwat,nom,
+ rΔTi= ΔTi ⁄ ΔTnominal =
+ (Twi-Tz) ⁄
+ (Tw,nominal-Tz),
- where u is the control input signal and
- ṁwat,nom is equal to the parameter
- mWat_flow_nominal. The parameter
- mWat_flow_nominal can be positive or negative. If
- ṁwat is positive, then moisture is added to the
- air stream, otherwise it is removed.
+ where Twi is the water inlet
+ temperature, Tz is the zone air temperature and
+ Tw,nominal is the nominal water inlet temperature.
- If the heat port heatPort is unconnected, then the
- enthalpy of the air that flows through the device remains unchanged,
- e.g., the humidification is adiabatic. To change the enthalpy of the
- air, add heat flow to the connector heatPort.
+ The normalized temperature difference rΔT must be
+ strictly increasing, i.e., rΔTi <
+ rΔTi+1. Both vectors, rΔT
+ and f must have the same size.
- - March 7, 2022, by Michael Wetter:
- Removed massDynamics.
- This is for #1542.
-
- - April 12, 2017, by Michael Wetter:
- Removed parameters use_T_in and T. This
- removes the optional specification of temperature through the
- parameter T or the input connector T_in.
- Exposed the heat port of the control volume to allow adding heat,
- for example, to use the model as a steam humidifier.
- This is for issue Buildings
- #704.
-
- - May 6, 2015, by Michael Wetter:
- Set prescribedHeatFlowRate=true. This is for issue
- #412.
-
- - May 29, 2014, by Michael Wetter:
- Removed undesirable annotation Evaluate=true.
-
- - February 11, 2014 by Michael Wetter:
- Corrected issue #197
- which led to twice the amount of latent heat being added to the
- fluid stream.
-
- - October 14, 2013 by Michael Wetter:
- Constrained medium to be a subclass of
- Modelica.Media.Interfaces.PartialCondensingGases, as
- this base class declares the function
- enthalpyOfCondensingGas.
-
- - July 30, 2013 by Michael Wetter:
- Updated model to use new variable mWat_flow in the
- base class.
-
- - May 24, 2011, by Michael Wetter:
- Changed base class to allow using the model as a dynamic or a
- steady-state model.
-
- - April 14, 2010, by Michael Wetter:
- Converted temperature input to a conditional connector.
+ - June 13, 2016, by Michael Wetter:
+ Revised implementation.
- - April 17, 2008, by Michael Wetter:
+ - May 20, 2016, by Alessandro Maccarini:
First implementation.
-------- Errors --------
-line 9 column 2 - Warning: attribute "align" not allowed for HTML5
+line 8 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/Actuators/BaseClasses/exponentialDamper.mo ----
+---- AixLib/Fluid/FixedResistances/BaseClasses/PlugFlow.mo ----
-------- HTML Code --------
+
+ -
+ October 20, 2017, by Michael Wetter:
+ Deleted various parameters and variables that were not used.
+
+ Revised documentation to follow the guidelines.
+
+ -
+ May 19, 2016 by Marcus Fuchs:
+ Remove condition on show_V_flow for calculation of
+ V_flow to conform with pedantic checking.
+
+ -
+ October 10, 2015 by Marcus Fuchs:
+ Copy Icon from KUL implementation and rename model.
+
+ -
+ June 23, 2015 by Marcus Fuchs:
+ First implementation.
+
+
+
- This function computes the opening characteristics of an exponential damper.
-
- The function is used by the model
-
- AixLib.Fluid.Actuators.Dampers.Exponential.
-
- For yL < y < yU, the damper characteristics is
+ Model that computes the temperature propagation of
+ a fluid flow through a pipe, idealized as a plug flow.
+ Main equation
+
+ The transport delay is computed using the one-dimensional wave equation
+ without source or sink terms,
- kd(y) = exp(a+b (1-y)).
+ ∂z(x,t)/∂t + v(t) ∂z(x,t)/∂x = 0,
-
- Outside this range, the damper characteristic is defined by a quadratic polynomial.
+
where z(x,t) is the spatial distribution as a function of time of any
+ property z of the fluid.
+ For the temperature propagation, z will be replaced by T.
+ Assumptions
- Note that this implementation returns sqrt(kd(y)) instead of kd(y).
- This is done for numerical reason since otherwise kd(y) may be an iteration
- variable, which may cause a lot of warnings and slower convergence if the solver
- attempts kd(y) < 0 during the iterative solution procedure.
+ This model is based on the following assumptions:
-
-
- April 14, 2014 by Michael Wetter:
- Improved documentation.
-
- -
- July 1, 2011 by Michael Wetter:
- Added constraint to control input to avoid using a number outside
- 0 and 1 in case that the control input
- has a numerical integration error.
-
- -
- April 4, 2010 by Michael Wetter:
- Reformulated implementation. The new implementation computes
- sqrt(kTheta). This avoid having kTheta in
- the iteration variables, which caused warnings when the solver attempted
- kTheta < 0.
+ Axial diffusion in water is assumed to be negligibe.
-
- June 22, 2008 by Michael Wetter:
- First implementation.
+ The water temperature is assumed uniform in a cross section.
-------- Corrected Code --------
+
+ - October 20, 2017, by Michael Wetter:
+ Deleted various parameters and variables that were not used.
+ Revised documentation to follow the guidelines.
+
+ - May 19, 2016 by Marcus Fuchs:
+ Remove condition on show_V_flow for calculation of
+ V_flow to conform with pedantic checking.
+
+ - October 10, 2015 by Marcus Fuchs:
+ Copy Icon from KUL implementation and rename model.
+
+ - June 23, 2015 by Marcus Fuchs:
+ First implementation.
+
+
- This function computes the opening characteristics of an exponential
- damper.
-
-
- The function is used by the model AixLib.Fluid.Actuators.Dampers.Exponential.
+ Model that computes the temperature propagation of a fluid flow
+ through a pipe, idealized as a plug flow.
+
+ Main equation
+
- For yL < y < yU, the damper characteristics is
+ The transport delay is computed using the one-dimensional wave
+ equation without source or sink terms,
- kd(y) = exp(a+b (1-y)).
+ ∂z(x,t)/∂t + v(t) ∂z(x,t)/∂x = 0,
- Outside this range, the damper characteristic is defined by a
- quadratic polynomial.
+ where z(x,t) is the spatial distribution as a function of time
+ of any property z of the fluid. For the temperature
+ propagation, z will be replaced by T.
+
+ Assumptions
+
- Note that this implementation returns sqrt(kd(y))
- instead of kd(y). This is done for numerical reason
- since otherwise kd(y) may be an iteration variable,
- which may cause a lot of warnings and slower convergence if the
- solver attempts kd(y) < 0 during the iterative
- solution procedure.
+ This model is based on the following assumptions:
- - April 14, 2014 by Michael Wetter:
- Improved documentation.
-
- - July 1, 2011 by Michael Wetter:
- Added constraint to control input to avoid using a number outside
- 0 and 1 in case that the control input
- has a numerical integration error.
-
- - April 4, 2010 by Michael Wetter:
- Reformulated implementation. The new implementation computes
- sqrt(kTheta). This avoid having kTheta in
- the iteration variables, which caused warnings when the solver
- attempted kTheta < 0.
+ - Axial diffusion in water is assumed to be negligibe.
- - June 22, 2008 by Michael Wetter:
- First implementation.
+ - The water temperature is assumed uniform in a cross section.
-------- Errors --------
-line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+line 10 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/Actuators/BaseClasses/PartialDamperExponential.mo ----
+---- AixLib/Fluid/FMI/ExportContainers/HVACZones.mo ----
-------- HTML Code --------
- Partial model for air dampers with exponential opening characteristics.
- This is the base model for air dampers.
- The model implements the functions that relate the opening signal and the
- flow coefficient.
- The model also defines parameters that are used by different air damper
- models.
+ Model that is used as a container for an HVAC system that is
+ to be exported as an FMU and that serves multiple zones.
+ Typical use and important parameters
- The model is as in ASHRAE 825-RP except that a control signal of
- y=0 means the damper is closed, and y=1 means
- the damper is open.
- This is opposite of the implementation of ASHRAE 825-RP, but used here
- for consistency within this library.
+ To use this model as a container for an FMU, simply extend
+ from this model, rather than instantiate it,
+ and add your HVAC system. By extending from this model, the top-level
+ signal connectors on the right stay at the top-level, and hence
+ will be visible at the FMI interface.
+ The example
+
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZones
+ shows how a simple HVAC system that serves two rooms can be implemented and exported as
+ an FMU.
+
- For yL < y < yU, the damper characteristics is:
-
-
- kd(y) = exp(a+b (1-y))
+ The following two parameters need to be assigned by the user:
+ Set nZon to the number of thermal zones to which the
+ FMU will be connected.
+ Set nPorts to the largest number of fluid ports
+ that the thermal zones has. For example,
+ if nZon=2 and zone 1 has one inlet and one outlet
+ (hence it has 2 ports),
+ and zone 2 has one inlets and two outlets
+ (hence it has 3 ports), then
+ set nPorts=3. This will add more fluid ports than are needed
+ for zone 1, but this causes no overhead if they are not connected.
- where kd is the loss coefficient (total pressure drop divided
- by dynamic pressure) and y is the fractional opening.
+ The conversion between the fluid ports and signal ports is done
+ in the HVAC adapter hvacAda.
+ This adapter has a vector of fluid ports called ports.
+ The supply and return air ducts, including any resistance model for the inlet
+ diffusor or exhaust grill, need to be connected to these ports.
+ Also, if a thermal zone has interzonal air exchange or air infiltration,
+ these flows need to be connected to ports.
+ This model outputs at the port fluPor the mass flow rate for
+ each flow that is connected to ports, together with its
+ temperature, water vapor mass fraction per total mass of the air (not per kg dry
+ air), and trace substances. These quantities are always as if the flow
+ enters the room, even if the flow is zero or negative.
+ If a medium has no moisture, e.g., if Medium.nXi=0, or
+ if it has no trace substances, e.g., if Medium.nC=0, then
+ the output signal for these properties are removed.
+ These quantities are always as if the flow
+ enters the room, even if the flow is zero or negative.
+ Thus, a thermal zone model that uses these signals to compute the
+ heat added by the HVAC system need to implement an equation such as
-
- Outside this range, the damper characteristics is defined by a quadratic polynomial that
- matches the damper resistance at y=0 and y=yL or
- y=yU and y=1, respectively.
- In addition, the polynomials are such that kd(y) is differentiable in
- y and the derivative is continuous.
+
+ Qsen = max(0, ṁsup) cp (Tsup - Tair,zon),
- The damper characteristics is then used to compute the flow coefficient k(y) as:
+ where
+ Qsen is the sensible heat flow rate added to the thermal zone,
+ ṁsup is the supply air mass flow rate from
+ the port fluPor (which is negative if it is an exhaust),
+ cp is the specific heat capacity at constant pressure,
+ Tsup is the supply air temperature and
+ Tair,zon is the zone air temperature.
+ Note that without the max(·, ·), the energy
+ balance would be wrong.
-
- k(y) = (2 ρ ⁄ kd(y))1/2 A
+
+
+ The input signals of this model are the radiative temperature of each zone.
+ The the zone air temperatures,
+ the water vapor mass fractions per total mass of the air (unless Medium.nXi=0)
+ and trace substances (unless Medium.nC=0) are obtained from the connector
+ fluPor.backward.
+ The outflowing fluid stream(s) at the port ports will be at the
+ states obtained from fluPor.backward.
+ For any given izon ∈ {1, ..., nzon},
+ for each iports ∈ {1, ..., nports}
+ all fluid streams at port ports[izon, iports] are at the same
+ pressure.
+ For convenience, the instance hvacAda also outputs the
+ properties obtained from fluPor.backward. These can be used
+ to connect a controller. The properties are available for each flow path in
+ fluPor.backward. For a thermal zone with mixed air, these are
+ all equal, while for a stratified room model, they can be different.
- where A is the face area, which is computed using the nominal
- mass flow rate m_flow_nominal, the nominal velocity
- v_nominal and the density of the medium.
+ See
+
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZones
+ for a model that uses this model.
- ASHRAE 825-RP lists the following parameter values as typical (note that the
- default values in the model correspond to opposed blades).
-
+ For models that only have one thermal zone connected to the HVAC system,
+ use the simpler model
+
+ AixLib.Fluid.FMI.ExportContainers.HVACZone.
-
-
- | opposed blades | single blades |
-
-
- | yL | 15/90 | 15/90 |
-
-
- | yU | 55/90 | 65/90 |
-
-
- | k1 | 0.2 to 0.5 | 0.2 to 0.5 |
-
-
- | a | -1.51 | -1.51 |
-
-
- | b | 0.105*90 | 0.0842*90 |
-
-
+ Assumption and limitations
- (The loss coefficient in fully closed position k0 is computed based on the leakage coefficient
- and the coefficient in fully open position.)
+ The mass flow rates at ports sum to zero, hence this
+ model conserves mass for each thermal zone.
- References
- P. Haves, L. K. Norford, M. DeSimone and L. Mei,
- A Standard Simulation Testbed for the Evaluation of Control Algorithms & Strategies,
- ASHRAE Final Report 825-RP, Atlanta, GA.
+ This model does not impose any pressure, other than,
+ for any given izon ∈ {1, ..., nzon} and
+ for each j,k ∈ {1, ..., nports},
+ setting the pressure of ports[izon, j].p = ports[izon, k].p
+ to be the same.
+ The reason is that setting a pressure can lead to non-physical system models,
+ for example if a mass flow rate is imposed and the HVAC system is connected
+ to a model that sets a pressure boundary condition such as
+
+ AixLib.Fluid.Sources.Outside.
+ Also, setting a pressure would make it impossible to use multiple instances
+ of this model (one for each thermal zone) and build in Modelica an airflow network
+ model with pressure driven mass flow rates.
+
+
+ The model has no pressure drop. Hence, the pressure drop
+ of an air diffuser or of an exhaust grill needs to be modelled
+ in models that are connected to ports.
-
- September 21, 2021, by Michael Wetter:
- Corrected typo in comments.
- This is for
- #1525.
-
- -
- December 23, 2019, by Antoine Gautier:
- Removed the equations involving m_flow and dp that now need
- to be added in each derived damper model.
- Added the declaration of dpDamper_nominal and dpFixed_nominal.
- Replaced k0 by leakage coefficient.
- Modified the limiting values for k0 and k1.
- This is for
- #1188.
-
- -
- March 22, 2017, by Michael Wetter:
- Added back v_nominal, but set the assignment of A
- to be final. This allows scaling the model with m_flow_nominal,
- which is generally known in the flow leg,
- and v_nominal, for which a default value can be specified.
- This is for
- #544.
-
- -
- October 12, 2016 by David Blum:
- Removed parameter v_nominal and variable area,
- to simplify parameterization of the model.
- Also added assertion statements upon initialization
- for parameters k0 and k1 so that they fall within
- suggested ranges found in ASHRAE 825-RP. This is for
- #544.
-
- -
- January 27, 2015 by Michael Wetter:
- Set Evaluate=true for use_constant_density.
- This is a structural parameter. Adding this annotation leads to fewer
- numerical Jacobians for
- Buildings.Examples.VAVReheat.ClosedLoop
- with
- Buildings.Media.PerfectGases.MoistAirUnsaturated.
-
- -
- December 14, 2012 by Michael Wetter:
- Renamed protected parameters for consistency with the naming conventions.
-
- -
- January 16, 2012 by Michael Wetter:
- To simplify object inheritance tree, revised base classes
- AixLib.Fluid.BaseClasses.PartialResistance,
- AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve,
- AixLib.Fluid.Actuators.BaseClasses.PartialDamperExponential,
- AixLib.Fluid.Actuators.BaseClasses.PartialActuator
- and model
- AixLib.Fluid.FixedResistances.PressureDrop.
-
- -
- August 5, 2011, by Michael Wetter:
- Moved linearized pressure drop equation from the function body to the equation
- section. With the previous implementation,
- the symbolic processor may not rearrange the equations, which can lead
- to coupled equations instead of an explicit solution.
-
- -
- June 22, 2008 by Michael Wetter:
- Extended range of control signal from 0 to 1 by implementing the function
-
- exponentialDamper.
+ January 18, 2019, by Jianjun Hu:
+ Limited the media choice to moist air only.
+ See #1050.
-
- June 10, 2008 by Michael Wetter:
+ May 25, 2016, by Michael Wetter:
First implementation.
-------- Corrected Code --------
- Partial model for air dampers with exponential opening
- characteristics. This is the base model for air dampers. The model
- implements the functions that relate the opening signal and the flow
- coefficient. The model also defines parameters that are used by
- different air damper models.
+ Model that is used as a container for an HVAC system that is to be
+ exported as an FMU and that serves multiple zones.
+
+ Typical use and important parameters
+
- The model is as in ASHRAE 825-RP except that a control signal of
- y=0 means the damper is closed, and y=1
- means the damper is open. This is opposite of the implementation of
- ASHRAE 825-RP, but used here for consistency within this library.
+ To use this model as a container for an FMU, simply extend from this
+ model, rather than instantiate it, and add your HVAC system. By
+ extending from this model, the top-level signal connectors on the
+ right stay at the top-level, and hence will be visible at the FMI
+ interface. The example
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZones shows
+ how a simple HVAC system that serves two rooms can be implemented and
+ exported as an FMU.
- For yL < y < yU, the damper characteristics is:
-
-
- kd(y) = exp(a+b (1-y))
+ The following two parameters need to be assigned by the user: Set
+ nZon to the number of thermal zones to which the FMU
+ will be connected. Set nPorts to the largest number of
+ fluid ports that the thermal zones has. For example, if
+ nZon=2 and zone 1 has one inlet and one outlet
+ (hence it has 2 ports), and zone 2 has one inlets and two
+ outlets (hence it has 3 ports), then set nPorts=3. This
+ will add more fluid ports than are needed for zone 1, but this
+ causes no overhead if they are not connected.
- where kd is the loss coefficient (total pressure drop divided
- by dynamic pressure) and y is the fractional opening.
+ The conversion between the fluid ports and signal ports is done in
+ the HVAC adapter hvacAda. This adapter has a vector of
+ fluid ports called ports. The supply and return air
+ ducts, including any resistance model for the inlet diffusor or
+ exhaust grill, need to be connected to these ports. Also, if a
+ thermal zone has interzonal air exchange or air infiltration, these
+ flows need to be connected to ports. This model outputs
+ at the port fluPor the mass flow rate for each flow that
+ is connected to ports, together with its temperature,
+ water vapor mass fraction per total mass of the air (not per kg dry
+ air), and trace substances. These quantities are always as if the
+ flow enters the room, even if the flow is zero or negative. If a
+ medium has no moisture, e.g., if Medium.nXi=0, or if it
+ has no trace substances, e.g., if Medium.nC=0, then the
+ output signal for these properties are removed. These quantities are
+ always as if the flow enters the room, even if the flow is zero or
+ negative. Thus, a thermal zone model that uses these signals to
+ compute the heat added by the HVAC system need to implement an
+ equation such as
-
- Outside this range, the damper characteristics is defined by a
- quadratic polynomial that matches the damper resistance at
- y=0 and y=yL or y=yU and
- y=1, respectively. In addition, the polynomials are such
- that kd(y) is differentiable in y and the
- derivative is continuous.
+
+ Qsen = max(0, ṁsup) cp
+ (Tsup - Tair,zon),
- The damper characteristics is then used to compute the flow
- coefficient k(y) as:
-
-
- k(y) = (2 ρ ⁄ kd(y))1/2 A
+ where Qsen is the sensible heat flow rate added to
+ the thermal zone, ṁsup is the supply air mass flow
+ rate from the port fluPor (which is negative if it is an
+ exhaust), cp is the specific heat capacity at
+ constant pressure, Tsup is the supply air
+ temperature and Tair,zon is the zone air
+ temperature. Note that without the max(·, ·), the energy
+ balance would be wrong.
- where A is the face area, which is computed using the nominal
- mass flow rate m_flow_nominal, the nominal velocity
- v_nominal and the density of the medium.
+ The input signals of this model are the radiative temperature of each
+ zone. The the zone air temperatures, the water vapor mass fractions
+ per total mass of the air (unless Medium.nXi=0) and
+ trace substances (unless Medium.nC=0) are obtained from
+ the connector fluPor.backward. The outflowing fluid
+ stream(s) at the port ports will be at the states
+ obtained from fluPor.backward. For any given
+ izon ∈ {1, ..., nzon}, for each
+ iports ∈ {1, ..., nports} all fluid
+ streams at port ports[izon,
+ iports] are at the same pressure. For convenience,
+ the instance hvacAda also outputs the properties
+ obtained from fluPor.backward. These can be used to
+ connect a controller. The properties are available for each flow path
+ in fluPor.backward. For a thermal zone with mixed air,
+ these are all equal, while for a stratified room model, they can be
+ different.
- ASHRAE 825-RP lists the following parameter values as typical (note
- that the default values in the model correspond to opposed
- blades).
+ See
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZones for a
+ model that uses this model.
-
-
- |
-
- opposed blades
- |
-
- single blades
- |
-
-
- |
- yL
- |
-
- 15/90
- |
-
- 15/90
- |
-
-
- |
- yU
- |
-
- 55/90
- |
-
- 65/90
- |
-
-
- |
- k1
- |
-
- 0.2 to 0.5
- |
-
- 0.2 to 0.5
- |
-
-
- |
- a
- |
-
- -1.51
- |
-
- -1.51
- |
-
-
- |
- b
- |
-
- 0.105*90
- |
-
- 0.0842*90
- |
-
-
- (The loss coefficient in fully closed position k0 is
- computed based on the leakage coefficient and the coefficient in
- fully open position.)
+ For models that only have one thermal zone connected to the HVAC
+ system, use the simpler model AixLib.Fluid.FMI.ExportContainers.HVACZone.
- References
+ Assumption and limitations
- P. Haves, L. K. Norford, M. DeSimone and L. Mei, A Standard
- Simulation Testbed for the Evaluation of Control Algorithms &
- Strategies, ASHRAE Final Report 825-RP, Atlanta, GA.
+ The mass flow rates at ports sum to zero, hence this
+ model conserves mass for each thermal zone.
+
+
+ This model does not impose any pressure, other than, for any given
+ izon ∈ {1, ..., nzon} and for each
+ j,k ∈ {1, ..., nports}, setting the pressure of
+ ports[izon, j].p = ports[izon,
+ k].p to be the same. The reason is that setting a pressure can
+ lead to non-physical system models, for example if a mass flow rate
+ is imposed and the HVAC system is connected to a model that sets a
+ pressure boundary condition such as AixLib.Fluid.Sources.Outside.
+ Also, setting a pressure would make it impossible to use multiple
+ instances of this model (one for each thermal zone) and build in
+ Modelica an airflow network model with pressure driven mass flow
+ rates.
+
+
+ The model has no pressure drop. Hence, the pressure drop of an air
+ diffuser or of an exhaust grill needs to be modelled in models that
+ are connected to ports.
- - September 21, 2021, by Michael Wetter:
- Corrected typo in comments.
- This is for #1525.
-
- - December 23, 2019, by Antoine Gautier:
- Removed the equations involving m_flow and
- dp that now need to be added in each derived damper
- model.
- Added the declaration of dpDamper_nominal and
- dpFixed_nominal.
- Replaced k0 by leakage coefficient.
- Modified the limiting values for k0 and
- k1.
- This is for #1188.
-
- - March 22, 2017, by Michael Wetter:
- Added back v_nominal, but set the assignment of
- A to be final. This allows scaling the model with
- m_flow_nominal, which is generally known in the flow
- leg, and v_nominal, for which a default value can be
- specified.
- This is for #544.
-
- - October 12, 2016 by David Blum:
- Removed parameter v_nominal and variable
- area, to simplify parameterization of the model. Also
- added assertion statements upon initialization for parameters
- k0 and k1 so that they fall within
- suggested ranges found in ASHRAE 825-RP. This is for #544.
-
- - January 27, 2015 by Michael Wetter:
- Set Evaluate=true for
- use_constant_density. This is a structural parameter.
- Adding this annotation leads to fewer numerical Jacobians for
- Buildings.Examples.VAVReheat.ClosedLoop with
- Buildings.Media.PerfectGases.MoistAirUnsaturated.
-
- - December 14, 2012 by Michael Wetter:
- Renamed protected parameters for consistency with the naming
- conventions.
-
- - January 16, 2012 by Michael Wetter:
- To simplify object inheritance tree, revised base classes
- AixLib.Fluid.BaseClasses.PartialResistance,
- AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve,
- AixLib.Fluid.Actuators.BaseClasses.PartialDamperExponential,
- AixLib.Fluid.Actuators.BaseClasses.PartialActuator and
- model AixLib.Fluid.FixedResistances.PressureDrop.
-
- - August 5, 2011, by Michael Wetter:
- Moved linearized pressure drop equation from the function body to
- the equation section. With the previous implementation, the
- symbolic processor may not rearrange the equations, which can lead
- to coupled equations instead of an explicit solution.
-
- - June 22, 2008 by Michael Wetter:
- Extended range of control signal from 0 to 1 by implementing the
- function exponentialDamper.
+ - January 18, 2019, by Jianjun Hu:
+ Limited the media choice to moist air only. See #1050.
- - June 10, 2008 by Michael Wetter:
+ - May 25, 2016, by Michael Wetter:
First implementation.
-------- Errors --------
-line 50 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 60 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/Boreholes/BaseClasses/Functions/convectionResistanceCircularPipe.mo ----
+---- AixLib/Fluid/HeatPumps/Carnot_TCon.mo ----
-------- HTML Code --------
- This model computes the convection resistance in the pipes of a borehole segment
- with heigth hSeg using correlations suggested by Bergman et al. (2011).
+ This is a model of a heat pump whose coefficient of performance COP changes
+ with temperatures in the same way as the Carnot efficiency changes.
+ The control input is the setpoint of the condenser leaving temperature, which
+ is met exactly at steady state if the heat pump has sufficient capacity.
- If the flow is laminar (Re ≤ 2300, with Re being the Reynolds number of the flow),
- the Nusselt number of the flow is assumed to be constant at 3.66. If the flow is turbulent (Re > 2300),
- the correlation of Dittus-Boelter is used to find the convection heat transfer coefficient as
+ The model allows to either specify the Carnot effectivness
+ ηCarnot,0, or
+ a COP0
+ at the nominal conditions, together with
+ the evaporator temperature Teva,0 and
+ the condenser temperature Tcon,0, in which
+ case the model computes the Carnot effectivness as
- Nu = 0.023 Re0.8 Prn,
+ ηCarnot,0 =
+ COP0
+ ⁄ (Tcon,0 ⁄ (Tcon,0-Teva,0)).
- where Nu is the Nusselt number and
- Pr is the Prandlt number.
- A value of n=0.35 is used, as the reference uses n=0.4 for heating and
- n=0.3 for cooling. To ensure that the function is continuously differentiable,
- a smooth transition between the laminar and turbulent values is created for the
- range 2300 < Re < 2400.
+ The heat pump COP is computed as the product
+
+
+ COP = ηCarnot,0 COPCarnot ηPL,
- References
- Bergman, T. L., Incropera, F. P., DeWitt, D. P., & Lavine, A. S. (2011). Fundamentals of heat and mass
- transfer (7th ed.). New York: John Wiley & Sons.
+ where COPCarnot is the Carnot efficiency and
+ ηPL is a polynomial in heating part load ratio yPL
+ that can be used to take into account a change in COP at part load
+ conditions.
+ This polynomial has the form
+
+
+ ηPL = a1 + a2 yPL + a3 yPL2 + ...
-
-
- -
- July 10, 2018, by Alex Laferrière:
- Added laminar flow and smooth laminar-turbulent transition.
- Revised documentation.
-
- -
- February 14, 2014, by Michael Wetter:
- Removed unused input rBor.
- Revised documentation.
-
- -
- January 24, 2014, by Michael Wetter:
- Revised implementation.
- Changed cpFluid to cpMed to use consistent notation.
- Added regularization for computation of convective heat transfer coefficient to
- avoid an event and a non-differentiability.
-
- -
- January 23, 2014, by Damien Picard:
- First implementation.
-
-
-
--------- Corrected Code --------
-
- This model computes the convection resistance in the pipes of a
- borehole segment with heigth hSeg using
- correlations suggested by Bergman et al. (2011).
-
-
- If the flow is laminar (Re ≤ 2300, with Re being the
- Reynolds number of the flow), the Nusselt number of the flow is
- assumed to be constant at 3.66. If the flow is turbulent (Re >
- 2300), the correlation of Dittus-Boelter is used to find the
- convection heat transfer coefficient as
-
-
- Nu = 0.023 Re0.8 Prn,
-
-
- where Nu is the Nusselt number and Pr is the Prandlt
- number. A value of n=0.35 is used, as the reference uses
- n=0.4 for heating and n=0.3 for cooling. To ensure that
- the function is continuously differentiable, a smooth transition
- between the laminar and turbulent values is created for the range
- 2300 < Re < 2400.
-
-
- References
-
-
- Bergman, T. L., Incropera, F. P., DeWitt, D. P., & Lavine, A. S.
- (2011). Fundamentals of heat and mass transfer (7th ed.). New
- York: John Wiley & Sons.
-
-
- - July 10, 2018, by Alex Laferrière:
- Added laminar flow and smooth laminar-turbulent transition. Revised
- documentation.
-
- - February 14, 2014, by Michael Wetter:
- Removed unused input rBor. Revised documentation.
-
- - January 24, 2014, by Michael Wetter:
- Revised implementation. Changed cpFluid to
- cpMed to use consistent notation. Added regularization
- for computation of convective heat transfer coefficient to avoid an
- event and a non-differentiability.
-
- - January 23, 2014, by Damien Picard:
- First implementation.
-
-
-
--------- Errors --------
-line 11 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/HeatPumps/Compressors/ReciprocatingCompressor.mo ----
--------- HTML Code --------
-
- Model for a reciprocating processor, as detailed in Jin (2002). The rate of heat transferred to the evaporator is given by:
+ where the coefficients ai
+ are declared by the parameter a.
-
- Q̇Eva = ṁref ( hVap(TEva) - hLiq(TCon) ).
+
+ On the Dynamics tag, the model can be parametrized to compute a transient
+ or steady-state response.
+ The transient response of the model is computed using a first
+ order differential equation for the evaporator and condenser fluid volumes.
+ The heat pump outlet temperatures are equal to the temperatures of these lumped volumes.
+ Typical use and important parameters
- The power consumed by the compressor is given by a linear efficiency relation:
+ When using this component, make sure that the condenser has sufficient mass flow rate.
+ Based on the evaporator mass flow rate, temperature difference and the efficiencies,
+ the model computes how much heat will be removed by to the evaporator.
+ If the mass flow rate is too small, very low outlet temperatures can result, possibly below freezing.
-
- P = PTheoretical / η + PLoss,constant.
+
+ The condenser heat flow rate QCon_flow_nominal is used to assign
+ the default value for the mass flow rates, which are used for the pressure drop
+ calculations.
+ It is also used to compute the part load efficiency.
+ Hence, make sure that QCon_flow_nominal is set to a reasonable value.
- Variable speed is acheived by multiplying the full load piston displacement
- by the normalized compressor speed. The power and heat transfer rates are forced
- to zero if the resulting heat pump state has higher evaporating pressure than
- condensing pressure.
+ The maximum heating capacity is set by the parameter QCon_flow_max,
+ which is by default set to infinity.
- Assumptions and limitations
- The compression process is assumed isentropic. The thermal energy
- of superheating is ignored in the evaluation of the heat transferred to the refrigerant
- in the evaporator. There is no supercooling.
+ The coefficient of performance depends on the
+ evaporator and condenser leaving temperature
+ since otherwise the second law of thermodynamics may be violated.
- References
+ Notes
- H. Jin.
-
- Parameter estimation based models of water source heat pumps.
-
- PhD Thesis. Oklahoma State University. Stillwater, Oklahoma, USA. 2002.
+ For a similar model that can be used as a chiller, see
+
+ AixLib.Fluid.Chillers.Examples.Carnot_TEva.
-
- January 25, 2019, by Michael Wetter:
- Added start value to avoid warning in JModelica.
+ January 3, 2017, by Michael Wetter:
+ Removed parameters
+ effInpEva and effInpCon
+ and updated documentation.
+ This is for
+
+ issue 497.
-
- May 30, 2017, by Filip Jorissen:
- Removed pressure_error as
- this is replaced by
-
- AixLib.Fluid.HeatPumps.Compressors.BaseClasses.TemperatureProtection.
- See #769.
+ August 8, 2016, by Michael Wetter:
+ Changed default temperature to compute COP to be the leaving temperature as
+ use of the entering temperature can violate the 2nd law if the temperature
+ lift is small.
+ This is for
+
+ Annex 60, issue 497.
-
- November 14, 2016, by Massimo Cimmino:
+ November 25, 2015 by Michael Wetter:
First implementation.
-------- Corrected Code --------
- Model for a reciprocating processor, as detailed in Jin (2002). The
- rate of heat transferred to the evaporator is given by:
+ This is a model of a heat pump whose coefficient of performance COP
+ changes with temperatures in the same way as the Carnot efficiency
+ changes. The control input is the setpoint of the condenser leaving
+ temperature, which is met exactly at steady state if the heat pump
+ has sufficient capacity.
+
+
+ The model allows to either specify the Carnot effectivness
+ ηCarnot,0, or a COP0 at the
+ nominal conditions, together with the evaporator temperature
+ Teva,0 and the condenser temperature
+ Tcon,0, in which case the model computes the Carnot
+ effectivness as
- Q̇Eva = ṁref (
- hVap(TEva) - hLiq(TCon)
- ).
+ ηCarnot,0 = COP0 ⁄ (Tcon,0 ⁄
+ (Tcon,0-Teva,0)).
- The power consumed by the compressor is given by a linear efficiency
- relation:
+ The heat pump COP is computed as the product
- P = PTheoretical / η + PLoss,constant.
+ COP = ηCarnot,0 COPCarnot ηPL,
- Variable speed is acheived by multiplying the full load piston
- displacement by the normalized compressor speed. The power and heat
- transfer rates are forced to zero if the resulting heat pump state
- has higher evaporating pressure than condensing pressure.
+ where COPCarnot is the Carnot efficiency and
+ ηPL is a polynomial in heating part load ratio
+ yPL that can be used to take into account a change
+ in COP at part load conditions. This polynomial has the form
+
+
+ ηPL = a1 + a2 yPL +
+ a3 yPL2 + ...
+
+
+ where the coefficients ai are declared by the
+ parameter a.
+
+
+ On the Dynamics tag, the model can be parametrized to
+ compute a transient or steady-state response. The transient response
+ of the model is computed using a first order differential equation
+ for the evaporator and condenser fluid volumes. The heat pump outlet
+ temperatures are equal to the temperatures of these lumped volumes.
- Assumptions and limitations
+ Typical use and important parameters
- The compression process is assumed isentropic. The thermal energy of
- superheating is ignored in the evaluation of the heat transferred to
- the refrigerant in the evaporator. There is no supercooling.
+ When using this component, make sure that the condenser has
+ sufficient mass flow rate. Based on the evaporator mass flow rate,
+ temperature difference and the efficiencies, the model computes how
+ much heat will be removed by to the evaporator. If the mass flow rate
+ is too small, very low outlet temperatures can result, possibly below
+ freezing.
+
+
+ The condenser heat flow rate QCon_flow_nominal is used
+ to assign the default value for the mass flow rates, which are used
+ for the pressure drop calculations. It is also used to compute the
+ part load efficiency. Hence, make sure that
+ QCon_flow_nominal is set to a reasonable value.
+
+
+ The maximum heating capacity is set by the parameter
+ QCon_flow_max, which is by default set to infinity.
+
+
+ The coefficient of performance depends on the evaporator and
+ condenser leaving temperature since otherwise the second law of
+ thermodynamics may be violated.
- References
+ Notes
- H. Jin. Parameter estimation based models of water source heat
- pumps. PhD Thesis. Oklahoma State University. Stillwater,
- Oklahoma, USA. 2002.
+ For a similar model that can be used as a chiller, see AixLib.Fluid.Chillers.Examples.Carnot_TEva.
- - January 25, 2019, by Michael Wetter:
- Added start value to avoid warning in JModelica.
+ - January 3, 2017, by Michael Wetter:
+ Removed parameters effInpEva and
+ effInpCon and updated documentation. This is for
+ issue
+ 497.
- - May 30, 2017, by Filip Jorissen:
- Removed pressure_error as this is replaced by
- AixLib.Fluid.HeatPumps.Compressors.BaseClasses.TemperatureProtection.
- See #769.
+ - August 8, 2016, by Michael Wetter:
+ Changed default temperature to compute COP to be the leaving
+ temperature as use of the entering temperature can violate the 2nd
+ law if the temperature lift is small.
+ This is for Annex 60,
+ issue 497.
- - November 14, 2016, by Massimo Cimmino:
+ - November 25, 2015 by Michael Wetter:
First implementation.
-------- Errors --------
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
-line 11 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 17 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 25 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 35 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/Interfaces/PrescribedOutlet.mo ----
+---- AixLib/Fluid/Sources/Outside_CpData.mo ----
-------- HTML Code --------
- This model sets the temperature or the water vapor mass fraction
- of the medium that leaves port_a
- to the value given by the input TSet or X_wSet,
- subject to optional limitations on the capacity
- for heating and cooling, or limitations on the humidification or dehumidification
- moisture mass flow rate.
- Also, optionally the model allows to take into account first order dynamics.
+ This model describes boundary conditions for
+ pressure, enthalpy, and species concentration that can be obtained
+ from weather data. The model is identical to
+
+ AixLib.Fluid.Sources.Outside,
+ except that it adds the wind pressure to the
+ pressure at the fluid ports ports.
- If the parameters energyDynamics is not equal to
- Modelica.Fluid.Types.Dynamics.SteadyState,
- the component models the dynamic response using a first order differential equation.
- The time constant of the component is equal to the parameter tau.
- This time constant is adjusted based on the mass flow rate using
+ The pressure p at the fluid ports is computed as:
- τeff = τ |ṁ| ⁄ ṁnom
+ p = pw + Cp,act Cs v2 ρ ⁄ 2,
- where
- τeff is the effective time constant for the given mass flow rate
- ṁ and
- τ is the time constant at the nominal mass flow rate
- ṁnom.
- This type of dynamics is equal to the dynamics that a completely mixed
- control volume would have.
+ where pw is the atmospheric pressure from the weather bus,
+ v is the wind speed from the weather bus, and
+ ρ is the fluid density.
- This model has no pressure drop.
- See
- AixLib.Fluid.HeatExchangers.PrescribedOutlet
- for a model that instantiates this model and that has a pressure drop.
+ The wind pressure coefficient Cp,act is a function of the surface wind incidence
+ angle and is defined relative to the surface azimuth (normal to the surface is 0).
+ The wind incidence angle incAng is computed from the wind direction obtained from the weather file
+ with the surface azimuth azi as the base of the angle.
+ The relation between the wind pressure coefficient Cp,act and the incidence angle incAng
+ is defined by a cubic hermite interpolation of the users table input.
+ Typical table values can be obtained from the "AIVC guide to energy efficient ventilation",
+ appendix 2 (1996). The default table is appendix 2, table 2.2, face 1.
- In case of reverse flow,
- the fluid that leaves port_a has the same
- properties as the fluid that enters port_b.
+ The wind speed modifier Cs can be used to incorporate the effect of the surroundings on the local wind speed.
+
+ Definition of angles
+
+ The angles incAngSurNor for the wind incidence angle relative to the surface normal
+ are measured counter-clock wise.
+ The figure below shows an example entry, which is also used in the model
+
+ AixLib.Fluid.Sources.Examples.Outside_CpData_Specification.
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Sources/Outside_CpData.png\"/)
+
+
+ The wind incidence angle and surface azimuths are defined as follows:
+ The wind indicience angle is obtained directly from the weather data bus weaBus.winDir.
+ This variable contains the data from the weather data file that was read, such as a TMY3 file.
+ In accordance to TMY3, the data is as shown in the table below.
+
+
+ Value of winDir if the wind blows from different directions.
+ | Wind from North:
0
0° | |
+ Wind from West:
3π/2
270° | | Wind from East:
π/2
90° |
+ | Wind from South:
π
180° | |
+
+
+ For the surface azimuth azi, the specification from
+ AixLib.Types.Azimuth is
+ used, which is as shown in the table below.
+
+ Value of azi if the exterior wall faces in the different directions.
+ | Wall facing north:
π
180° | |
+ Wall facing West:
π/2
90° | | Wall facing east:
3π/2
270° |
+ | Wall facing South:
0;
0° | |
+
+
+ Related model
+
+ This model differs from
+ AixLib.Fluid.Sources.Outside_CpLowRise by the calculation of the wind pressure coefficient
+ Cp,act.
+ The wind pressure coefficient is defined by a user-defined table instead of a generalized equation
+ such that it can be used for all building sizes and situations, for shielded buildings,
+ and for buildings with non-rectangular shapes.
+
+
+ References
+
+
+ - M. W. Liddament, 1996, A guide to energy efficient ventilation. AIVC Annex V.
+
+
-
- March 3, 2022, by Michael Wetter:
- Removed massDynamics.
- This is for
- issue 1542.
-
- -
- April 29, 2021, by Michael Wetter:
- Removed duplicate declaration of m_flow_nominal which is already
- declared in the base class.
-
- -
- March 19, 2018, by Michael Wetter:
- Added bugfix as the old model did not track TSet and X_wSet
- simultaneously.
- This is for
- #893.
-
- -
- May 3, 2017, by Michael Wetter:
- Refactored model to allow X_wSet as an input.
+ February 2, 2022, by Michael Wetter:
+ Revised implementation.
This is for
- #763.
-
- -
- January 26, 2016, by Michael Wetter:
- Removed inequality comparison of real numbers in restrictCool
- and in restrictHeat as this is not allowed in Modelica.
+ IBPSA, #1436.
-
- November 10, 2014, by Michael Wetter:
+ Apr 6, 2021, by Klaas De Jonge:
First implementation.
-------- Corrected Code --------
- This model sets the temperature or the water vapor mass fraction of
- the medium that leaves port_a to the value given by the
- input TSet or X_wSet, subject to optional
- limitations on the capacity for heating and cooling, or limitations
- on the humidification or dehumidification moisture mass flow rate.
- Also, optionally the model allows to take into account first order
- dynamics.
+ This model describes boundary conditions for pressure, enthalpy, and
+ species concentration that can be obtained from weather data. The
+ model is identical to AixLib.Fluid.Sources.Outside,
+ except that it adds the wind pressure to the pressure at the fluid
+ ports ports.
- If the parameters energyDynamics is not equal to
- Modelica.Fluid.Types.Dynamics.SteadyState, the component
- models the dynamic response using a first order differential
- equation. The time constant of the component is equal to the
- parameter tau. This time constant is adjusted based on
- the mass flow rate using
+ The pressure p at the fluid ports is computed as:
- τeff = τ |ṁ| ⁄ ṁnom
+ p = pw + Cp,act Cs v2 ρ ⁄
+ 2,
- where τeff is the effective time constant for the
- given mass flow rate ṁ and τ is the time constant at
- the nominal mass flow rate ṁnom. This type of
- dynamics is equal to the dynamics that a completely mixed control
- volume would have.
+ where pw is the atmospheric pressure from the
+ weather bus, v is the wind speed from the weather bus, and
+ ρ is the fluid density.
- This model has no pressure drop. See AixLib.Fluid.HeatExchangers.PrescribedOutlet
- for a model that instantiates this model and that has a pressure
- drop.
+ The wind pressure coefficient Cp,act is a function
+ of the surface wind incidence angle and is defined relative to the
+ surface azimuth (normal to the surface is 0). The wind
+ incidence angle incAng is computed from the wind
+ direction obtained from the weather file with the surface azimuth
+ azi as the base of the angle. The relation between the
+ wind pressure coefficient Cp,act and the incidence
+ angle incAng is defined by a cubic hermite interpolation
+ of the users table input. Typical table values can be obtained from
+ the \"AIVC guide to energy efficient ventilation\", appendix 2 (1996).
+ The default table is appendix 2, table 2.2, face 1.
- In case of reverse flow, the fluid that leaves port_a
- has the same properties as the fluid that enters port_b.
+ The wind speed modifier Cs can be used to
+ incorporate the effect of the surroundings on the local wind speed.
-
- - March 3, 2022, by Michael Wetter:
- Removed massDynamics.
- This is for issue
- 1542.
-
- - April 29, 2021, by Michael Wetter:
- Removed duplicate declaration of m_flow_nominal which
- is already declared in the base class.
-
- - March 19, 2018, by Michael Wetter:
- Added bugfix as the old model did not track TSet and
- X_wSet simultaneously.
- This is for #893.
-
- - May 3, 2017, by Michael Wetter:
- Refactored model to allow X_wSet as an input.
- This is for #763.
-
- - January 26, 2016, by Michael Wetter:
- Removed inequality comparison of real numbers in
- restrictCool and in restrictHeat as this
- is not allowed in Modelica.
-
- - November 10, 2014, by Michael Wetter:
- First implementation.
-
-
-
--------- Errors --------
-line 18 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/ThermalZones/ReducedOrder/RC/BaseClasses/ExteriorWall.mo ----
--------- HTML Code --------
-
-
ExteriorWall represents heat conduction and heat storage
- within walls. It links a variable number n of thermal resistances
- and capacities to a series connection. n thus defines the spatial
- discretization of thermal effects within the wall. All effects are considered
- as one-dimensional normal to the wall's surface. This model is thought
- for exterior wall elements that contribute to heat transfer to the outdoor.
- The RC-chain is defined via a vector of capacities CExt[n] and a
- vector of resistances RExt[n]. Resistances and capacities are
- connected alternately, starting with the first resistance RExt[1],
- from heat port_a to heat port_b. RExtRem
- is the resistance between the last capacity CExt[end] and the
- heat port_b.
- ![\"image\"/](\"modelica://AixLib/Resources/Images/ThermalZones/ReducedOrder/RC/BaseClasses/ExtMassVarRC/ExtMassVarRC.png\")
-
-
- -
- April 27, 2016, by Michael Wetter:
- Added graphical connections.
-
- -
- April 17, 2015, by Moritz Lauster:
- Implemented.
-
-
-
--------- Corrected Code --------
+
+ Definition of angles
+
- ExteriorWall represents heat conduction and heat storage
- within walls. It links a variable number n of thermal
- resistances and capacities to a series connection. n
- thus defines the spatial discretization of thermal effects within the
- wall. All effects are considered as one-dimensional normal to the
- wall's surface. This model is thought for exterior wall elements that
- contribute to heat transfer to the outdoor. The RC-chain is defined
- via a vector of capacities CExt[n] and a vector of
- resistances RExt[n]. Resistances and capacities are
- connected alternately, starting with the first resistance
- RExt[1], from heat port_a to heat
- port_b. RExtRem is the resistance between
- the last capacity CExt[end] and the heat
- port_b.
+ The angles incAngSurNor for the wind incidence angle
+ relative to the surface normal are measured counter-clock wise. The
+ figure below shows an example entry, which is also used in the model
+
+ AixLib.Fluid.Sources.Examples.Outside_CpData_Specification.
-
+
+
+
+ The wind incidence angle and surface azimuths are defined as follows:
+ The wind indicience angle is obtained directly from the weather data
+ bus weaBus.winDir. This variable contains the data from
+ the weather data file that was read, such as a TMY3 file. In
+ accordance to TMY3, the data is as shown in the table below.
+
+
+
+ Value of winDir if the wind blows from different
+ directions.
+
+
+ |
+
+ Wind from North:
+ 0
+ 0°
+ |
+ |
+
+
+
+ Wind from West:
+ 3π/2
+ 270°
+ |
+ |
+
+ Wind from East:
+ π/2
+ 90°
+ |
+
+
+ |
+
+ Wind from South:
+ π
+ 180°
+ |
+ |
+
+
+
+ For the surface azimuth azi, the specification from
+ AixLib.Types.Azimuth is
+ used, which is as shown in the table below.
+
+
+
+ Value of azi if the exterior wall faces in the
+ different directions.
+
+
+ |
+
+ Wall facing north:
+ π
+ 180°
+ |
+ |
+
+
+
+ Wall facing West:
+ π/2
+ 90°
+ |
+ |
+
+ Wall facing east:
+ 3π/2
+ 270°
+ |
+
+
+ |
+
+ Wall facing South:
+ 0;
+ 0°
+ |
+ |
+
+
+
+ Related model
+
+
+ This model differs from AixLib.Fluid.Sources.Outside_CpLowRise
+ by the calculation of the wind pressure coefficient
+ Cp,act. The wind pressure coefficient is defined by
+ a user-defined table instead of a generalized equation such that it
+ can be used for all building sizes and situations, for shielded
+ buildings, and for buildings with non-rectangular shapes.
+
+
+ References
- - April 27, 2016, by Michael Wetter:
- Added graphical connections.
+ - M. W. Liddament, 1996, A guide to energy efficient
+ ventilation. AIVC Annex V.
- - April 17, 2015, by Moritz Lauster:
- Implemented.
+
+
+ - February 2, 2022, by Michael Wetter:
+ Revised implementation.
+ This is for IBPSA,
+ #1436.
+
+ - Apr 6, 2021, by Klaas De Jonge:
+ First implementation.
-------- Errors --------
-line 14 column 4 - Warning: attribute "align" not allowed for HTML5
+line 51 column 2 - Warning: The summary attribute on the
element is obsolete in HTML5
+line 63 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 14 column 2 - Warning: attribute "align" not allowed for HTML5
+line 43 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/Chillers/BaseClasses/Carnot.mo ----
+---- AixLib/BoundaryConditions/Validation/BESTEST/WD100.mo ----
-------- HTML Code --------
-
- This is the base class for the Carnot chiller and the Carnot heat pump
- whose coefficient of performance COP changes
- with temperatures in the same way as the Carnot efficiency changes.
-
-
- The model allows to either specify the Carnot effectivness
- ηCarnot,0, or
- a COP0
- at the nominal conditions, together with
- the evaporator temperature Teva,0 and
- the condenser temperature Tcon,0, in which
- case the model computes the Carnot effectivness as
-
-
- ηCarnot,0 =
- COP0
- ⁄ (Tuse,0 ⁄ (Tcon,0-Teva,0)),
-
-
- where
- Tuse is the temperature of the the useful heat,
- e.g., the evaporator temperature for a chiller or the condenser temperature
- for a heat pump.
-
-
- The COP is computed as the product
-
-
- COP = ηCarnot,0 COPCarnot ηPL,
-
-
- where COPCarnot is the Carnot efficiency and
- ηPL is the part load efficiency, expressed using
- a polynomial.
- This polynomial has the form
-
-
- ηPL = a1 + a2 y + a3 y2 + ...
-
-
- where y ∈ [0, 1] is
- either the part load for cooling in case of a chiller, or the part load of heating in
- case of a heat pump, and the coefficients ai
- are declared by the parameter a.
-
- Implementation
-
- To make this base class applicable to chiller or heat pumps, it uses
- the boolean constant COP_is_for_cooling.
- Depending on its value, the equations for the coefficient of performance
- and the part load ratio are set up.
-
+ WD100: Base Case
+ Weather data file : WD100.epw
+ Table 1: Site Data for Weather file WD100.epw
+
+ Latitude |
+ 39.833° north |
+
+
+ Longitude |
+ 104.65° west |
+
+
+ Altitude |
+ 1650 m |
+
+
+ Time Zone |
+ -7 |
+
+
+ This model is a template for all the other test cases.
+ It allows to extrapolate all the weather data from the Reader TMY3 for a specific location, incliation and azimuth.
+ The model
+ AixLib.BoundaryConditions.Validation.IsotropicAndPerezDiffuseRadiation
+ outputs radiation data using the available Isotropic and Perez methodlogies.
+ The sky temperature is calculated using both the Horizontal radiation model,
+ from data reader weaBusHorRad and the dew point temperature plus sky cover model from the datareader weaBusSkyCovDewTem.
-
- April 14, 2020, by Michael Wetter:
- Changed homotopyInitialization to a constant.
+ September 6, 2021, by Ettore Zanetti:
+ Removed parameter lat as it is now obtained from the weather data bus.
This is for
- IBPSA, #1341.
+ IBPSA, #1477.
-
- September 12, 2019, by Michael Wetter:
- Corrected value of evaluate_etaPL and how it is used.
- This correction only affects protected variables and does not affect the results.
- This is for
- #1200.
+ March 11, 2020, by Ettore Zanetti:
+ First implementation.
-
- June 16, 2017, by Michael Wetter:
- Added temperature difference between fluids in condenser and evaporator
- for computation of nominal COP and effectiveness.
- This is for
- #698.
+ April 14, 2020, by Ettore Zanetti:
+ Rework after comments from pull request
+ #1339.
-
- March 28, 2017, by Felix Buenning:
- Added temperature difference between fluids in condenser and evaporator.
- The difference is based on discussions with Emerson Climate Technologies.
- This is for
- #698.
+ May 2, 2021, by Ettore Zanetti:
+ Updated weather file as explained in #1478.
-
- January 2, 2017, by Filip Jorissen:
- Removed option for choosing what temperature
- should be used to compute the Carnot efficiency.
+ May 2, 2021, by Ettore Zanetti:
+ Added altitude to parameters.
This is for
-
- issue 497.
-
- -
- January 26, 2016, by Michael Wetter:
- First implementation of this base class.
+ IBPSA, #1477.
-------- Corrected Code --------
+
+ WD100: Base Case
+
- This is the base class for the Carnot chiller and the Carnot heat
- pump whose coefficient of performance COP changes with temperatures
- in the same way as the Carnot efficiency changes.
-
-
- The model allows to either specify the Carnot effectivness
- ηCarnot,0, or a COP0 at the
- nominal conditions, together with the evaporator temperature
- Teva,0 and the condenser temperature
- Tcon,0, in which case the model computes the Carnot
- effectivness as
-
-
- ηCarnot,0 = COP0 ⁄ (Tuse,0 ⁄
- (Tcon,0-Teva,0)),
-
-
- where Tuse is the temperature of the the useful
- heat, e.g., the evaporator temperature for a chiller or the condenser
- temperature for a heat pump.
-
-
- The COP is computed as the product
-
-
- COP = ηCarnot,0 COPCarnot ηPL,
-
-
- where COPCarnot is the Carnot efficiency and
- ηPL is the part load efficiency, expressed using a
- polynomial. This polynomial has the form
-
-
- ηPL = a1 + a2 y + a3
- y2 + ...
+ Weather data file : WD100.epw
- where y ∈ [0, 1] is either the part load for cooling in case
- of a chiller, or the part load of heating in case of a heat pump, and
- the coefficients ai are declared by the parameter
- a.
+ Table 1: Site Data for Weather file WD100.epw
-
- Implementation
-
+
+
+ |
+
+ Latitude
+
+ |
+
+
+ 39.833° north
+
+ |
+
+
+ |
+
+ Longitude
+
+ |
+
+
+ 104.65° west
+
+ |
+
+
+ |
+
+ Altitude
+
+ |
+
+
+ 1650 m
+
+ |
+
+
+ |
+
+ Time Zone
+
+ |
+
+
+ -7
+
+ |
+
+
- To make this base class applicable to chiller or heat pumps, it uses
- the boolean constant COP_is_for_cooling. Depending on
- its value, the equations for the coefficient of performance and the
- part load ratio are set up.
+ This model is a template for all the other test cases. It allows to
+ extrapolate all the weather data from the Reader TMY3 for a specific
+ location, incliation and azimuth. The model
+ AixLib.BoundaryConditions.Validation.IsotropicAndPerezDiffuseRadiation
+ outputs radiation data using the available Isotropic and Perez
+ methodlogies. The sky temperature is calculated using both the
+ Horizontal radiation model, from data reader weaBusHorRad and the dew
+ point temperature plus sky cover model from the datareader
+ weaBusSkyCovDewTem.
- - April 14, 2020, by Michael Wetter:
- Changed homotopyInitialization to a constant.
- This is for IBPSA,
- #1341.
-
- - September 12, 2019, by Michael Wetter:
- Corrected value of evaluate_etaPL and how it is used.
- This correction only affects protected variables and does not
- affect the results.
+ - September 6, 2021, by Ettore Zanetti:
+ Removed parameter lat as it is now obtained from the
+ weather data bus.
This is for #1200.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/1477\">IBPSA,
+ #1477.
- - June 16, 2017, by Michael Wetter:
- Added temperature difference between fluids in condenser and
- evaporator for computation of nominal COP and effectiveness.
- This is for #698.
+ - March 11, 2020, by Ettore Zanetti:
+ First implementation.
- - March 28, 2017, by Felix Buenning:
- Added temperature difference between fluids in condenser and
- evaporator. The difference is based on discussions with Emerson
- Climate Technologies.
- This is for #698.
+ - April 14, 2020, by Ettore Zanetti:
+ Rework after comments from pull request #1339.
- - January 2, 2017, by Filip Jorissen:
- Removed option for choosing what temperature should be used to
- compute the Carnot efficiency. This is for issue 497.
+ - May 2, 2021, by Ettore Zanetti:
+ Updated weather file as explained in #1478.
- - January 26, 2016, by Michael Wetter:
- First implementation of this base class.
+ - May 2, 2021, by Ettore Zanetti:
+ Added altitude to parameters.
+ This is for IBPSA,
+ #1477.
-------- Errors --------
-line 16 column 2 - Warning: attribute "align" not allowed for HTML5
-line 30 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 39 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 5 column 2 - Warning: The summary attribute on the
element is obsolete in HTML5
----- AixLib/Fluid/Geothermal/Borefields/UsersGuide.mo ----
+---- AixLib/Fluid/Types.mo ----
-------- HTML Code --------
+
+
+ Enumeration to define the choice of valve flow coefficient
+ (to be selected via choices menu):
+
+
+
+ | Enumeration |
+ Description |
|---|
+
+ | OpPoint |
+ flow coefficient defined by ratio m_flow_nominal/sqrt(dp_nominal) |
+
+ | Kv |
+ Kv (metric) flow coefficient |
+
+ | Cv |
+ Cv (US) flow coefficient |
+
+ | Av |
+ Av (metric) flow coefficient |
+
+
+
+
+ The details of the coefficients are explained in the
+
+ Users Guide.
+
+
+
+
+ Enumeration that defines the heat exchanger construction.
+
+
+ The following heat exchanger configurations are available in this enumeration:
+
+
+ | Enumeration | Description |
|---|
+ | ParallelFlow | Parallel flow |
+ | CounterFlow | Counter flow |
+ | CrossFlowUnmixed | Cross flow, both streams unmixed |
+ | CrossFlowStream1MixedStream2Unmixed | Cross flow, stream 1 mixed, stream 2 unmixed |
+ | CrossFlowStream1UnmixedStream2Mixed | Cross flow, stream 1 unmixed, stream 2 mixed |
+ | ConstantTemperaturePhaseChange | Constant temperature phase change in one stream |
+
+
+ Note that for a given heat exchanger, the
+ HeatExchangerConfiguration is fixed. However, if the capacity
+ flow rates change, then the
+
+ AixLib.Fluid.Types.HeatExchangerFlowRegime may change. For example,
+ a counter flow heat exchanger has HeatExchangerConfiguration=CounterFlow,
+ but the
+ AixLib.Fluid.Types.HeatExchangerFlowRegime can change to parallel flow if one of the two capacity flow rates reverts
+ its direction.
+
+
+
+ -
+ March 27, 2017, by Michael Wetter:
+ Added ConstantTemperaturePhaseChange.
+ This is for
+
+ AixLib #694.
+
+ -
+ February 18, 2009, by Michael Wetter:
+ First implementation.
+
+
+
+
+ Enumeration to define the heat exchanger flow regime.
+
+
+ This enumeration defines for the current capacity flow rate the kind of
+ heat transfer relation that will be used to compute the relation between
+ effectiveness and Number of Transfer Units.
+
+
+ The following heat exchanger flow regimes are available in this enumeration:
+
+
+ | Enumeration | Description |
|---|
+ | ParallelFlow | Parallel flow |
+ | CounterFlow | Counter flow |
+ | CrossFlowUnmixed | Cross flow, both streams unmixed |
+ | CrossFlowCMinMixedCMaxUnmixed | Cross flow, CMin mixed, CMax unmixed |
+ | CrossFlowCMinUnmixedCMaxMixed | Cross flow, CMin unmixed, CMax mixed |
+ | ConstantTemperaturePhaseChange | Constant temperature phase change in one stream |
+
+
+
+ -
+ March 27, 2017, by Michael Wetter:
+ Added ConstantTemperaturePhaseChange.
+ This is for
+
+ AixLib #694.
+
+ -
+ February 18, 2009, by Michael Wetter:
+ First implementation.
+
+
+
+
+ This type allows defining which type of input should be used for movers.
+ This can either be
+
+
+ -
+ a constant set point declared by a parameter,
+
+ -
+ a series of possible set points that can be switched using an integer input, or
+
+ -
+ a continuously variable set point.
+
+
+
+
+ -
+ April 2, 2015, by Filip Jorissen:
+ First implementation.
+
+
+
+
+ This package contains type definitions.
+
+
+-------- Corrected Code --------
-This package contains borefield models. These models can simulate any arbitrary
-configuration of vertical boreholes with equal lengths with both short and
-long-term accuracy with an aggregation method to speed up the calculations of the ground heat transfer. Examples
-of how to use the borefield models and validation cases can be found in
-
-AixLib.Fluid.Geothermal.Borefields.Examples
-and
-
-AixLib.Fluid.Geothermal.Borefields.Validation,
-respectively.
-
-
-The major features and configurations currently supported are:
-
-- User-defined borefield characteristics and geometry (borehole radius, pipe radius, shank spacing, etc.),
-including single U-tube, double U-tube in parallel and double U-tube in series configurations.
-
-- The resistances Rb and Ra are
-either automatically calculated using the multipole method,
-or the resistance Rb can be directly provided by the user.
-In this case, the resistances Rb and Ra are
-still evaluated internally, but their values are weighted so that the borehole
-resistance matches the specified value.
-
--
-User-defined vertical discretization of boreholes are supported.
-However, the borehole wall temperature
-is identical for each borehole, as the ground temperature response model only computes the average borehole wall temperature
-for all boreholes combined.
-
--
-Borefields can consist of one or many boreholes. Each borehole can be positioned
-at an arbitrary position in the field using cartesian coordinates.
-
--
-The resolution and precision of the load aggregation method for the ground heat transfer can be adapted.
-
--
-The thermal response of the ground heat transfer is stored locally to avoid
-having to recalculate it for future simulations with the same borefield configuration.
-
--
-Pressure losses are calculated if the
dp_nominal parameter is set to a non-zero value.
-
-
-
-
-The model is limited to the simulation of borefields with boreholes connected in
-parallel, as shown on the figure below for a single U-tube configuration. All
-boreholes have the same length hBor, the same radius
-rBor, and are buried at the same depth dBor below the
-ground surface (also known as the inactive borehole length).
-
-
-![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/BorefieldGeometry_01.png\")
-
-
-How to use the borefield models
-Borefield data record
-
-Most of the parameter values of the model are contained in the record called borFieDat.
-This record is composed of three subrecords:
-filDat (containing the thermal characteristics of the borehole filling material),
-soiDat (containing the thermal characteristics of the surrounding soil),
-and conDat (containing all others parameters, namely parameters
-defining the configuration of the borefield).
-The structure and default values of the record are in the package:
-AixLib.Fluid.Geothermal.Borefields.Data.
-The borFieDat record
-can be found in the
-AixLib.Fluid.Geothermal.Borefields.Data.Borefield subpackage therein.
-Examples of the subrecords conDat, filDat and soiDat
-can be found in
-
-AixLib.Fluid.Geothermal.Borefields.Data.Configuration,
-
-AixLib.Fluid.Geothermal.Borefields.Data.Filling and
-
-AixLib.Fluid.Geothermal.Borefields.Data.Soil, respectively.
-
-
-It is important to make sure that the borCon parameter within
-the conDat subrecord is compatible with the chosen borefield model.
-For example, if a double U-tube
-borefield model is chosen, the borCon parameter could be set
-to both a parallel double U-tube configuration and a double U-tube configuration in series,
-but could not be set to a single U-tube configuration. An incompatible borehole
-configuration will stop the simulation.
-
-Ground heat transfer parameters
-
-Other than the parameters contained in the borFieDat record,
-the borefield models have other parameters which can be modified by the user.
-The tLoaAgg parameter is the time resolution of the load aggregation
-for the calculation of the ground heat transfer. It represents the
-frequency at which the load aggregation procedure is performed in the simulation.
-Therefore, smaller values of tLoaAgg will improve
-the accuracy of the model, at the cost of increased simulation times
-due to a higher number of events occuring in the simulation. While a default value
-is provided for this parameter, it is advisable to ensure that it is lower
-than a fraction (e.g. half) of the time required for the fluid to completely circulate
-through the borefield,
-as increasing the value of tLoaAgg beyond this
-will result in non-physical borehole wall temperatures.
-
-
-The nCel parameter also affects the accuracy and simulation time
-of the ground heat transfer calculations. As this parameter sets the number
-of consecutive equal-size aggregation cells before increasing the size of cells,
-increasing its value will result in less load aggregation, which will increase
-accuracy at the cost of computation time. On the other hand,
-decreasing the value of nCel (down to a minimum of 1)
-will decrease accuracy but improve
-computation time. The default value is chosen as a compromise between the two.
+ Enumeration to define the choice of valve flow coefficient (to be
+ selected via choices menu):
+
+
+ |
+ Enumeration
+ |
+
+ Description
+ |
+
+
+ |
+ OpPoint
+ |
+
+ flow coefficient defined by ratio m_flow_nominal/sqrt(dp_nominal)
+ |
+
+
+ |
+ Kv
+ |
+
+ Kv (metric) flow coefficient
+ |
+
+
+ |
+ Cv
+ |
+
+ Cv (US) flow coefficient
+ |
+
+
+ |
+ Av
+ |
+
+ Av (metric) flow coefficient
+ |
+
+
-Further information on the tLoaAgg and nCel parameters can
-be found in the documentation of
-
-AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.GroundTemperatureResponse.
+ The details of the coefficients are explained in the
+ Users Guide.
-Other parameters
-Other parameters which can be modified include the dynamics, initial conditions,
-and further information regarding the fluid flow, for example whether the flow is reversible.
-It is worth noting that regardless of the energyDynamics chosen,
-the dynFil parameter can be set to false
-to remove the effect of the thermal capacitance
-of the filling material in the borehole(s).
-The nSeg parameter specifies the number of segments for the vertical discretization of the borehole(s).
-Further information on this discretization can be found in the "Model description" section below.
+ Enumeration that defines the heat exchanger construction.
-Running simulations
-When running simulations using the borefield models,
-the tmp/temperatureResponseMatrix directory within the current directory
-will be checked to see if any of the
-borefield configurations used in the simulation have already
-had their ground temperature response calculated previously
-If the data doesn't exist in the tmp/temperatureResponseMatrix folder,
-it will be calculated during the initialization of the model
-and will be saved there for future use.
-
-Model description
-
-The borefield models rely on the following key assumptions:
-
-- The thermal properties of the soil (conductivity and diffusivity) are constant,
-homogenous and isotropic.
-
--
-The conductivity, capacitance and density of the grout and pipe material are constant, homogenous and isotropic.
-
--
-There is no heat extraction or injection prior to the simulation start.
-
--
-All of the boreholes in the borefield have uniform dimensions (including the pipe dimensions).
-
--
-Inside the boreholes, the non-advective heat transfer is only in the radial direction.
-
-
-
-The borefield models are constructed in two main parts: the borehole(s) and the ground heat transfer.
-The former is modeled as a vertical discretization of borehole segments, where a uniform temperature increase or decrease
-(due to heat injection or extraction) is superimposed to the far-field ground temperature to obtain the borehole wall
-temperature. The thermal effects of the circulating fluid (including the convection resistance),
-of the pipes and of the filling material are all taken into consideration, which allows modeling
-short-term thermal effects in the borehole. The borehole segments do not take into account axial effects,
-thus only radial (horizontal) effects are considered within the borehole(s). The thermal
-behavior between the pipes and borehole wall are modeled as a resistance-capacitance network, with
-the grout capacitance being split in the number of pipes present in a borehole section.
-The capacitance is only present if the dynFil parameter is set to true.
-The figure below shows an example for a borehole section within a single U-tube configuration.
-
-
-![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/BoreholeResistances_01.png\")
-
-
-The second main part of the borefield models is the ground heat transfer, which shares a thermal boundary
-condition at the uniform borehole wall with all of the borehole segments. The heat transfer in the ground
-is modeled analytically as a convolution integral between the heat flux at the borehole wall
-and the borefield's thermal response factor.
-
-
-![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/LoadAggregation_12.png\")
-
-
-The model uses a load aggregation technique to reduce the time required to calculate
-the borehole wall temperature changes resulting from heat injection or extraction.
+ The following heat exchanger configurations are available in this
+ enumeration:
+
+
+ |
+ Enumeration
+ |
+
+ Description
+ |
+
+
+ |
+ ParallelFlow
+ |
+
+ Parallel flow
+ |
+
+
+ |
+ CounterFlow
+ |
+
+ Counter flow
+ |
+
+
+ |
+ CrossFlowUnmixed
+ |
+
+ Cross flow, both streams unmixed
+ |
+
+
+ |
+ CrossFlowStream1MixedStream2Unmixed
+ |
+
+ Cross flow, stream 1 mixed, stream 2 unmixed
+ |
+
+
+ |
+ CrossFlowStream1UnmixedStream2Mixed
+ |
+
+ Cross flow, stream 1 unmixed, stream 2 mixed
+ |
+
+
+ |
+ ConstantTemperaturePhaseChange
+ |
+
+ Constant temperature phase change in one stream
+ |
+
+
-The ground heat transfer takes into account both the borehole axial effects and
-the borehole radial effects which are a result of its cylindrical geometry. The borefield's
-thermal response to a constant load, also known as its g-function, is used
-to calculate the thermal response in the simulation. This g-function
-is stored in the tmp/temperatureResponseMatrix subdirectory,
-as discussed previously in the
-"How to use the borefield models" section. Further information on the
-ground heat transfer model and the thermal temperature response calculations can
-be found in
-
-AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.GroundTemperatureResponse
-and
-
-AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.gFunction.
+ Note that for a given heat exchanger, the
+ HeatExchangerConfiguration is fixed. However, if the
+ capacity flow rates change, then the AixLib.Fluid.Types.HeatExchangerFlowRegime
+ may change. For example, a counter flow heat exchanger has
+ HeatExchangerConfiguration=CounterFlow, but the AixLib.Fluid.Types.HeatExchangerFlowRegime
+ can change to parallel flow if one of the two capacity flow rates
+ reverts its direction.
-References
+
+ - March 27, 2017, by Michael Wetter:
+ Added ConstantTemperaturePhaseChange.
+ This is for AixLib
+ #694.
+
+ - February 18, 2009, by Michael Wetter:
+ First implementation.
+
+
-D. Picard, L. Helsen.
-Advanced Hybrid Model for Borefield Heat
-Exchanger Performance Evaluation; an Implementation in Modelica
-Proc. of the 10th Intertional ModelicaConference, p. 857-866. Lund, Sweden. March 2014.
-https://lirias.kuleuven.be/retrieve/270880.
+ Enumeration to define the heat exchanger flow regime.
-
--------- Corrected Code --------
- This package contains borefield models. These models can simulate any
- arbitrary configuration of vertical boreholes with equal lengths with
- both short and long-term accuracy with an aggregation method to speed
- up the calculations of the ground heat transfer. Examples of how to
- use the borefield models and validation cases can be found in
- AixLib.Fluid.Geothermal.Borefields.Examples
- and AixLib.Fluid.Geothermal.Borefields.Validation,
- respectively.
+ This enumeration defines for the current capacity flow rate the kind
+ of heat transfer relation that will be used to compute the relation
+ between effectiveness and Number of Transfer Units.
- The major features and configurations currently supported are:
+ The following heat exchanger flow regimes are available in this
+ enumeration:
+
+
+ |
+ Enumeration
+ |
+
+ Description
+ |
+
+
+ |
+ ParallelFlow
+ |
+
+ Parallel flow
+ |
+
+
+ |
+ CounterFlow
+ |
+
+ Counter flow
+ |
+
+
+ |
+ CrossFlowUnmixed
+ |
+
+ Cross flow, both streams unmixed
+ |
+
+
+ |
+ CrossFlowCMinMixedCMaxUnmixed
+ |
+
+ Cross flow, CMin mixed, CMax unmixed
+ |
+
+
+ |
+ CrossFlowCMinUnmixedCMaxMixed
+ |
+
+ Cross flow, CMin unmixed, CMax mixed
+ |
+
+
+ |
+ ConstantTemperaturePhaseChange
+ |
+
+ Constant temperature phase change in one stream
+ |
+
+
- - User-defined borefield characteristics and geometry (borehole
- radius, pipe radius, shank spacing, etc.), including single U-tube,
- double U-tube in parallel and double U-tube in series configurations.
-
- - The resistances Rb and Ra are
- either automatically calculated using the multipole method, or the
- resistance Rb can be directly provided by the user.
- In this case, the resistances Rb and
- Ra are still evaluated internally, but their values
- are weighted so that the borehole resistance matches the specified
- value.
+
- March 27, 2017, by Michael Wetter:
+ Added ConstantTemperaturePhaseChange.
+ This is for AixLib
+ #694.
- - User-defined vertical discretization of boreholes are supported.
- However, the borehole wall temperature is identical for each
- borehole, as the ground temperature response model only computes the
- average borehole wall temperature for all boreholes combined.
+
- February 18, 2009, by Michael Wetter:
+ First implementation.
- - Borefields can consist of one or many boreholes. Each borehole
- can be positioned at an arbitrary position in the field using
- cartesian coordinates.
+
+
+ This type allows defining which type of input should be used for
+ movers. This can either be
+
+
+ - a constant set point declared by a parameter,
- - The resolution and precision of the load aggregation method for
- the ground heat transfer can be adapted.
+
- a series of possible set points that can be switched using an
+ integer input, or
- - The thermal response of the ground heat transfer is stored
- locally to avoid having to recalculate it for future simulations with
- the same borefield configuration.
+
- a continuously variable set point.
- - Pressure losses are calculated if the
dp_nominal
- parameter is set to a non-zero value.
+
+
+ - April 2, 2015, by Filip Jorissen:
+ First implementation.
- The model is limited to the simulation of borefields with boreholes
- connected in parallel, as shown on the figure below for a single
- U-tube configuration. All boreholes have the same length
- hBor, the same radius rBor, and are buried
- at the same depth dBor below the ground surface (also
- known as the inactive borehole length).
-
-
-
-
-
- How to use the borefield models
-
-
- Borefield data record
-
-
- Most of the parameter values of the model are contained in the record
- called borFieDat. This record is composed of three
- subrecords: filDat (containing the thermal
- characteristics of the borehole filling material),
- soiDat (containing the thermal characteristics of the
- surrounding soil), and conDat (containing all others
- parameters, namely parameters defining the configuration of the
- borefield). The structure and default values of the record are in the
- package: AixLib.Fluid.Geothermal.Borefields.Data.
- The borFieDat record can be found in the AixLib.Fluid.Geothermal.Borefields.Data.Borefield
- subpackage therein. Examples of the subrecords conDat,
- filDat and soiDat can be found in AixLib.Fluid.Geothermal.Borefields.Data.Configuration,
- AixLib.Fluid.Geothermal.Borefields.Data.Filling
- and AixLib.Fluid.Geothermal.Borefields.Data.Soil,
- respectively.
-
-
- It is important to make sure that the borCon parameter
- within the conDat subrecord is compatible with the
- chosen borefield model. For example, if a double U-tube borefield
- model is chosen, the borCon parameter could be set to
- both a parallel double U-tube configuration and a double U-tube
- configuration in series, but could not be set to a single U-tube
- configuration. An incompatible borehole configuration will stop the
- simulation.
-
-
- Ground heat transfer parameters
-
-
- Other than the parameters contained in the borFieDat
- record, the borefield models have other parameters which can be
- modified by the user. The tLoaAgg parameter is the time
- resolution of the load aggregation for the calculation of the ground
- heat transfer. It represents the frequency at which the load
- aggregation procedure is performed in the simulation. Therefore,
- smaller values of tLoaAgg will improve the accuracy of
- the model, at the cost of increased simulation times due to a higher
- number of events occuring in the simulation. While a default value is
- provided for this parameter, it is advisable to ensure that it is
- lower than a fraction (e.g. half) of the time required for the fluid
- to completely circulate through the borefield, as increasing the
- value of tLoaAgg beyond this will result in non-physical
- borehole wall temperatures.
+ This package contains type definitions.
+
+-------- Errors --------
+line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+
+
+line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+
+
+line 13 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+
+
+---- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/PlugFlowULg.mo ----
+-------- HTML Code --------
+
+
+ The example contains
+ experimental data from a real district heating network.
+
+
+ This model compares the results with the original Modelica Standard Library pipes.
+
+ The pipes' temperatures are not initialized. Therefore, results of
+ outflow temperature before approximately the first 10000 seconds should not be
+ considered.
+
+ Test bench schematic
+ ![\"Schematic](\"modelica://AixLib/Resources/Images/Fluid/FixedResistances/Validation/PlugFlowPipes/ULgTestBench.png\"/)
+ Calibration
+
+ There are some uncertainties about the heat loss coefficient between pipe and
+ surrounding air as well as regarding the heat conductivity of the insulation
+ material.
+ With the
+ given data, the length specific thermal resistance is R = 2.164
+ ((m K)/W), calculated as follows:
+
+
+ R=((1/(2*pipe.kIns)*log((0.0603+2*pipe.dIns)/(0.0603)))+1/(5*(0.0603+2*pipe.dIns)))/Modelica.Constants.pi
+
+ U = 1/R = 0.462 W/(m K)
+
+
+ -
+ March 7, 2020, by Michael Wetter:
+ Replaced measured data from specification in Modelica file to external table,
+ as this reduces the computing time.
+ This is for
+ #1289.
+
+ -
+ November 24, 2016 by Bram van der Heijde:
Add pipe thickness for wall
+ capacity calculation and expand documentation section.
+ - April 2, 2016 by Bram van der Heijde:
Change thermal conductivity and
+ put boundary condition in K.
+
+ - Januar 26, 2016 by Carles Ribas:
First implementation.
+
+
+
+-------- Corrected Code --------
- The nCel parameter also affects the accuracy and
- simulation time of the ground heat transfer calculations. As this
- parameter sets the number of consecutive equal-size aggregation cells
- before increasing the size of cells, increasing its value will result
- in less load aggregation, which will increase accuracy at the cost of
- computation time. On the other hand, decreasing the value of
- nCel (down to a minimum of 1) will decrease accuracy but
- improve computation time. The default value is chosen as a compromise
- between the two.
+ The example contains experimental data from a real district heating
+ network.
- Further information on the tLoaAgg and nCel
- parameters can be found in the documentation of
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.GroundTemperatureResponse.
+ This model compares the results with the original Modelica Standard
+ Library pipes.
-
- Other parameters
-
- Other parameters which can be modified include the dynamics, initial
- conditions, and further information regarding the fluid flow, for
- example whether the flow is reversible. It is worth noting that
- regardless of the energyDynamics chosen, the
- dynFil parameter can be set to false to
- remove the effect of the thermal capacitance of the filling material
- in the borehole(s). The nSeg parameter specifies the
- number of segments for the vertical discretization of the
- borehole(s). Further information on this discretization can be found
- in the \"Model description\" section below.
+ The pipes' temperatures are not initialized. Therefore, results of
+ outflow temperature before approximately the first 10000 seconds
+ should not be considered.
-
- Running simulations
-
+
+ Test bench schematic
+
- When running simulations using the borefield models, the
- tmp/temperatureResponseMatrix directory within the
- current directory will be checked to see if any of the borefield
- configurations used in the simulation have already had their ground
- temperature response calculated previously If the data doesn't exist
- in the tmp/temperatureResponseMatrix folder, it will be
- calculated during the initialization of the model and will be saved
- there for future use.
+
- Model description
+ Calibration
- The borefield models rely on the following key assumptions:
+ There are some uncertainties about the heat loss coefficient between
+ pipe and surrounding air as well as regarding the heat conductivity
+ of the insulation material. With the
+ given data, the length specific thermal resistance is R =
+ 2.164 ((m K)/W), calculated as follows:
+
+
+ R=((1/(2*pipe.kIns)*log((0.0603+2*pipe.dIns)/(0.0603)))+1/(5*(0.0603+2*pipe.dIns)))/Modelica.Constants.pi
+
+
+ U = 1/R = 0.462 W/(m K)
- - The thermal properties of the soil (conductivity and diffusivity)
- are constant, homogenous and isotropic.
-
- - The conductivity, capacitance and density of the grout and pipe
- material are constant, homogenous and isotropic.
+
- March 7, 2020, by Michael Wetter:
+ Replaced measured data from specification in Modelica file to
+ external table, as this reduces the computing time.
+ This is for #1289.
- - There is no heat extraction or injection prior to the simulation
- start.
+
- November 24, 2016 by Bram van der Heijde:
+ Add pipe thickness for wall capacity calculation and expand
+ documentation section.
- - All of the boreholes in the borefield have uniform dimensions
- (including the pipe dimensions).
+
- April 2, 2016 by Bram van der Heijde:
+ Change thermal conductivity and put boundary condition in K.
- - Inside the boreholes, the non-advective heat transfer is only in
- the radial direction.
+
- Januar 26, 2016 by Carles Ribas:
+ First implementation.
+
+-------- Errors --------
+line 25 column 2 - Warning: attribute "align" not allowed for HTML5
+line 27 column 2 - Warning:
attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/HeatExchangers/ActiveBeams/UsersGuide.mo ----
+-------- HTML Code --------
+
- The borefield models are constructed in two main parts: the
- borehole(s) and the ground heat transfer. The former is modeled as a
- vertical discretization of borehole segments, where a uniform
- temperature increase or decrease (due to heat injection or
- extraction) is superimposed to the far-field ground temperature to
- obtain the borehole wall temperature. The thermal effects of the
- circulating fluid (including the convection resistance), of the pipes
- and of the filling material are all taken into consideration, which
- allows modeling short-term thermal effects in the borehole. The
- borehole segments do not take into account axial effects, thus only
- radial (horizontal) effects are considered within the borehole(s).
- The thermal behavior between the pipes and borehole wall are modeled
- as a resistance-capacitance network, with the grout capacitance being
- split in the number of pipes present in a borehole section. The
- capacitance is only present if the dynFil parameter is
- set to true. The figure below shows an example for a
- borehole section within a single U-tube configuration.
+This package contains models of active beams.
+Active beams are devices used for heating, cooling and ventilation of spaces.
+A schematic diagram of an active beam unit is given below.
-
-
+
+
- The second main part of the borefield models is the ground heat
- transfer, which shares a thermal boundary condition at the uniform
- borehole wall with all of the borehole segments. The heat transfer in
- the ground is modeled analytically as a convolution integral between
- the heat flux at the borehole wall and the borefield's thermal
- response factor.
-
-
-
+The active beam unit consists of a primary air plenum, a mixing chamber, a heat exchanger (coil) and several nozzles.
+Typically, an air-handling unit supplies primary air to the active beams.
+The primary air is discharged to the mixing chamber through the nozzles.
+This generates a low-pressure region which induces air from the room up through the heat exchanger,
+where hot or cold water is circulating.
+The conditioned induced air is then mixed with primary air, and the mixture descents back to the space.
- The model uses a load aggregation technique to reduce the time
- required to calculate the borehole wall temperature changes resulting
- from heat injection or extraction.
+This package contains two models. The model
+
+AixLib.Fluid.HeatExchangers.ActiveBeams.Cooling
+is for cooling only, while the model
+
+AixLib.Fluid.HeatExchangers.ActiveBeams.CoolingAndHeating
+has two water streams, one for heating and one for cooling.
+
+Model equations for cooling
- The ground heat transfer takes into account both the borehole axial
- effects and the borehole radial effects which are a result of its
- cylindrical geometry. The borefield's thermal response to a constant
- load, also known as its g-function, is used to calculate the
- thermal response in the simulation. This g-function is stored in the
- tmp/temperatureResponseMatrix subdirectory, as discussed
- previously in the \"How to use the borefield models\" section. Further
- information on the ground heat transfer model and the thermal
- temperature response calculations can be found in
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.GroundTemperatureResponse
- and
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.gFunction.
+The performance of the model
+
+AixLib.Fluid.HeatExchangers.ActiveBeams.Cooling
+is computed based on manufacturer data
+specified in the package
+
+AixLib.Fluid.HeatExchangers.ActiveBeams.Data.
-
- References
-
- D. Picard, L. Helsen. Advanced Hybrid Model for Borefield Heat
- Exchanger Performance Evaluation; an Implementation in Modelica
- Proc. of the 10th Intertional ModelicaConference, p. 857-866. Lund,
- Sweden. March 2014. https://lirias.kuleuven.be/retrieve/270880.
+For off-design conditions, the performance is adjusted using modification factors
+that account for changes in water flow rate,
+primary air flow rate and temperature difference.
+The total heat flow rate of the active beam unit is the sum of the heat flow rate provided by the primary air supply
+Qsa and the cooling heat flow rate provided by the beam convector Qc,Beam
+which injects room air and mixes it with the primary air.
+
+The heat flow rate
+Qsa is delivered to a thermal zone
+through the fluid ports, while the heat flow rate from the convector Qc,Beam
+is coupled directly to the heat port.
+See for example
+
+AixLib.Fluid.HeatExchangers.ActiveBeams.Examples.CoolingOnly
+for how to connect these heat flow rates to a control volume.
+
+
+The primary air contribution is
+
+
+ Qsa = ṁsa cp,sa (Tsa-Tz)
+
+
+where ṁsa is the primary air mass flow rate,
+cp,sa is the air specific heat capacity,
+Tsa is the primary air temperature
+and Tz is the zone air temperature.
+
+
+The heat flow rate of the beam convector Qc,Beam is determined using
+the rated capacity which is modified by three separate functions as
+
+
+ Qc,Beam = Qc,nominal
+fΔT ( ΔTc ⁄ ΔTc,nominal )
+fsa( ṁsa ⁄ ṁsa,nominal )
+fw( ṁc,w ),
+
+
+the modification factors are as follows:
+The modification factor fΔT(·)
+describes how the capacity is adjusted to account for the temperature difference
+between the zone air and the water entering the convector.
+The independent variable is the ratio between the current temperature difference
+ΔTc and the temperature difference used to rate beam performance ΔTc,nominal.
+The temperature difference is
+
+
+ ΔTc = Tcw-Tz,
+
+
+where Tcw is the chilled water temperature entering the convector.
--------- Errors --------
-line 56 column 1 - Warning:
attribute "align" not allowed for HTML5
-line 179 column 1 - Warning:
attribute "align" not allowed for HTML5
-line 188 column 1 - Warning:
attribute "align" not allowed for HTML5
-
+The modification factor fsa(·) adjusts the cooling capacity to account for varying primary air flow rate.
+The independent variable is the ratio between the current primary air flow rate ṁsa
+and the nominal air flow rate used to rate the beam performance.
----- AixLib/Fluid/Geothermal/Borefields/Types.mo ----
--------- HTML Code --------
+The modification factor fw(·) adjusts the cooling capacity for changes in water flow rate through the convector.
+The independent variable is the ratio between the current water flow rate ṁw
+and the nominal water flow rate used to rate the beam performance.
+
-
- Enumeration that defines the pipe configuration in the borehole.
-
-
- The following pipe configurations are available in this enumeration:
-
-
- | Enumeration | Description |
|---|
- | SingleUTube | Single U-tube configuration |
-
- | DoubleUTubeParallel | Double U-tube configuration with pipes connected in parallel |
- | DoubleUTubeSeries | Double U-tube configuration with pipes connected in series |
-
-
-
- -
- July 15, 2018, by Michael Wetter:
- First implementation.
-
-
-
-
- This package contains type definitions.
-
-
--------- Corrected Code --------
+Model equations for heating
- Enumeration that defines the pipe configuration in the borehole.
+The performance of the model
+
+AixLib.Fluid.HeatExchangers.ActiveBeams.CoolingAndHeating
+is computed identical to the above described model that only provides cooling,
+with the exception that this model contains an additional water stream that
+can be used to provide heating.
- The following pipe configurations are available in this enumeration:
+For the heating water stream, the temperature difference ΔTh
+used for the calculation of the modification factor fΔT(·) is
+
+
+ΔTh = Thw-Tz,
-
-
- |
- Enumeration
- |
-
- Description
- |
-
-
- |
- SingleUTube
- |
-
- Single U-tube configuration
- |
-
-
- |
- DoubleUTubeParallel
- |
-
- Double U-tube configuration with pipes connected in parallel
- |
-
-
- |
- DoubleUTubeSeries
- |
-
- Double U-tube configuration with pipes connected in series
- |
-
-
-
- - July 15, 2018, by Michael Wetter:
- First implementation.
-
-
- This package contains type definitions.
+where Thw is the hot water temperature entering the convector in heating mode
+and Tz is the zone air temperature.
--------- Errors --------
-line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-
+Dynamics
+
+The model can be configured to be steady-state or dynamic.
+If configured as dynamic, then a dynamic conservation equation is applied to the water streams
+for heating and for cooling.
+However, because the capacity of the beam depends on its inlet temperature, and is independent of the
+outlet temperature, the heat transferred
+to the room at the port heaPor.Q_flow, as well as the heat added to or removed from the
+water streams, will instantaneously change.
+The only dynamic responses are the water outlet temperatures, which change with a first
+order response, parameterized with the time constant tau.
+
----- AixLib/Fluid/HeatExchangers/Radiators/RadiatorEN442_2.mo ----
--------- HTML Code --------
+Energy balance
+
+All heat flow rate that is added to or extracted from the room is transmitted through the heat port
+heaPor. Hence, this model does not cool the supply air between the ports
+air_a and air_b. Rather, it adds this heat flow rate
+to the heat port heaPor.
+The rationale for this implementation is that the beam transfers heat by convection directly to the room, and
+by induction of room air into the supply air. As this split of heat flow rate is generally not known,
+and because the amount of inducted air is also unknown,
+it was decided to transfer all heat through the heat port heaPor.
+This also avoids having to add an extra air flow path for the air induced from the room.
+
-
- This is a model of a radiator that can be used as a dynamic or steady-state model.
- The required parameters are data that are typically available from
- manufacturers that follow the European Norm EN 442-2.
-
-
- However, to allow for varying mass flow rates, the transferred heat is computed
- using a discretization along the water flow path, and heat is exchanged between
- each compartment and a uniform room air and radiation temperature.
- This discretization is different from the computation in EN 442-2, which
- may yield water outlet temperatures that are below
- the room temperature at low mass flow rates.
- Furthermore, rather than using only one room temperature, this model uses
- a room air and room radiation temperature.
-
-
- The transferred heat is modeled as follows:
- Let N denote the number of elements used to discretize the radiator model.
- For each element i ∈ {1, … , N},
- the convective and radiative heat transfer
- Qic and
- Qir
- from the radiator to the room is
-
-
- Qic = sign(Ti-Ta)
- (1-fr) UA ⁄ N |Ti-Ta|n
-
- Qir = sign(Ti-Tr)
- fr UA ⁄ N |Ti-Tr|n
-
-
- where
- Ti is the water temperature of the element,
- Ta is the temperature of the room air,
- Tr is the radiative temperature,
- 0 < fr < 1 is the fraction of radiant to total heat transfer,
- UA is the UA-value of the radiator,
- and
- n is an exponent for the heat transfer.
- The model computes the UA-value by numerically solving the above equations
- for given
- nominal heating power, nominal temperatures, fraction radiant to total heat transfer
- and exponent for heat transfer.
+-------- Corrected Code --------
+
+ This package contains models of active beams. Active beams are
+ devices used for heating, cooling and ventilation of spaces. A
+ schematic diagram of an active beam unit is given below.
+
+
+
+
+
+ The active beam unit consists of a primary air plenum, a mixing
+ chamber, a heat exchanger (coil) and several nozzles. Typically, an
+ air-handling unit supplies primary air to the active beams. The
+ primary air is discharged to the mixing chamber through the nozzles.
+ This generates a low-pressure region which induces air from the room
+ up through the heat exchanger, where hot or cold water is
+ circulating. The conditioned induced air is then mixed with primary
+ air, and the mixture descents back to the space.
+
+
+ This package contains two models. The model AixLib.Fluid.HeatExchangers.ActiveBeams.Cooling
+ is for cooling only, while the model
+ AixLib.Fluid.HeatExchangers.ActiveBeams.CoolingAndHeating has two
+ water streams, one for heating and one for cooling.
+
+
+ Model equations for cooling
+
+
+ The performance of the model AixLib.Fluid.HeatExchangers.ActiveBeams.Cooling
+ is computed based on manufacturer data specified in the package
+ AixLib.Fluid.HeatExchangers.ActiveBeams.Data.
+
+
+ For off-design conditions, the performance is adjusted using
+ modification factors that account for changes in water flow rate,
+ primary air flow rate and temperature difference. The total heat flow
+ rate of the active beam unit is the sum of the heat flow rate
+ provided by the primary air supply Qsa and the
+ cooling heat flow rate provided by the beam convector
+ Qc,Beam which injects room air and mixes it with
+ the primary air.
+
+
+ The heat flow rate Qsa is delivered to a thermal
+ zone through the fluid ports, while the heat flow rate from the
+ convector Qc,Beam is coupled directly to the heat
+ port. See for example
+ AixLib.Fluid.HeatExchangers.ActiveBeams.Examples.CoolingOnly for
+ how to connect these heat flow rates to a control volume.
+
+
+ The primary air contribution is
+
+
+ Qsa = ṁsa cp,sa
+ (Tsa-Tz)
+
+
+ where ṁsa is the primary air mass flow rate,
+ cp,sa is the air specific heat capacity,
+ Tsa is the primary air temperature and
+ Tz is the zone air temperature.
+
+
+ The heat flow rate of the beam convector Qc,Beam is
+ determined using the rated capacity which is modified by three
+ separate functions as
+
+
+ Qc,Beam = Qc,nominal fΔT (
+ ΔTc ⁄ ΔTc,nominal ) fsa(
+ ṁsa ⁄ ṁsa,nominal ) fw(
+ ṁc,w ),
+
+
+ the modification factors are as follows: The modification factor
+ fΔT(·) describes how the capacity is adjusted to
+ account for the temperature difference between the zone air and the
+ water entering the convector. The independent variable is the ratio
+ between the current temperature difference ΔTc and
+ the temperature difference used to rate beam performance
+ ΔTc,nominal. The temperature difference is
+
+
+ ΔTc = Tcw-Tz,
+
+
+ where Tcw is the chilled water temperature entering
+ the convector. The modification factor fsa(·)
+ adjusts the cooling capacity to account for varying primary air flow
+ rate. The independent variable is the ratio between the current
+ primary air flow rate ṁsa and the nominal air flow
+ rate used to rate the beam performance. The modification factor
+ fw(·) adjusts the cooling capacity for changes in
+ water flow rate through the convector. The independent variable is
+ the ratio between the current water flow rate ṁw
+ and the nominal water flow rate used to rate the beam performance.
+
+
+ Model equations for heating
+
+
+ The performance of the model
+ AixLib.Fluid.HeatExchangers.ActiveBeams.CoolingAndHeating is
+ computed identical to the above described model that only provides
+ cooling, with the exception that this model contains an additional
+ water stream that can be used to provide heating.
+
+
+ For the heating water stream, the temperature difference
+ ΔTh used for the calculation of the
+ modification factor fΔT(·) is
+
+
+ ΔTh = Thw-Tz,
+
+
+ where Thw is the hot water temperature entering the
+ convector in heating mode and Tz is the zone air
+ temperature.
+
+
+ Dynamics
+
+
+ The model can be configured to be steady-state or dynamic. If
+ configured as dynamic, then a dynamic conservation equation is
+ applied to the water streams for heating and for cooling. However,
+ because the capacity of the beam depends on its inlet temperature,
+ and is independent of the outlet temperature, the heat transferred to
+ the room at the port heaPor.Q_flow, as well as the heat
+ added to or removed from the water streams, will instantaneously
+ change. The only dynamic responses are the water outlet temperatures,
+ which change with a first order response, parameterized with the time
+ constant tau.
+
+
+ Energy balance
+
+
+ All heat flow rate that is added to or extracted from the room is
+ transmitted through the heat port heaPor. Hence, this
+ model does not cool the supply air between the ports
+ air_a and air_b. Rather, it adds this heat
+ flow rate to the heat port heaPor. The rationale for
+ this implementation is that the beam transfers heat by convection
+ directly to the room, and by induction of room air into the supply
+ air. As this split of heat flow rate is generally not known, and
+ because the amount of inducted air is also unknown, it was decided to
+ transfer all heat through the heat port heaPor. This
+ also avoids having to add an extra air flow path for the air induced
+ from the room.
+
+
+-------- Errors --------
+line 7 column 1 - Warning: attribute "align" not allowed for HTML5
+line 59 column 1 - Warning:
attribute "align" not allowed for HTML5
+line 72 column 1 - Warning:
attribute "align" not allowed for HTML5
+line 87 column 1 - Warning:
attribute "align" not allowed for HTML5
+line 115 column 1 - Warning:
attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Chillers/BaseClasses/Carnot.mo ----
+-------- HTML Code --------
+
+
+ This is the base class for the Carnot chiller and the Carnot heat pump
+ whose coefficient of performance COP changes
+ with temperatures in the same way as the Carnot efficiency changes.
- The parameter energyDynamics (in the Assumptions tab),
- determines whether the model computes the dynamic or the steady-state response.
- For the transient response, heat storage is computed using a
- finite volume approach for the
- water and the metal mass, which are both assumed to be at the same
- temperature.
+ The model allows to either specify the Carnot effectivness
+ ηCarnot,0, or
+ a COP0
+ at the nominal conditions, together with
+ the evaporator temperature Teva,0 and
+ the condenser temperature Tcon,0, in which
+ case the model computes the Carnot effectivness as
+
+
+ ηCarnot,0 =
+ COP0
+ ⁄ (Tuse,0 ⁄ (Tcon,0-Teva,0)),
- The default parameters for the heat capacities are valid for a flat plate radiator without fins,
- with one plate of water carying fluid, and a height of 0.42 meters.
+ where
+ Tuse is the temperature of the the useful heat,
+ e.g., the evaporator temperature for a chiller or the condenser temperature
+ for a heat pump.
+
+
+ The COP is computed as the product
+
+
+ COP = ηCarnot,0 COPCarnot ηPL,
+
+
+ where COPCarnot is the Carnot efficiency and
+ ηPL is the part load efficiency, expressed using
+ a polynomial.
+ This polynomial has the form
+
+
+ ηPL = a1 + a2 y + a3 y2 + ...
+
+
+ where y ∈ [0, 1] is
+ either the part load for cooling in case of a chiller, or the part load of heating in
+ case of a heat pump, and the coefficients ai
+ are declared by the parameter a.
+
+ Implementation
+
+ To make this base class applicable to chiller or heat pumps, it uses
+ the boolean constant COP_is_for_cooling.
+ Depending on its value, the equations for the coefficient of performance
+ and the part load ratio are set up.
-
- March 7, 2022, by Michael Wetter:
- Set final massDynamics=energyDynamics.
- This is for
- #1542.
-
- -
April 14, 2020, by Michael Wetter:
Changed homotopyInitialization to a constant.
This is for
IBPSA, #1341.
-
- February 21, 2020, by Michael Wetter:
- Changed icon to display its operating state.
- This is for
- #1294.
-
- -
- November 17, 2016, by Filip Jorissen:
- Added pressure drop equations and parameters.
- This is for
- #586.
+ September 12, 2019, by Michael Wetter:
+ Corrected value of evaluate_etaPL and how it is used.
+ This correction only affects protected variables and does not affect the results.
+ This is for
+ #1200.
-
- November 3, 2016, by Michael Wetter:
- Set preHea(final alpha=0) as this allows to simplify the
- system of equations.
- This is for
- #570.
+ June 16, 2017, by Michael Wetter:
+ Added temperature difference between fluids in condenser and evaporator
+ for computation of nominal COP and effectiveness.
+ This is for
+ #698.
-
- March 17, 2016, by Michael Wetter:
- Reformulated model to reduce the dimension of the nonlinear system of equations.
- This is for
- #435.
+ March 28, 2017, by Felix Buenning:
+ Added temperature difference between fluids in condenser and evaporator.
+ The difference is based on discussions with Emerson Climate Technologies.
+ This is for
+ #698.
-
- November 19, 2015, by Michael Wetter:
- Removed assignment of parameter
- showDesignFlowDirection in extends statement.
+ January 2, 2017, by Filip Jorissen:
+ Removed option for choosing what temperature
+ should be used to compute the Carnot efficiency.
This is for
- #349.
-
- -
- April 11, 2015, by Filip Jorissen:
- Propagated vol.massDynamics to
- top level parameter massDynamics instead of energyDynamics.
-
- -
- November 25, 2014, by Carles Ribas Tugores:
- Interchange position of fraRad parameter and the complementary (1-fraRad)
- in the equation used to calculate the nominal heating power of each element, QEle_flow_nominal[i].
-
- -
- October 29, 2014, by Michael Wetter:
- Made assignment of mFactor final, and changed computation of
- density to use default medium states as are also used to compute the
- specific heat capacity.
-
- -
- October 21, 2014, by Filip Jorissen:
- Added parameter mFactor and removed thermal capacity
- which can lead to an index reduction.
-
- -
- May 29, 2014, by Michael Wetter:
- Removed undesirable annotation Evaluate=true.
-
- -
- October 8, 2013 by Michael Wetter:
- Removed conditional statement in the declaration of the parameter
- mDry, as this is incorrect syntax.
-
- -
- September 26, 2013 by Michael Wetter:
- Reformulated implementation to avoid mixing textual and graphical
- declarations in the equation section.
-
- -
- April 4, 2011 by Michael Wetter:
- Changed the implementation to use
-
- AixLib.Utilities.Math.Functions.regNonZeroPower.
- This allows formulating the model without any non-differentiable function
- inside the equation section.
-
- -
- April 2, 2011 by Michael Wetter:
- Added homotopy operator.
-
- -
- February 11, 2011 by Michael Wetter:
- Revised the initialization to ensure that at the nominal conditions, the
- amount of transferred heat is excatly the same as the specified nominal power.
- In the previous implementation, the UA-value was computed using a simplified
- expression for the temperature difference, leading to a slightly different amount
- of heat transfer.
-
- -
- February 4, 2011 by Michael Wetter:
- Simplified implementation.
+
+ issue 497.
-
- January 30, 2009 by Michael Wetter:
- First implementation.
+ January 26, 2016, by Michael Wetter:
+ First implementation of this base class.
-------- Corrected Code --------
- This is a model of a radiator that can be used as a dynamic or
- steady-state model. The required parameters are data that are
- typically available from manufacturers that follow the European Norm
- EN 442-2.
+ This is the base class for the Carnot chiller and the Carnot heat
+ pump whose coefficient of performance COP changes with temperatures
+ in the same way as the Carnot efficiency changes.
- However, to allow for varying mass flow rates, the transferred heat
- is computed using a discretization along the water flow path, and
- heat is exchanged between each compartment and a uniform room air and
- radiation temperature. This discretization is different from the
- computation in EN 442-2, which may yield water outlet temperatures
- that are below the room temperature at low mass flow rates.
- Furthermore, rather than using only one room temperature, this model
- uses a room air and room radiation temperature.
+ The model allows to either specify the Carnot effectivness
+ ηCarnot,0, or a COP0 at the
+ nominal conditions, together with the evaporator temperature
+ Teva,0 and the condenser temperature
+ Tcon,0, in which case the model computes the Carnot
+ effectivness as
+
+
+ ηCarnot,0 = COP0 ⁄ (Tuse,0 ⁄
+ (Tcon,0-Teva,0)),
- The transferred heat is modeled as follows: Let N denote the
- number of elements used to discretize the radiator model. For each
- element i ∈ {1, … , N}, the convective and radiative heat
- transfer Qic and
- Qir from the radiator to the room is
+ where Tuse is the temperature of the the useful
+ heat, e.g., the evaporator temperature for a chiller or the condenser
+ temperature for a heat pump.
+
+
+ The COP is computed as the product
- Qic = sign(Ti-Ta)
- (1-fr) UA ⁄ N
- |Ti-Ta|n
-
- Qir = sign(Ti-Tr)
- fr UA ⁄ N |Ti-Tr|n
+ COP = ηCarnot,0 COPCarnot ηPL,
- where Ti is the water temperature of the element,
- Ta is the temperature of the room air,
- Tr is the radiative temperature, 0 <
- fr < 1 is the fraction of radiant to total heat
- transfer, UA is the UA-value of the radiator, and n is
- an exponent for the heat transfer. The model computes the UA-value by
- numerically solving the above equations for given nominal heating
- power, nominal temperatures, fraction radiant to total heat transfer
- and exponent for heat transfer.
+ where COPCarnot is the Carnot efficiency and
+ ηPL is the part load efficiency, expressed using a
+ polynomial. This polynomial has the form
+
+
+ ηPL = a1 + a2 y + a3
+ y2 + ...
- The parameter energyDynamics (in the Assumptions tab),
- determines whether the model computes the dynamic or the steady-state
- response. For the transient response, heat storage is computed using
- a finite volume approach for the water and the metal mass, which are
- both assumed to be at the same temperature.
+ where y ∈ [0, 1] is either the part load for cooling in case
+ of a chiller, or the part load of heating in case of a heat pump, and
+ the coefficients ai are declared by the parameter
+ a.
+
+ Implementation
+
- The default parameters for the heat capacities are valid for a flat
- plate radiator without fins, with one plate of water carying fluid,
- and a height of 0.42 meters.
+ To make this base class applicable to chiller or heat pumps, it uses
+ the boolean constant COP_is_for_cooling. Depending on
+ its value, the equations for the coefficient of performance and the
+ part load ratio are set up.
- - March 7, 2022, by Michael Wetter:
- Set final massDynamics=energyDynamics.
- This is for #1542.
-
- April 14, 2020, by Michael Wetter:
Changed homotopyInitialization to a constant.
This is for IBPSA,
#1341.
- - February 21, 2020, by Michael Wetter:
- Changed icon to display its operating state.
+ - September 12, 2019, by Michael Wetter:
+ Corrected value of evaluate_etaPL and how it is used.
+ This correction only affects protected variables and does not
+ affect the results.
This is for #1294.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/1200\">#1200.
- - November 17, 2016, by Filip Jorissen:
- Added pressure drop equations and parameters.
+ - June 16, 2017, by Michael Wetter:
+ Added temperature difference between fluids in condenser and
+ evaporator for computation of nominal COP and effectiveness.
This is for #586.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/698\">#698.
- - November 3, 2016, by Michael Wetter:
- Set preHea(final alpha=0) as this allows to simplify
- the system of equations.
+ - March 28, 2017, by Felix Buenning:
+ Added temperature difference between fluids in condenser and
+ evaporator. The difference is based on discussions with Emerson
+ Climate Technologies.
This is for #570.
-
- - March 17, 2016, by Michael Wetter:
- Reformulated model to reduce the dimension of the nonlinear system
- of equations. This is for #435.
-
- - November 19, 2015, by Michael Wetter:
- Removed assignment of parameter
- showDesignFlowDirection in extends
- statement. This is for #349.
-
- - April 11, 2015, by Filip Jorissen:
- Propagated vol.massDynamics to top level parameter
- massDynamics instead of energyDynamics.
-
- - November 25, 2014, by Carles Ribas Tugores:
- Interchange position of fraRad parameter and the
- complementary (1-fraRad) in the equation used to
- calculate the nominal heating power of each element,
- QEle_flow_nominal[i].
-
- - October 29, 2014, by Michael Wetter:
- Made assignment of mFactor final, and changed
- computation of density to use default medium states as are also
- used to compute the specific heat capacity.
-
- - October 21, 2014, by Filip Jorissen:
- Added parameter mFactor and removed thermal capacity
- which can lead to an index reduction.
-
- - May 29, 2014, by Michael Wetter:
- Removed undesirable annotation Evaluate=true.
-
- - October 8, 2013 by Michael Wetter:
- Removed conditional statement in the declaration of the parameter
- mDry, as this is incorrect syntax.
-
- - September 26, 2013 by Michael Wetter:
- Reformulated implementation to avoid mixing textual and graphical
- declarations in the equation section.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/698\">#698.
- - April 4, 2011 by Michael Wetter:
- Changed the implementation to use AixLib.Utilities.Math.Functions.regNonZeroPower.
- This allows formulating the model without any non-differentiable
- function inside the equation section.
+ - January 2, 2017, by Filip Jorissen:
+ Removed option for choosing what temperature should be used to
+ compute the Carnot efficiency. This is for issue 497.
- - April 2, 2011 by Michael Wetter:
- Added homotopy operator.
-
- - February 11, 2011 by Michael Wetter:
- Revised the initialization to ensure that at the nominal
- conditions, the amount of transferred heat is excatly the same as
- the specified nominal power. In the previous implementation, the
- UA-value was computed using a simplified expression for the
- temperature difference, leading to a slightly different amount of
- heat transfer.
-
- - February 4, 2011 by Michael Wetter:
- Simplified implementation.
-
- - January 30, 2009 by Michael Wetter:
- First implementation.
+ - January 26, 2016, by Michael Wetter:
+ First implementation of this base class.
-------- Errors --------
-line 26 column 2 - Warning: attribute "align" not allowed for HTML5
+line 16 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 30 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 39 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/ThermalZones/ReducedOrder/RC/FourElements.mo ----
+---- AixLib/Fluid/Movers/Validation/PowerSimplified.mo ----
-------- HTML Code --------
+
+ This example compares the power consumed by pumps that
+ take three different control signals.
+ Each pump has identical mass flow rate and pressure rise.
+
+
+ Note that for the instances
+
+ AixLib.Fluid.Movers.FlowControlled_dp
+ and
+
+ AixLib.Fluid.Movers.FlowControlled_m_flow,
+ we had to assign the efficiencies (otherwise the default constant
+ efficiency of 0.7 would have been used).
+ In these models, the power consumption is computed
+ using similarity laws, but using the mass flow rate as opposed
+ to the speed, because speed is not known in these two models.
+ This is an approximation at operating points in which
+ the speed is different from the nominal speed N_nominal
+ because similarity laws are valid for speed and not for
+ mass flow rate.
+
+
+ The figure below shows the approximation error for the
+ power calculation where the speed Nrpm differs from
+ the nominal speed Nnominal.
+
+
+
+
+
-
- March 7, 2022, by Michael Wetter:
- Removed massDynamics.
- This is for
- #1542.
+ October 15, 2021, by Hongxiang Fu:
+ Fixed the image in the documentation which was cut off
+ at the y-axis. This is for
+ IBPSA, #1533.
-
- December 9, 2019, by Moritz Lauster:
- Changes nExt to nRoof for
- RRoof and CRoof
+ March 11, 2016, by Michael Wetter:
+ Revised implementation by assigning the data record directly in the
+ instances pump_dp and pump_m_flow, because
+ using a parameter and assigning this parameter leads
+ in OpenModelica to the error message
+ expected subtype of record AixLib.Fluid.Movers.Data.Generic.
-
- July 11, 2019, by Katharina Brinkmann:
- Renamed alphaRoof to hConRoof,
- alphaRoofConst to hConRoof_const
+ March 2, 2016, by Filip Jorissen:
+ Revised implementation for
+ #417.
-
- August 31, 2018 by Moritz Lauster:
- Updated schema in documentation and fixes
- orientation and connections of roofRC for
-
- issue 997.
+ November 5, 2015, by Michael Wetter:
+ Changed parameters since the power is no longer a parameter for the movers
+ that take mass flow rate or head as an input.
+ This is for
+ issue 457.
-
- September 11, 2015 by Moritz Lauster:
- First Implementation.
+ November 22, 2014, by Michael Wetter:
+ Revised implementation.
-
- This model adds another element for the roof. Roofs commonly
- exhibit the same excitations as exterior walls but have different coefficients
- of heat transfer due to their orientation. Adding an extra element for the roof
- might lead to a finer resolution of the dynamic behaviour but increases
- calculation times. The roof is parameterized via the length of the RC-chain
- nRoof,
- the vector of capacities CRoof[nRoof], the vector of resistances
- RRoof[nRoof] and remaining resistances RRoofRem.
-
-
- The image below shows the RC-network of this model.
-
-
- ![\"image\"/](\"modelica://AixLib/Resources/Images/ThermalZones/ReducedOrder/RC/FourElements.png\")
-
-
-------- Corrected Code --------
+
+ This example compares the power consumed by pumps that take three
+ different control signals. Each pump has identical mass flow rate and
+ pressure rise.
+
+
+ Note that for the instances AixLib.Fluid.Movers.FlowControlled_dp
+ and AixLib.Fluid.Movers.FlowControlled_m_flow,
+ we had to assign the efficiencies (otherwise the default constant
+ efficiency of 0.7 would have been used). In these models, the
+ power consumption is computed using similarity laws, but using the
+ mass flow rate as opposed to the speed, because speed is not known in
+ these two models. This is an approximation at operating points in
+ which the speed is different from the nominal speed
+ N_nominal because similarity laws are valid for speed
+ and not for mass flow rate.
+
+
+ The figure below shows the approximation error for the power
+ calculation where the speed Nrpm differs from the
+ nominal speed Nnominal.
+
+
+
+
- - March 7, 2022, by Michael Wetter:
- Removed massDynamics.
- This is for #1542.
+ - October 15, 2021, by Hongxiang Fu:
+ Fixed the image in the documentation which was cut off at the
+ y-axis. This is for IBPSA,
+ #1533.
- - December 9, 2019, by Moritz Lauster:
- Changes nExt to nRoof for
- RRoof and CRoof
+ - March 11, 2016, by Michael Wetter:
+ Revised implementation by assigning the data record directly in the
+ instances pump_dp and pump_m_flow,
+ because using a parameter and assigning this
+ parameter leads in OpenModelica to the error message
+ expected subtype of record
+ AixLib.Fluid.Movers.Data.Generic.
- - July 11, 2019, by Katharina Brinkmann:
- Renamed alphaRoof to hConRoof,
- alphaRoofConst to hConRoof_const
+ - March 2, 2016, by Filip Jorissen:
+ Revised implementation for #417.
- - August 31, 2018 by Moritz Lauster:
- Updated schema in documentation and fixes orientation and
- connections of roofRC for issue 997.
+ - November 5, 2015, by Michael Wetter:
+ Changed parameters since the power is no longer a parameter for the
+ movers that take mass flow rate or head as an input. This is for
+ issue
+ 457.
- - September 11, 2015 by Moritz Lauster:
- First Implementation.
+ - November 22, 2014, by Michael Wetter:
+ Revised implementation.
-
- This model adds another element for the roof. Roofs commonly exhibit
- the same excitations as exterior walls but have different
- coefficients of heat transfer due to their orientation. Adding an
- extra element for the roof might lead to a finer resolution of the
- dynamic behaviour but increases calculation times. The roof is
- parameterized via the length of the RC-chain nRoof, the
- vector of capacities CRoof[nRoof], the vector of
- resistances RRoof[nRoof] and remaining resistances
- RRoofRem.
-
-
- The image below shows the RC-network of this model.
-
-
-
-
-------- Errors --------
-line 15 column 4 - Warning: attribute "align" not allowed for HTML5
+line 29 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/Humidifiers/SteamHumidifier_X.mo ----
+---- AixLib/Fluid/Humidifiers/Humidifier_u.mo ----
-------- HTML Code --------
- Model for a steam humidifier with a prescribed outlet water vapor mass fraction
- in kg/kg total air.
-
-
- This model forces the outlet water mass fraction at port_b to be
- no lower than the
- input signal X_wSet, subject to optional limits on the
- maximum water vapor mass flow rate that is added, as
- described by the parameter mWatMax_flow.
- By default, the model has unlimited capacity.
-
-
- The output signal mWat_flow ≥ 0 is the moisture added
- to the medium if the flow rate is from port_a to port_b.
- If the flow is reversed, then mWat_flow = 0.
- The outlet specific enthalpy at port_b is increased by
- the enthalpy of steam at 100°C times the mass of steam that was added.
- Therefore, the temperature of the leaving fluid is slightly above the inlet temperature.
-
-
- The outlet conditions at port_a are not affected by this model,
- other than for a possible pressure difference due to flow friction.
+ Model for an air humidifier or dehumidifier.
- If the parameter energyDynamics is different from
- Modelica.Fluid.Types.Dynamics.SteadyState,
- the component models the dynamic response using a first order differential equation.
- The time constant of the component is equal to the parameter tau.
- This time constant is adjusted based on the mass flow rate using
+ This model adds (or removes) moisture from the air stream.
+ The amount of exchanged moisture is equal to
- τeff = τ |ṁ| ⁄ ṁnom
-
-
- where
- τeff is the effective time constant for the given mass flow rate
- ṁ and
- τ is the time constant at the nominal mass flow rate
- ṁnom.
- This type of dynamics is equal to the dynamics that a completely mixed
- control volume would have.
-
-
- Optionally, this model can have a flow resistance.
- Set dp_nominal = 0 to disable the flow friction calculation.
+ ṁwat = u ṁwat,nom,
- For a model that uses a control signal u ∈ [0, 1] and multiplies
- this with the nominal water mass flow rate, use
-
- AixLib.Fluid.Humidifiers.Humidifier_u
-
+ where u is the control input signal and
+ ṁwat,nom is equal to the parameter mWat_flow_nominal.
+ The parameter mWat_flow_nominal can be positive or negative.
+ If ṁwat is positive, then moisture is added
+ to the air stream, otherwise it is removed.
- Limitations
- This model only adds water vapor for the flow from
- port_a to port_b.
- The water vapor of the reverse flow is not affected by this model.
+ If the heat port heatPort is unconnected, then the enthalpy of the
+ air that flows through the device remains unchanged, e.g., the humidification
+ is adiabatic. To change the enthalpy of the air, add heat flow to the connector
+ heatPort.
-
- March 8, 2022, by Michael Wetter:
- Renamed parameter massDynamics to energyDynamics for consistency with other models.
-
+ March 7, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for
+ #1542.
+
-
- May 10, 2017, by Michael Wetter:
+ April 12, 2017, by Michael Wetter:
+ Removed parameters use_T_in and T.
+ This removes the optional specification of temperature through the parameter T
+ or the input connector T_in.
+ Exposed the heat port of the control volume to allow adding heat,
+ for example, to use the model as a steam humidifier.
+ This is for issue
+
+ Buildings #704.
+
+ -
+ May 6, 2015, by Michael Wetter:
+ Set prescribedHeatFlowRate=true.
+ This is for issue
+
+ #412.
+
+ -
+ May 29, 2014, by Michael Wetter:
+ Removed undesirable annotation Evaluate=true.
+
+ -
+ February 11, 2014 by Michael Wetter:
+ Corrected issue #197
+ which led to twice the amount of latent heat being added to the fluid stream.
+
+ -
+ October 14, 2013 by Michael Wetter:
+ Constrained medium to be a subclass of
+ Modelica.Media.Interfaces.PartialCondensingGases,
+ as this base class declares the function
+ enthalpyOfCondensingGas.
+
+ -
+ July 30, 2013 by Michael Wetter:
+ Updated model to use new variable mWat_flow
+ in the base class.
+
+ -
+ May 24, 2011, by Michael Wetter:
+ Changed base class to allow using the model as a dynamic or a steady-state model.
+
+ -
+ April 14, 2010, by Michael Wetter:
+ Converted temperature input to a conditional connector.
+
+ -
+ April 17, 2008, by Michael Wetter:
First implementation.
-------- Corrected Code --------
- Model for a steam humidifier with a prescribed outlet water vapor
- mass fraction in kg/kg total air.
+ Model for an air humidifier or dehumidifier.
- This model forces the outlet water mass fraction at
- port_b to be no lower than the input signal
- X_wSet, subject to optional limits on the maximum water
- vapor mass flow rate that is added, as described by the parameter
- mWatMax_flow. By default, the model has unlimited
- capacity.
+ This model adds (or removes) moisture from the air stream. The amount
+ of exchanged moisture is equal to
+
+
+ ṁwat = u ṁwat,nom,
- The output signal mWat_flow ≥ 0 is the moisture added to
- the medium if the flow rate is from port_a to
- port_b. If the flow is reversed, then mWat_flow =
- 0. The outlet specific enthalpy at port_b is
- increased by the enthalpy of steam at 100°C times the mass of
- steam that was added. Therefore, the temperature of the leaving fluid
- is slightly above the inlet temperature.
+ where u is the control input signal and
+ ṁwat,nom is equal to the parameter
+ mWat_flow_nominal. The parameter
+ mWat_flow_nominal can be positive or negative. If
+ ṁwat is positive, then moisture is added to the
+ air stream, otherwise it is removed.
+
+
+ If the heat port heatPort is unconnected, then the
+ enthalpy of the air that flows through the device remains unchanged,
+ e.g., the humidification is adiabatic. To change the enthalpy of the
+ air, add heat flow to the connector heatPort.
+
+
+ - March 7, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for #1542.
+
+ - April 12, 2017, by Michael Wetter:
+ Removed parameters use_T_in and T. This
+ removes the optional specification of temperature through the
+ parameter T or the input connector T_in.
+ Exposed the heat port of the control volume to allow adding heat,
+ for example, to use the model as a steam humidifier.
+ This is for issue Buildings
+ #704.
+
+ - May 6, 2015, by Michael Wetter:
+ Set prescribedHeatFlowRate=true. This is for issue
+ #412.
+
+ - May 29, 2014, by Michael Wetter:
+ Removed undesirable annotation Evaluate=true.
+
+ - February 11, 2014 by Michael Wetter:
+ Corrected issue #197
+ which led to twice the amount of latent heat being added to the
+ fluid stream.
+
+ - October 14, 2013 by Michael Wetter:
+ Constrained medium to be a subclass of
+ Modelica.Media.Interfaces.PartialCondensingGases, as
+ this base class declares the function
+ enthalpyOfCondensingGas.
+
+ - July 30, 2013 by Michael Wetter:
+ Updated model to use new variable mWat_flow in the
+ base class.
+
+ - May 24, 2011, by Michael Wetter:
+ Changed base class to allow using the model as a dynamic or a
+ steady-state model.
+
+ - April 14, 2010, by Michael Wetter:
+ Converted temperature input to a conditional connector.
+
+ - April 17, 2008, by Michael Wetter:
+ First implementation.
+
+
+
+-------- Errors --------
+line 9 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/HeatExchangers/Heater_T.mo ----
+-------- HTML Code --------
+
+
+ Model for an ideal heater that controls its outlet temperature to
+ a prescribed outlet temperature.
+
+
+ This model forces the outlet temperature at port_b to be
+ no lower than the temperature of the input signal
+ TSet, subject to optional limits on the
+ capacity.
+ By default, the model has unlimited heating capacity.
+
+
+ The output signal Q_flow is the heat added
+ to the medium if the mass flow rate is from port_a to port_b.
+ If the flow is reversed, then Q_flow=0.
+
+
+ The outlet conditions at port_a are not affected by this model,
+ other than for a possible pressure difference due to flow friction.
+
+
+ If the parameter energyDynamics is different from
+ Modelica.Fluid.Types.Dynamics.SteadyState,
+ the component models the dynamic response using a first order differential equation.
+ The time constant of the component is equal to the parameter tau.
+ This time constant is adjusted based on the mass flow rate using
+
+
+ τeff = τ |ṁ| ⁄ ṁnom
+
+
+ where
+ τeff is the effective time constant for the given mass flow rate
+ ṁ and
+ τ is the time constant at the nominal mass flow rate
+ ṁnom.
+ This type of dynamics is equal to the dynamics that a completely mixed
+ control volume would have.
+
+
+ Optionally, this model can have a flow resistance.
+ Set dp_nominal = 0 to disable the flow friction calculation.
+
+
+ For a similar model that is a sensible cooling device, use
+
+ AixLib.Fluid.HeatExchangers.SensibleCooler_T.
+ For a model that uses a control signal u ∈ [0, 1] and multiplies
+ this with the nominal heating or cooling power, use
+
+ AixLib.Fluid.HeatExchangers.HeaterCooler_u
+
+
+ Limitations
+
+ If the flow is from port_b to port_a,
+ then the enthalpy of the medium is not affected by this model.
+
+ Validation
+
+ The model has been validated against the analytical solution in
+ the examples
+
+ AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet
+ and
+
+ AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet_dynamic.
+
+
+
+ -
+ September 10, 2018, by Michael Wetter:
+ Corrected missing propagation of initial conditions.
+ This is for
+
+ AixLib, #1016.
+
+ -
+ May 3, 2017, by Michael Wetter:
+ First implementation.
+ This is for
+
+ AixLib, #763.
+
+
+
+-------- Corrected Code --------
+
+ Model for an ideal heater that controls its outlet temperature to a
+ prescribed outlet temperature.
+
+
+ This model forces the outlet temperature at port_b to be
+ no lower than the temperature of the input signal TSet,
+ subject to optional limits on the capacity. By default, the model has
+ unlimited heating capacity.
+
+
+ The output signal Q_flow is the heat added to the medium
+ if the mass flow rate is from port_a to
+ port_b. If the flow is reversed, then
+ Q_flow=0.
The outlet conditions at port_a are not affected by this
@@ -7770,130 +7343,51 @@ line 15 column 4 - Warning:
attribute "align" not allowed for HTML5
dp_nominal = 0 to disable the flow friction calculation.
+ For a similar model that is a sensible cooling device, use AixLib.Fluid.HeatExchangers.SensibleCooler_T.
For a model that uses a control signal u ∈ [0, 1] and
- multiplies this with the nominal water mass flow rate, use AixLib.Fluid.Humidifiers.Humidifier_u
+ multiplies this with the nominal heating or cooling power, use
+ AixLib.Fluid.HeatExchangers.HeaterCooler_u
Limitations
- This model only adds water vapor for the flow from
- port_a to port_b. The water vapor of the
- reverse flow is not affected by this model.
-
-
- - March 8, 2022, by Michael Wetter:
- Renamed parameter massDynamics to
- energyDynamics for consistency with other models.
-
- - May 10, 2017, by Michael Wetter:
- First implementation.
-
-
-
--------- Errors --------
-line 33 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/LoadAggregation/Validation/ShiftAggregationCells.mo ----
--------- HTML Code --------
-
-
- This validation case replicates the load-shifting procedure illustred in the figure below by Cimmino (2014).
-
-
-
-
- References
-
- Cimmino, M. 2014. Développement et validation expérimentale de facteurs de réponse
- thermique pour champs de puits géothermiques,
- Ph.D. Thesis, École Polytechnique de Montréal.
-
-
-
- -
- July 18, 2018, by Alex Laferrière:
- First implementation.
-
-
-
--------- Corrected Code --------
-
- This validation case replicates the load-shifting procedure illustred
- in the figure below by Cimmino (2014).
-
-
-
+ If the flow is from port_b to port_a, then
+ the enthalpy of the medium is not affected by this model.
- References
+ Validation
- Cimmino, M. 2014. Développement et validation expérimentale de
- facteurs de réponse thermique pour champs de puits géothermiques,
- Ph.D. Thesis, École Polytechnique de Montréal.
+ The model has been validated against the analytical solution in the
+ examples AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet
+ and
+ AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet_dynamic.
- - July 18, 2018, by Alex Laferrière:
- First implementation.
+ - September 10, 2018, by Michael Wetter:
+ Corrected missing propagation of initial conditions.
+ This is for AixLib,
+ #1016.
-
-
--------- Errors --------
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Utilities/Math/Bicubic.mo ----
--------- HTML Code --------
-
-
- This block computes
-
-
- y = a1
- + a2 x1 + a3 x12
- + a4 x2 + a5 x22
- + a6 x1 x2
- + a7 x1^3
- + a8 x2^3
- + a9 x12 x2
- + a10 x1 x22
-
-
-
- -
- Sep 17, 2010 by Michael Wetter:
- First implementation.
-
-
-
--------- Corrected Code --------
-
- This block computes
-
-
- y = a1 + a2 x1 + a3
- x12 + a4 x2 +
- a5 x22 + a6 x1
- x2 + a7 x1^3 + a8
- x2^3 + a9 x12
- x2 + a10 x1
- x22
-
-
- - Sep 17, 2010 by Michael Wetter:
- First implementation.
+ - May 3, 2017, by Michael Wetter:
+ First implementation.
+ This is for AixLib,
+ #763.
-------- Errors --------
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+line 29 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/BoundaryConditions/Validation/BESTEST/WD200.mo ----
+---- AixLib/BoundaryConditions/Validation/BESTEST/WD600.mo ----
-------- HTML Code --------
- WD200: Low Elevation, Hot and Humid Case.
- Weather data file : WD200.epw
- Table 1: Site Data for Weather file WD200.epw
-
+ WD600: Ground Reflactance
+ Weather data file : WD600.epw
+ Table 1: Site Data for Weather file WD600.epw
+
Latitude |
- 33.633° north |
+ 39.833° north |
Longitude |
- 84.433° west |
+ 104.65° west |
Altitude |
- 308 m |
+ 1650 m |
Time Zone |
- -5 |
+ -7 |
@@ -7955,21 +7445,17 @@ line 5 column 2 - Warning: attribute "align" not allowed for HTML5
Rework after comments from pull request #1339.
-
May 2, 2021, by Ettore Zanetti:
- Updated weather file as explained in #1478.
-
- WD200: Low Elevation, Hot and Humid Case.
+ WD600: Ground Reflactance
- Weather data file : WD200.epw
+ Weather data file : WD600.epw
- Table 1: Site Data for Weather file WD200.epw
+ Table 1: Site Data for Weather file WD600.epw
-
|
@@ -7979,7 +7465,7 @@ cellpadding=\"0\" border=\"1\">
|
- 33.633° north
+ 39.833° north
|
@@ -7991,7 +7477,7 @@ cellpadding=\"0\" border=\"1\">
- 84.433° west
+ 104.65° west
|
@@ -8003,7 +7489,7 @@ cellpadding=\"0\" border=\"1\">
- 308 m
+ 1650 m
|
@@ -8015,7 +7501,7 @@ cellpadding=\"0\" border=\"1\">
- -5
+ -7
|
@@ -8025,375 +7511,148 @@ cellpadding=\"0\" border=\"1\">
line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/BoundaryConditions/Validation/BESTEST/WD100.mo ----
+---- AixLib/Controls/Continuous/Examples/SignalRanker.mo ----
-------- HTML Code --------
- WD100: Base Case
- Weather data file : WD100.epw
- Table 1: Site Data for Weather file WD100.epw
-
- Latitude |
- 39.833° north |
-
-
- Longitude |
- 104.65° west |
-
-
- Altitude |
- 1650 m |
-
-
- Time Zone |
- -7 |
-
-
- This model is a template for all the other test cases.
- It allows to extrapolate all the weather data from the Reader TMY3 for a specific location, incliation and azimuth.
- The model
- AixLib.BoundaryConditions.Validation.IsotropicAndPerezDiffuseRadiation
- outputs radiation data using the available Isotropic and Perez methodlogies.
- The sky temperature is calculated using both the Horizontal radiation model,
- from data reader weaBusHorRad and the dew point temperature plus sky cover model from the datareader weaBusSkyCovDewTem.
+
+ Example that demonstrates the use of the signal ranker model.
+ The figure below shows the input and output signals of the block.
+ Note that
+ sigRan.y[1] ≥ sigRan.y[2] ≥ sigRan.y[3].
+
+
+ ![\"Input](\"modelica://AixLib/Resources/Images/Controls/Continuous/Examples/SignalRankerU.png\")
+ ![\"Output](\"modelica://AixLib/Resources/Images/Controls/Continuous/Examples/SignalRankerY.png\")
+
-
- September 6, 2021, by Ettore Zanetti:
- Removed parameter lat as it is now obtained from the weather data bus.
+ October 15, 2021, by Michael Wetter:
+ Moved start time of sine input signal to avoid simultaneous state event and time event.
This is for
- IBPSA, #1477.
-
- -
- March 11, 2020, by Ettore Zanetti:
- First implementation.
-
- -
- April 14, 2020, by Ettore Zanetti:
- Rework after comments from pull request
- #1339.
-
- -
- May 2, 2021, by Ettore Zanetti:
- Updated weather file as explained in #1478.
+ IBPSA, #1534.
-
- May 2, 2021, by Ettore Zanetti:
- Added altitude to parameters.
- This is for
- IBPSA, #1477.
+ November 21, 2011, by Michael Wetter:
+ Added documentation.
-------- Corrected Code --------
-
- WD100: Base Case
-
- Weather data file : WD100.epw
+ Example that demonstrates the use of the signal ranker model. The
+ figure below shows the input and output signals of the block. Note
+ that sigRan.y[1] ≥ sigRan.y[2] ≥ sigRan.y[3].
-
- Table 1: Site Data for Weather file WD100.epw
-
-
-
- |
-
- Latitude
-
- |
-
-
- 39.833° north
-
- |
-
-
- |
-
- Longitude
-
- |
-
-
- 104.65° west
-
- |
-
-
- |
-
- Altitude
-
- |
-
-
- 1650 m
-
- |
-
-
- |
-
- Time Zone
-
- |
-
-
- -7
-
- |
-
-
-
- This model is a template for all the other test cases. It allows to
- extrapolate all the weather data from the Reader TMY3 for a specific
- location, incliation and azimuth. The model
- AixLib.BoundaryConditions.Validation.IsotropicAndPerezDiffuseRadiation
- outputs radiation data using the available Isotropic and Perez
- methodlogies. The sky temperature is calculated using both the
- Horizontal radiation model, from data reader weaBusHorRad and the dew
- point temperature plus sky cover model from the datareader
- weaBusSkyCovDewTem.
+
+
+
- - September 6, 2021, by Ettore Zanetti:
- Removed parameter lat as it is now obtained from the
- weather data bus.
+ - October 15, 2021, by Michael Wetter:
+ Moved start time of sine input signal to avoid simultaneous state
+ event and time event.
This is for IBPSA,
- #1477.
-
- - March 11, 2020, by Ettore Zanetti:
- First implementation.
-
- - April 14, 2020, by Ettore Zanetti:
- Rework after comments from pull request #1339.
-
- - May 2, 2021, by Ettore Zanetti:
- Updated weather file as explained in #1478.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/1534\">IBPSA,
+ #1534.
- - May 2, 2021, by Ettore Zanetti:
- Added altitude to parameters.
- This is for IBPSA,
- #1477.
+ - November 21, 2011, by Michael Wetter:
+ Added documentation.
-------- Errors --------
-line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 8 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Sensors/SensibleEnthalpyFlowRate.mo ----
+---- AixLib/Fluid/HeatExchangers/DryCoilEffectivenessNTU.mo ----
-------- HTML Code --------
- This model outputs the sensible enthalphy flow rate of the medium in the flow
- between its fluid ports. In particular, if the total enthalpy flow rate is
+ Model of a coil without humidity condensation.
+ This model transfers heat in the amount of
- Ḣtot = Ḣsen + Ḣlat,
+ Q̇ = Q̇max ε
+ ε = f(NTU, Z, flowRegime),
where
- Ḣsen = ṁ (1-Xw) cp,air,
- then this sensor outputs Ḣ = Ḣsen.
+ Q̇max is the maximum heat that can be transferred,
+ ε is the heat transfer effectiveness,
+ NTU is the Number of Transfer Units,
+ Z is the ratio of minimum to maximum capacity flow rate and
+ flowRegime is the heat exchanger flow regime.
+ such as
+ parallel flow, cross flow or counter flow.
-
- If the parameter tau is non-zero, then the measured
- specific sensible enthalpy hout that is used to
- compute the sensible enthalpy flow rate
- Ḣsen = ṁ hout
- is computed using a first order differential equation.
- See
- AixLib.Fluid.Sensors.UsersGuide for an explanation.
+ The flow regimes depend on the heat exchanger configuration. All configurations
+ defined in
+
+ AixLib.Fluid.Types.HeatExchangerConfiguration
+ are supported.
-
- For a sensor that measures
- Ḣtot, use
-
- AixLib.Fluid.Sensors.EnthalpyFlowRate.
- For a sensor that measures
- Ḣlat, use
-
- AixLib.Fluid.Sensors.LatentEnthalpyFlowRate.
+ The convective heat transfer coefficients scale proportional to
+ (ṁ/ṁ0)n, where
+ ṁ is the mass flow rate,
+ ṁ0 is the nominal mass flow rate, and
+ n=0.8 on the air-side and n=0.85 on the water side.
-
- The sensor is ideal, i.e., it does not influence the fluid.
- The sensor can only be used with medium models that implement the function
- enthalpyOfNonCondensingGas(T).
-
+ For a heat and moisture exchanger, use
+
+ AixLib.Fluid.MassExchangers.ConstantEffectiveness.
+
-
- October 19, 2020, by Antoine Gautier:
- Changed default value for tau from 1 to 0.
- This is for
- #1406.
-
- -
- February 25, 2020, by Michael Wetter:
- Changed icon to display its operating state.
- This is for
- #1294.
-
- -
- January 18, 2016 by Filip Jorissen:
- Using parameter tauInv
- since this now exists in
- AixLib.Fluid.Sensors.BaseClasses.PartialDynamicFlowSensor.
- This is for
- #372.
-
- -
- September 10, 2013, by Michael Wetter:
- Changed medium declaration in the extends statement
- to replaceable to avoid a translation error in
- OpenModelica.
-
- -
- August 31, 2013, by Michael Wetter:
- Removed default value tau=0 as the base class
- already sets tau=1.
- This change was made so that all sensors use the same default value.
-
- -
- December 18, 2012, by Michael Wetter:
- Moved computation of i_w to new base class
-
- AixLib.Fluid.BaseClasses.IndexWater.
- The value of this parameter is now assigned dynamically and does not require to be specified
- by the user.
-
- -
- November 3, 2011, by Michael Wetter:
- Moved der(h_out) := 0; from the initial algorithm section to
- the initial equation section
- as this assignment does not conform to the Modelica specification.
-
- -
- August 10, 2011 by Michael Wetter:
- Added parameter i_w and an assert statement to
- make sure it is set correctly. Without this change, Dymola
- cannot differentiate the model when reducing the index of the DAE.
-
- -
- June 3, 2011 by Michael Wetter:
- Revised implementation to add dynamics in such a way that
- the time constant increases as the mass flow rate tends to zero.
- This can improve the numerics.
-
- -
- February 22, by Michael Wetter:
- Improved code that searches for index of 'water' in the medium model.
-
- -
- September 9, 2009 by Michael Wetter:
- First implementation.
- Implementation is based on enthalpy sensor of Modelica.Fluid.
+ September 25, 2018, by Michael Wetter:
+ Refactored model to use a common base class.
-------- Corrected Code --------
- This model outputs the sensible enthalphy flow rate of the
- medium in the flow between its fluid ports. In particular, if the
- total enthalpy flow rate is
+ Model of a coil without humidity condensation. This model transfers
+ heat in the amount of
- Ḣtot = Ḣsen + Ḣlat,
+ Q̇ = Q̇max ε
+ ε = f(NTU, Z, flowRegime),
- where Ḣsen = ṁ (1-Xw)
- cp,air, then this sensor outputs Ḣ =
- Ḣsen.
+ where Q̇max is the maximum heat that can be
+ transferred, ε is the heat transfer effectiveness, NTU
+ is the Number of Transfer Units, Z is the ratio of minimum to
+ maximum capacity flow rate and flowRegime is the heat
+ exchanger flow regime. such as parallel flow, cross flow or counter
+ flow.
- If the parameter tau is non-zero, then the measured
- specific sensible enthalpy hout that is used to
- compute the sensible enthalpy flow rate Ḣsen = ṁ
- hout is computed using a first order differential
- equation. See AixLib.Fluid.Sensors.UsersGuide
- for an explanation.
+ The flow regimes depend on the heat exchanger configuration. All
+ configurations defined in AixLib.Fluid.Types.HeatExchangerConfiguration
+ are supported.
- For a sensor that measures Ḣtot, use AixLib.Fluid.Sensors.EnthalpyFlowRate.
-
- For a sensor that measures Ḣlat, use AixLib.Fluid.Sensors.LatentEnthalpyFlowRate.
+ The convective heat transfer coefficients scale proportional to
+ (ṁ/ṁ0)n, where ṁ is the mass
+ flow rate, ṁ0 is the nominal mass flow rate, and
+ n=0.8 on the air-side and n=0.85 on the water side.
- The sensor is ideal, i.e., it does not influence the fluid. The
- sensor can only be used with medium models that implement the
- function enthalpyOfNonCondensingGas(T).
+ For a heat and moisture exchanger, use AixLib.Fluid.MassExchangers.ConstantEffectiveness.
- - October 19, 2020, by Antoine Gautier:
- Changed default value for tau from 1 to
- 0.
- This is for #1406.
-
- - February 25, 2020, by Michael Wetter:
- Changed icon to display its operating state.
- This is for #1294.
-
- - January 18, 2016 by Filip Jorissen:
- Using parameter tauInv since this now exists in
-
- AixLib.Fluid.Sensors.BaseClasses.PartialDynamicFlowSensor. This
- is for #372.
-
- - September 10, 2013, by Michael Wetter:
- Changed medium declaration in the extends statement to
- replaceable to avoid a translation error in
- OpenModelica.
-
- - August 31, 2013, by Michael Wetter:
- Removed default value tau=0 as the base class already
- sets tau=1. This change was made so that all sensors
- use the same default value.
-
- - December 18, 2012, by Michael Wetter:
- Moved computation of i_w to new base class AixLib.Fluid.BaseClasses.IndexWater.
- The value of this parameter is now assigned dynamically and does
- not require to be specified by the user.
-
- - November 3, 2011, by Michael Wetter:
- Moved der(h_out) := 0; from the initial algorithm
- section to the initial equation section as this assignment does not
- conform to the Modelica specification.
-
- - August 10, 2011 by Michael Wetter:
- Added parameter i_w and an assert statement to make
- sure it is set correctly. Without this change, Dymola cannot
- differentiate the model when reducing the index of the DAE.
-
- - June 3, 2011 by Michael Wetter:
- Revised implementation to add dynamics in such a way that the time
- constant increases as the mass flow rate tends to zero. This can
- improve the numerics.
-
- - February 22, by Michael Wetter:
- Improved code that searches for index of 'water' in the medium
- model.
-
- - September 9, 2009 by Michael Wetter:
- First implementation. Implementation is based on enthalpy sensor of
- Modelica.Fluid.
+ - September 25, 2018, by Michael Wetter:
+ Refactored model to use a common base class.
@@ -8401,825 +7660,801 @@ line 5 column 2 - Warning: The summary attribute on the element is obsol
line 6 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/Cylindrical.mo ----
+---- AixLib/Fluid/Actuators/Valves/ThreeWayTable.mo ----
-------- HTML Code --------
- Model for radial heat transfer in a hollow cylinder.
+ Three way valve with table-specified opening characteristics.
+ A separate characteristic for each flow path is used.
- If the heat capacity of the material is non-zero, then this model computes transient heat conduction, i.e., it
- computes a numerical approximation to the solution of the heat equation
-
-
- ρ c ( ∂ T(r,t) ⁄ ∂t ) =
- k ( ∂² T(r,t) ⁄ ∂r² + 1 ⁄ r ∂ T(r,t) ⁄ ∂r ),
+ Each flow path uses an instance of the model
+
+ AixLib.Fluid.Actuators.Valves.TwoWayTable.
+ Therefore, this model needs to be parameterized the same way as
+
+ AixLib.Fluid.Actuators.Valves.TwoWayTable.
+ Specifically,
+ the mass flow rate for the fully open valve is determined based
+ on the value of the parameter CvData.
+ For the different valve positions y ∈ [0, 1], this nominal flow rate is
+ scaled by the values of the parameter
+ flowCharacteristics1 and flowCharacteristics3, respectively.
+ These parameters declare a table of the form
+
+
+ | y | 0 | ... | 1 |
+
+
+ | φ | l | ... | 1 |
+
+
- where
- ρ
- is the mass density,
- c
- is the specific heat capacity per unit mass,
- T
- is the temperature at location r and time t and
- k is the heat conductivity.
- At the locations r=ra and r=rb,
- the temperature and heat flow rate are equal to the
- temperature and heat flow rate of the heat ports.
+ where l = Kv(y=0)/Kv(y=1) > 0 is the valve leakage.
+ The first row is the valve opening, and the second row is the
+ mass flow rate, relative to the mass flow rate of the fully open
+ valve, under the assumption of a constant pressure difference across the
+ valve.
+ A suggested value for the valve leakage is l=0.0001.
+ If l = 0, then this model will replace it with
+ l = 10-8 for numerical reasons.
+ For example, if a valve has Kv=0.5 [m3/h/bar1/2] and
+ a linear opening characteristics and
+ a valve leakage of l=0.0001, then one would set
+
+ CvData=AixLib.Fluid.Types.CvTypes.Kv
+ Kv = 0.5
+ flowCharacteristics1(y={0,1}, phi={0.0001,1})
+ flowCharacteristics3(y={0,1}, phi={0.0001,1})
+
- If the heat capacity of the material is set to zero, then steady-state heat flow is computed using
+ Note, however, that
+
+ AixLib.Fluid.Actuators.Valves.ThreeWayLinear provides a more
+ efficient implementation for this simple case.
-
- Q = 2 π k (Ta-Tb)⁄ ln(ra ⁄ rb),
+
+ The parameters flowCharacteristics1 and flowCharacteristics3 must meet the following
+ requirements, otherwise the model stops with an error:
+
+ -
+ Their arrays
+
y and phi
+ must be strictly monotonic increasing.
+
+ -
+ The first value must satisfy
+
y[1]=0, and
+ phi[1] must be equal to the
+ leakage flow rate, which must be bigger than zero.
+ Otherwise, a default value of 1E-8 is used.
+
+ -
+ The last values must satisfy
+
y[end]=1 and
+ phi[end]=1.
+
+
- where
- ra is the internal radius,
- rb is the external radius,
- Ta is the temperature at port a and
- Tb is the temperature at port b.
+ This model is based on the partial valve model
+
+ AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve.
+ Check this model for more information, such
+ as the regularization near the origin.
- Implementation
- To spatially discretize the heat equation, the construction is
- divided into compartments with nSta ≥ 1 state variables.
- The state variables are connected to each other through thermal conductors.
- There is also a thermal conductor
- between the surfaces and the outermost state variables. Thus, to obtain
- the surface temperature, use port_a.T (or port_b.T)
- and not the variable T[1].
+ For an example that specifies an opening characteristics, see
+
+ AixLib.Fluid.Actuators.Valves.Examples.TwoWayValveTable.
+
-
- January, 2014, by Damien Picard:
- Modify the discretization of the cilindrical layer so that the first three layers have an equal thickness the following an exponentionally growing thickness.
- This follows the guidelines of Eskilson (P. Eskilson. Thermal analysis of heat extraction
- boreholes. PhD thesis, Dep. of Mathematical
- Physics, University of Lund, Sweden, 1987).
+ March 7, 2022, by Michael Wetter:
+ Set final massDynamics=energyDynamics.
+ This is for
+ #1542.
-
- March 9, 2012, by Michael Wetter:
- Removed protected variable der_T as it is not required.
+ June 10, 2021, by Michael Wetter:
+ Changed implementation of the filter and changed the parameter order to a constant
+ as most users need not change this value.
+ This is for
+ #1498.
-
- April 14 2011, by Pierre Vigouroux:
+ November 28, 2019, by Michael Wetter:
+ Revised implementation.
+
+ -
+ November 15, 2019, by Alexander Kümpel:
First implementation.
-------- Corrected Code --------
- Model for radial heat transfer in a hollow cylinder.
+ Three way valve with table-specified opening characteristics. A
+ separate characteristic for each flow path is used.
- If the heat capacity of the material is non-zero, then this model
- computes transient heat conduction, i.e., it computes a numerical
- approximation to the solution of the heat equation
-
-
- ρ c ( ∂ T(r,t) ⁄ ∂t ) = k ( ∂² T(r,t) ⁄ ∂r² + 1 ⁄ r ∂ T(r,t) ⁄
- ∂r ),
+ Each flow path uses an instance of the model AixLib.Fluid.Actuators.Valves.TwoWayTable.
+ Therefore, this model needs to be parameterized the same way as
+ AixLib.Fluid.Actuators.Valves.TwoWayTable.
+ Specifically, the mass flow rate for the fully open valve is
+ determined based on the value of the parameter CvData.
+ For the different valve positions y ∈ [0, 1], this nominal
+ flow rate is scaled by the values of the parameter
+ flowCharacteristics1 and
+ flowCharacteristics3, respectively. These parameters
+ declare a table of the form
+
+
+ |
+ y
+ |
+
+ 0
+ |
+
+ ...
+ |
+
+ 1
+ |
+
+
+ |
+ φ
+ |
+
+ l
+ |
+
+ ...
+ |
+
+ 1
+ |
+
+
- where ρ is the mass density, c is the specific heat
- capacity per unit mass, T is the temperature at location
- r and time t and k is the heat conductivity. At
- the locations r=ra and r=rb, the
- temperature and heat flow rate are equal to the temperature and heat
- flow rate of the heat ports.
+ where l = Kv(y=0)/Kv(y=1) > 0 is the
+ valve leakage. The first row is the valve opening, and the second row
+ is the mass flow rate, relative to the mass flow rate of the fully
+ open valve, under the assumption of a constant pressure difference
+ across the valve. A suggested value for the valve leakage is
+ l=0.0001. If l = 0, then this model will replace it
+ with l = 10-8 for numerical reasons. For example,
+ if a valve has Kv=0.5
+ [m3/h/bar1/2] and a linear opening
+ characteristics and a valve leakage of l=0.0001, then one
+ would set
+
+ CvData=AixLib.Fluid.Types.CvTypes.Kv
+ Kv = 0.5
+ flowCharacteristics1(y={0,1}, phi={0.0001,1})
+ flowCharacteristics3(y={0,1}, phi={0.0001,1})
+
- If the heat capacity of the material is set to zero, then
- steady-state heat flow is computed using
+ Note, however, that AixLib.Fluid.Actuators.Valves.ThreeWayLinear
+ provides a more efficient implementation for this simple case.
-
- Q = 2 π k (Ta-Tb)⁄ ln(ra ⁄
- rb),
+
+ The parameters flowCharacteristics1 and
+ flowCharacteristics3 must meet the following
+ requirements, otherwise the model stops with an error:
+
+ - Their arrays
y and phi must be strictly
+ monotonic increasing.
+
+ - The first value must satisfy
y[1]=0, and
+ phi[1] must be equal to the leakage flow rate, which
+ must be bigger than zero. Otherwise, a default value of
+ 1E-8 is used.
+
+ - The last values must satisfy
y[end]=1 and
+ phi[end]=1.
+
+
- where ra is the internal radius,
- rb is the external radius, Ta is
- the temperature at port a and Tb is the temperature
- at port b.
+ This model is based on the partial valve model AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve.
+ Check this model for more information, such as the regularization
+ near the origin.
-
- Implementation
-
- To spatially discretize the heat equation, the construction is
- divided into compartments with nSta ≥ 1 state variables.
- The state variables are connected to each other through thermal
- conductors. There is also a thermal conductor between the surfaces
- and the outermost state variables. Thus, to obtain the surface
- temperature, use port_a.T (or port_b.T) and
- not the variable T[1].
+ For an example that specifies an opening characteristics, see
+
+ AixLib.Fluid.Actuators.Valves.Examples.TwoWayValveTable.
- - January, 2014, by Damien Picard:
- Modify the discretization of the cilindrical layer so that the
- first three layers have an equal thickness the following an
- exponentionally growing thickness. This follows the guidelines of
- Eskilson (P. Eskilson. Thermal analysis of heat extraction
- boreholes. PhD thesis, Dep. of Mathematical Physics, University of
- Lund, Sweden, 1987).
+ - March 7, 2022, by Michael Wetter:
+ Set final massDynamics=energyDynamics.
+ This is for #1542.
- - March 9, 2012, by Michael Wetter:
- Removed protected variable der_T as it is not
- required.
+ - June 10, 2021, by Michael Wetter:
+ Changed implementation of the filter and changed the parameter
+ order to a constant as most users need not change this
+ value.
+ This is for #1498.
- - April 14 2011, by Pierre Vigouroux:
+ - November 28, 2019, by Michael Wetter:
+ Revised implementation.
+
+ - November 15, 2019, by Alexander Kümpel:
First implementation.
-------- Errors --------
-line 9 column 2 - Warning: attribute "align" not allowed for HTML5
-line 29 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 21 column 2 - Warning: The summary attribute on the
element is obsolete in HTML5
----- AixLib/Fluid/Movers/BaseClasses/Characteristics/power.mo ----
+---- AixLib/Controls/Continuous/LimPID.mo ----
-------- HTML Code --------
- This function computes the fan power consumption for given volume flow rate,
- speed and performance data. The power consumption is
+ PID controller in the standard form
- P = rN3 s(V̇/rN, d),
+ y = k ( e(t) + 1 ⁄ Ti ∫ e(s) ds + Td de(t)⁄dt ),
where
- P is the power consumption,
- rN is the normalized fan speed,
- V̇ is the volume flow rate and
- d are performance data for fan or pump power consumption at rN=1.
+ y is the control signal,
+ e(t) = us - um is the control error,
+ with us being the set point and um being
+ the measured quantity,
+ k is the gain,
+ Ti is the time constant of the integral term and
+ Td is the time constant of the derivative term.
- Implementation
- The function s(·, ·) is a cubic hermite spline.
- If the data d define a monotone decreasing sequence, then
- s(·, d) is a monotone decreasing function.
+ Note that the units of k are the inverse of the units of the control error,
+ while the units of Ti and Td are seconds.
+
+
+ For detailed treatment of integrator anti-windup, set-point weights and output limitation, see
+ Modelica.Blocks.Continuous.LimPID.
+
+ Options
+ This controller can be configured as follows.
+ P, PI, PD, or PID action
+
+ Through the parameter controllerType, the controller can be configured
+ as P, PI, PD or PID controller. The default configuration is PI.
+
+ Direct or reverse acting
+
+ Through the parameter reverseActing, the controller can be configured to
+ be reverse or direct acting.
+ The above standard form is reverse acting, which is the default configuration.
+ For a reverse acting controller, for a constant set point,
+ an increase in measurement signal u_m decreases the control output signal y
+ (Montgomery and McDowall, 2008).
+ Thus,
+
+
+ -
+ for a heating coil with a two-way valve, leave
reverseActing = true, but
+
+ -
+ for a cooling coil with a two-way valve, set
reverseActing = false.
+
+
+ Reset of the controller output
+
+ The controller can be configured to enable an input port that allows resetting the controller
+ output. The controller output can be reset as follows:
+
+
+ -
+ If
reset = AixLib.Types.Reset.Disabled, which is the default,
+ then the controller output is never reset.
+
+ -
+ If
reset = AixLib.Types.Reset.Parameter, then a boolean
+ input signal trigger is enabled. Whenever the value of
+ this input changes from false to true,
+ the controller output is reset by setting y
+ to the value of the parameter y_reset.
+
+ -
+ If
reset = AixLib.Types.Reset.Input, then a boolean
+ input signal trigger and a real input signal y_reset_in
+ are enabled. Whenever the value of
+ trigger changes from false to true,
+ the controller output is reset by setting the value of y
+ to y_reset_in.
+
+
+
+ Note that this controller implements an integrator anti-windup. Therefore,
+ for most applications, keeping the default setting of
+ reset = AixLib.Types.Reset.Disabled is sufficient.
+ However, if the controller is used in conjuction with equipment that is being
+ switched on, better control performance may be achieved by resetting the controller
+ output when the equipment is switched on.
+ This is in particular the case in situations
+ where the equipment control input should continuously increase as the equipment is
+ switched on, such as a light dimmer that may slowly increase the luminance, or
+ a variable speed drive of a motor that should continuously increase the speed.
+
+ References
+
+ R. Montgomery and R. McDowall (2008).
+ \"Fundamentals of HVAC Control Systems.\"
+ American Society of Heating Refrigerating and Air-Conditioning Engineers Inc. Atlanta, GA.
+
-
- February 26, 2014, by Filip Jorissen:
- Changed polynomial to be evaluated at V_flow/r_N
- instead of V_flow to properly account for the
- scaling law. See
- #202
- for a discussion and validation.
+ June 1, 2020, by Michael Wetter:
+ Corrected wrong convention of reverse and direct action.
+ Changed default configuration from PID to PI.
+ This is for issue 1365.
-
- September 28, 2011, by Michael Wetter:
+ March 9, 2020, by Michael Wetter:
+ Corrected wrong unit declaration for parameter k.
+ This is for issue 1316.
+
+ -
+ October 19, 2019, by Filip Jorissen:
+ Disabled homotopy to ensure bounded outputs
+ by copying the implementation from MSL 3.2.3 and by
+ hardcoding the implementation for homotopyType=NoHomotopy.
+ See issue 1221.
+
+ -
+ September 29, 2016, by Michael Wetter:
+ Refactored model.
+
+ -
+ August 25, 2016, by Michael Wetter:
+ Removed parameter limitsAtInit because it was only propagated to
+ the instance limiter, but this block no longer makes use of this parameter.
+ This is a non-backward compatible change.
+ Revised implemenentation, added comments, made some parameter in the instances final.
+
+ - July 18, 2016, by Philipp Mehrfeld:
+ Added integrator reset.
+ This is for issue 494.
+
+ -
+ March 15, 2016, by Michael Wetter:
+ Changed the default value to strict=true in order to avoid events
+ when the controller saturates.
+ This is for issue 433.
+
+ -
+ February 24, 2010, by Michael Wetter:
First implementation.
-------- Corrected Code --------
- This function computes the fan power consumption for given volume
- flow rate, speed and performance data. The power consumption is
+ PID controller in the standard form
- P = rN3 s(V̇/rN, d),
+ y = k ( e(t) + 1 ⁄ Ti ∫ e(s) ds +
+ Td de(t)⁄dt ),
- where P is the power consumption, rN is the
- normalized fan speed, V̇ is the volume flow rate and d
- are performance data for fan or pump power consumption at
- rN=1.
+ where y is the control signal, e(t) = us -
+ um is the control error, with us
+ being the set point and um being the measured
+ quantity, k is the gain, Ti is the time
+ constant of the integral term and Td is the time
+ constant of the derivative term.
+
+
+ Note that the units of k are the inverse of the units of the
+ control error, while the units of Ti and
+ Td are seconds.
+
+
+ For detailed treatment of integrator anti-windup, set-point weights
+ and output limitation, see Modelica.Blocks.Continuous.LimPID.
- Implementation
-
+ Options
+This controller can be configured as follows.
+
+ P, PI, PD, or PID action
+
- The function s(·, ·) is a cubic hermite spline. If the data
- d define a monotone decreasing sequence, then s(·, d)
- is a monotone decreasing function.
+ Through the parameter controllerType, the controller can
+ be configured as P, PI, PD or PID controller. The default
+ configuration is PI.
+
+
+ Direct or reverse acting
+
+
+ Through the parameter reverseActing, the controller can
+ be configured to be reverse or direct acting. The above standard form
+ is reverse acting, which is the default configuration. For a reverse
+ acting controller, for a constant set point, an increase in
+ measurement signal u_m decreases the control output
+ signal y (Montgomery and McDowall, 2008). Thus,
- - February 26, 2014, by Filip Jorissen:
- Changed polynomial to be evaluated at V_flow/r_N
- instead of V_flow to properly account for the scaling
- law. See #202
- for a discussion and validation.
+ - for a heating coil with a two-way valve, leave
+
reverseActing = true, but
- - September 28, 2011, by Michael Wetter:
- First implementation.
+ - for a cooling coil with a two-way valve, set
reverseActing
+ = false.
-
--------- Errors --------
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/finiteLineSource.mo ----
--------- HTML Code --------
-
-
- This function evaluates the finite line source solution. This solution
- gives the relation between the constant heat transfer rate (per unit length)
- injected by a line source of finite length H1 buried at a
- distance D1 from a constant temperature surface
- (T=0) and the average temperature raise over a line of finite length
- H2 buried at a distance D2 from the constant
- temperature surface.
- The finite line source solution is defined by:
-
-
- ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/FiniteLineSource_01.png\")
-
-
- where ΔT1-2(t,r,H1,D1,H2,D2)
- is the temperature raise after a time t of constant heat injection and at
- a distance r from the line heat source, Q' is the heat injection
- rate per unit length, ks is the soil thermal conductivity and
- hFLS is the finite line source solution.
-
-
- The finite line source solution is given by:
-
-
- ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/FiniteLineSource_02.png\")
-
-
- where αs is the ground thermal diffusivity and
- erfint is the integral of the error function, defined in
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.finiteLineSource_erfint.
- The integral is solved numerically, with the integrand defined in
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.finiteLineSource_Integrand.
-
-
-
- -
- March 17, 2019, by Massimo Cimmino:
- Modified the upper bound of integration to avoid underestimating the value of
- the integral.
- This is for
- IBPSA, issue 1107.
-
- -
- March 22, 2018 by Massimo Cimmino:
- First implementation.
-
-
-
--------- Corrected Code --------
-
- This function evaluates the finite line source solution. This
- solution gives the relation between the constant heat transfer rate
- (per unit length) injected by a line source of finite length
- H1 buried at a distance D1 from a
- constant temperature surface (T=0) and the average temperature
- raise over a line of finite length H2 buried at a
- distance D2 from the constant temperature surface.
- The finite line source solution is defined by:
-
-
-
-
+
+ Reset of the controller output
+
- where
- ΔT1-2(t,r,H1,D1,H2,D2)
- is the temperature raise after a time t of constant heat
- injection and at a distance r from the line heat source,
- Q' is the heat injection rate per unit length,
- ks is the soil thermal conductivity and
- hFLS is the finite line source solution.
+ The controller can be configured to enable an input port that allows
+ resetting the controller output. The controller output can be reset
+ as follows:
+
+ - If
reset = AixLib.Types.Reset.Disabled, which is the
+ default, then the controller output is never reset.
+
+ - If
reset = AixLib.Types.Reset.Parameter, then a
+ boolean input signal trigger is enabled. Whenever the
+ value of this input changes from false to
+ true, the controller output is reset by setting
+ y to the value of the parameter y_reset.
+
+ - If
reset = AixLib.Types.Reset.Input, then a boolean
+ input signal trigger and a real input signal
+ y_reset_in are enabled. Whenever the value of
+ trigger changes from false to
+ true, the controller output is reset by setting the
+ value of y to y_reset_in.
+
+
- The finite line source solution is given by:
-
-
-
+ Note that this controller implements an integrator anti-windup.
+ Therefore, for most applications, keeping the default setting of
+ reset = AixLib.Types.Reset.Disabled is sufficient.
+ However, if the controller is used in conjuction with equipment that
+ is being switched on, better control performance may be achieved by
+ resetting the controller output when the equipment is switched on.
+ This is in particular the case in situations where the equipment
+ control input should continuously increase as the equipment is
+ switched on, such as a light dimmer that may slowly increase the
+ luminance, or a variable speed drive of a motor that should
+ continuously increase the speed.
+
+ References
+
- where αs is the ground thermal diffusivity and
- erfint is the integral of the error function, defined in
-
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.finiteLineSource_erfint.
- The integral is solved numerically, with the integrand defined in
-
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.finiteLineSource_Integrand.
+ R. Montgomery and R. McDowall (2008). \"Fundamentals of HVAC Control
+ Systems.\" American Society of Heating Refrigerating and
+ Air-Conditioning Engineers Inc. Atlanta, GA.
- - March 17, 2019, by Massimo Cimmino:
- Modified the upper bound of integration to avoid underestimating
- the value of the integral. This is for IBPSA, issue
- 1107.
+ - June 1, 2020, by Michael Wetter:
+ Corrected wrong convention of reverse and direct action.
+ Changed default configuration from PID to PI.
+ This is for issue
+ 1365.
- - March 22, 2018 by Massimo Cimmino:
+ - March 9, 2020, by Michael Wetter:
+ Corrected wrong unit declaration for parameter k.
+ This is for issue
+ 1316.
+
+ - October 19, 2019, by Filip Jorissen:
+ Disabled homotopy to ensure bounded outputs by copying the
+ implementation from MSL 3.2.3 and by hardcoding the implementation
+ for homotopyType=NoHomotopy. See issue
+ 1221.
+
+ - September 29, 2016, by Michael Wetter:
+ Refactored model.
+
+ - August 25, 2016, by Michael Wetter:
+ Removed parameter limitsAtInit because it was only
+ propagated to the instance limiter, but this block no
+ longer makes use of this parameter. This is a non-backward
+ compatible change.
+ Revised implemenentation, added comments, made some parameter in
+ the instances final.
+
+ - July 18, 2016, by Philipp Mehrfeld:
+ Added integrator reset. This is for issue 494.
+
+ - March 15, 2016, by Michael Wetter:
+ Changed the default value to strict=true in order to
+ avoid events when the controller saturates. This is for issue 433.
+
+ - February 24, 2010, by Michael Wetter:
First implementation.
-------- Errors --------
-line 12 column 2 - Warning: attribute "align" not allowed for HTML5
-line 25 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 5 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatPumps/Carnot_y.mo ----
+---- AixLib/ThermalZones/ReducedOrder/RC/BaseClasses/splitFacVal.mo ----
-------- HTML Code --------
-
- This is model of a heat pump whose coefficient of performance COP changes
- with temperatures in the same way as the Carnot efficiency changes.
- The input signal y is the control signal for the compressor.
-
-
- The model allows to either specify the Carnot effectivness
- ηCarnot,0, or
- a COP0
- at the nominal conditions, together with
- the evaporator temperature Teva,0 and
- the condenser temperature Tcon,0, in which
- case the model computes the Carnot effectivness as
-
-
- ηCarnot,0 =
- COP0
- ⁄ (Tcon,0 ⁄ (Tcon,0-Teva,0)).
-
-
- The heat pump COP is computed as the product
-
-
- COP = ηCarnot,0 COPCarnot ηPL,
-
-
- where COPCarnot is the Carnot efficiency and
- ηPL is a polynomial in the heating part load ratio yPL
- that can be used to take into account a change in COP at part load
- conditions.
- This polynomial has the form
-
-
- ηPL = a1 + a2 yPL + a3 yPL2 + ...
-
-
- where the coefficients ai are declared by the parameter a.
-
-
- On the Dynamics tag, the model can be parametrized to compute a transient
- or steady-state response.
- The transient response of the model is computed using a first
- order differential equation for the evaporator and condenser fluid volumes.
- The heat pump outlet temperatures are equal to the temperatures of these lumped volumes.
-
- Typical use and important parameters
-
- When using this component, make sure that the evaporator and the condenser have sufficient mass flow rate.
- Based on the mass flow rates, the compressor power, temperature difference and the efficiencies,
- the model computes how much heat will be added to the condenser and removed at the evaporator.
- If the mass flow rates are too small, very high temperature differences can result.
+
Calculates the ratio of the surface areas of a wall to the total wall area,
+ unless the area is zero. It subtracts the wall area AExt
+ for first entry in AArray and AWin for
+ second entry in AArray unless AArray[1] and/or
+ AArray[2] are not zero. This is done separately for each
+ orientation. Consequently, the function gives an nRow x nCol
+ array back as output. Each row stands for one area in
+ AArray and each column for one orientation in
+ AExt and AWin. The function is used to
+ calculate the split factors for
+
+ AixLib.ThermalZones.ReducedOrder.RC.BaseClasses.ThermSplitter.
+ For internal gains, the calculation is:
+
+ SplitFaci = AArray[i]
+ /ATot
+
+ whereby ATot is the sum of AArray. To
+ perform this,
+ AExt and AWin can just be set to vectors of
+ zeros with length 1.
+ For solar radiation through windows, the window and wall area with the same
+ orientation as the incoming radiation should be subtracted as these areas
+ cannot be hit by the radiation. This needs to be done separately for each
+ orientation and for exterior walls and windows only, according to:
+
+ SplitFaci,k = (AArray[i]
+ - AExt[k])
+ /(ATot
+ - AExt[k]
+ -AWin[k])
+
+ and
+
+ SplitFaci,k = (AArray[i]
+ - AWin[k])
+ /(ATot
+ - AExt[k]
+ - AWin[k])
+
+ respectively. For all other walls, the equation is:
+
+ SplitFaci,k = AArray[i]
+ /(ATot
+ - AExt[k]
+ - AWin[k])
+
+
+
+ - December 15, 2015 by Moritz Lauster:
+ First Implementation.
+
+
+
+-------- Corrected Code --------
+
+ Calculates the ratio of the surface areas of a wall to the total wall
+ area, unless the area is zero. It subtracts the wall area
+ AExt for first entry in AArray and
+ AWin for second entry in AArray unless
+ AArray[1] and/or AArray[2] are not zero.
+ This is done separately for each orientation. Consequently, the
+ function gives an nRow x nCol array back as output. Each
+ row stands for one area in AArray and each column for
+ one orientation in AExt and AWin. The
+ function is used to calculate the split factors for AixLib.ThermalZones.ReducedOrder.RC.BaseClasses.ThermSplitter.
+
For internal gains, the calculation is:
+
+ SplitFaci = AArray[i] /ATot
+
whereby ATot is the sum of AArray. To
+perform this, AExt and AWin can just be set
+to vectors of zeros with length 1. For solar radiation through windows,
+the window and wall area with the same orientation as the incoming
+radiation should be subtracted as these areas cannot be hit by the
+radiation. This needs to be done separately for each orientation and
+for exterior walls and windows only, according to:
+
+ SplitFaci,k = (AArray[i] - AExt[k]) /(ATot - AExt[k]
+ -AWin[k])
+
and
+
+ SplitFaci,k = (AArray[i] - AWin[k]) /(ATot - AExt[k] -
+ AWin[k])
+
respectively. For all other walls, the equation is:
+
+ SplitFaci,k = AArray[i] /(ATot - AExt[k] - AWin[k])
+
+
+ - December 15, 2015 by Moritz Lauster:
+ First Implementation.
+
+
+
+-------- Errors --------
+line 15 column 4 - Warning: attribute "align" not allowed for HTML5
+line 27 column 4 - Warning:
attribute "align" not allowed for HTML5
+line 35 column 4 - Warning:
attribute "align" not allowed for HTML5
+line 43 column 4 - Warning:
attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/HeatPumps/Compressors/ScrollCompressor.mo ----
+-------- HTML Code --------
+
+
+ Model for a scroll processor, as detailed in Jin (2002). The rate of heat transferred to the evaporator is given by:
+
+
+ Q̇Eva = ṁref ( hVap(TEva) - hLiq(TCon) ).
- The condenser heat flow rate QCon_flow_nominal is used to assign
- the default value for the mass flow rates, which are used for the pressure drop
- calculations.
- It is also used to compute the part load efficiency.
- Hence, make sure that QCon_flow_nominal is set to a reasonable value.
+ The power consumed by the compressor is given by a linear efficiency relation:
+
+
+ P = PTheoretical / η + PLoss,constant.
- The maximum heating capacity is set by the parameter QCon_flow_max,
- which is by default set to infinity.
+ Variable speed is achieved by multiplying the full load suction volume flow rate
+ by the normalized compressor speed. The power and heat transfer rates are forced
+ to zero if the resulting heat pump state has higher evaporating pressure than
+ condensing pressure.
+ Assumptions and limitations
- The coefficient of performance depends on the
- evaporator and condenser leaving temperature
- since otherwise the second law of thermodynamics may be violated.
+ The compression process is assumed isentropic. The thermal energy
+ of superheating is ignored in the evaluation of the heat transferred to the refrigerant
+ in the evaporator. There is no supercooling.
- Notes
+ References
- For a similar model that can be used as a chiller, see
- AixLib.Fluid.Chillers.Carnot_y.
+ H. Jin.
+
+ Parameter estimation based models of water source heat pumps.
+
+ PhD Thesis. Oklahoma State University. Stillwater, Oklahoma, USA. 2002.
-
- January 3, 2017, by Michael Wetter:
- Removed parameters
- effInpEva and effInpCon
- and updated documentation.
- This is for
-
- issue 497.
-
- -
- August 8, 2016, by Michael Wetter:
- Changed default temperature to compute COP to be the leaving temperature as
- use of the entering temperature can violate the 2nd law if the temperature
- lift is small.
- This is for
-
- Annex 60, issue 497.
-
- -
- January 26, 2016, by Michael Wetter:
- Refactored model to use the same base class as
- AixLib.Fluid.Chillers.Carnot_y.
- Changed part load efficiency to depend on heating part load ratio rather than on the compressor
- part load ratio.
-
- -
- January 20, 2015, by Damien Picard:
- Add Carnot model to Annex 60 from the Buildings library.
- Removed the flow direction dependency of
- staA1, staB1, staA2 and staB2 as the
- efficiency of the Carnot machine should only be computed in the design flow direction.
-
- -
- December 18, 2015, by Michael Wetter:
- Corrected wrong computation of staB1 and staB2
- which mistakenly used the inStream operator
- for the configuration without flow reversal.
- This is for
-
- issue 476.
-
- -
- November 25, 2015 by Michael Wetter:
- Changed sign convention for dTEva_nominal to be consistent with
- other models.
- The model will still work with the old values for dTEva_nominal,
- but it will write a warning so that users can transition their models.
-
- Corrected assert statement for the efficiency curve.
- This is for
-
- issue 468.
-
- -
- September 3, 2015 by Michael Wetter:
- Expanded documentation.
-
- -
- May 6, 2015 by Michael Wetter:
- Added prescribedHeatFlowRate=true for vol2.
-
- -
- October 9, 2013 by Michael Wetter:
- Reimplemented the computation of the port states to avoid using
- the conditionally removed variables sta_a1,
- sta_a2, sta_b1 and sta_b2.
-
- -
- May 10, 2013 by Michael Wetter:
- Added electric power P as an output signal.
+ January 25, 2019, by Michael Wetter:
+ Added start value to avoid warning in JModelica.
-
- October 11, 2010 by Michael Wetter:
- Fixed bug in energy balance.
+ May 30, 2017, by Filip Jorissen:
+ Removed pressure_error as
+ this is replaced by
+
+ AixLib.Fluid.HeatPumps.Compressors.BaseClasses.TemperatureProtection.
+ See #769.
-
- March 3, 2009 by Michael Wetter:
+ November 11, 2016, by Massimo Cimmino:
First implementation.
-------- Corrected Code --------
- This is model of a heat pump whose coefficient of performance COP
- changes with temperatures in the same way as the Carnot efficiency
- changes. The input signal y is the control signal for the
- compressor.
-
-
- The model allows to either specify the Carnot effectivness
- ηCarnot,0, or a COP0 at the
- nominal conditions, together with the evaporator temperature
- Teva,0 and the condenser temperature
- Tcon,0, in which case the model computes the Carnot
- effectivness as
+ Model for a scroll processor, as detailed in Jin (2002). The rate of
+ heat transferred to the evaporator is given by:
- ηCarnot,0 = COP0 ⁄ (Tcon,0 ⁄
- (Tcon,0-Teva,0)).
+ Q̇Eva = ṁref (
+ hVap(TEva) - hLiq(TCon)
+ ).
- The heat pump COP is computed as the product
+ The power consumed by the compressor is given by a linear efficiency
+ relation:
- COP = ηCarnot,0 COPCarnot ηPL,
+ P = PTheoretical / η + PLoss,constant.
- where COPCarnot is the Carnot efficiency and
- ηPL is a polynomial in the heating part load ratio
- yPL that can be used to take into account a change
- in COP at part load conditions. This polynomial has the form
-
-
- ηPL = a1 + a2 yPL +
- a3 yPL2 + ...
-
-
- where the coefficients ai are declared by the
- parameter a.
-
-
- On the Dynamics tag, the model can be parametrized to
- compute a transient or steady-state response. The transient response
- of the model is computed using a first order differential equation
- for the evaporator and condenser fluid volumes. The heat pump outlet
- temperatures are equal to the temperatures of these lumped volumes.
+ Variable speed is achieved by multiplying the full load suction
+ volume flow rate by the normalized compressor speed. The power and
+ heat transfer rates are forced to zero if the resulting heat pump
+ state has higher evaporating pressure than condensing pressure.
- Typical use and important parameters
+ Assumptions and limitations
- When using this component, make sure that the evaporator and the
- condenser have sufficient mass flow rate. Based on the mass flow
- rates, the compressor power, temperature difference and the
- efficiencies, the model computes how much heat will be added to the
- condenser and removed at the evaporator. If the mass flow rates are
- too small, very high temperature differences can result.
-
-
- The condenser heat flow rate QCon_flow_nominal is used
- to assign the default value for the mass flow rates, which are used
- for the pressure drop calculations. It is also used to compute the
- part load efficiency. Hence, make sure that
- QCon_flow_nominal is set to a reasonable value.
-
-
- The maximum heating capacity is set by the parameter
- QCon_flow_max, which is by default set to infinity.
-
-
- The coefficient of performance depends on the evaporator and
- condenser leaving temperature since otherwise the second law of
- thermodynamics may be violated.
+ The compression process is assumed isentropic. The thermal energy of
+ superheating is ignored in the evaluation of the heat transferred to
+ the refrigerant in the evaporator. There is no supercooling.
- Notes
+ References
- For a similar model that can be used as a chiller, see AixLib.Fluid.Chillers.Carnot_y.
+ H. Jin. Parameter estimation based models of water source heat
+ pumps. PhD Thesis. Oklahoma State University. Stillwater,
+ Oklahoma, USA. 2002.
- - January 3, 2017, by Michael Wetter:
- Removed parameters effInpEva and
- effInpCon and updated documentation. This is for
- issue
- 497.
-
- - August 8, 2016, by Michael Wetter:
- Changed default temperature to compute COP to be the leaving
- temperature as use of the entering temperature can violate the 2nd
- law if the temperature lift is small.
- This is for Annex 60,
- issue 497.
-
- - January 26, 2016, by Michael Wetter:
- Refactored model to use the same base class as AixLib.Fluid.Chillers.Carnot_y.
-
- Changed part load efficiency to depend on heating part load ratio
- rather than on the compressor part load ratio.
-
- - January 20, 2015, by Damien Picard:
- Add Carnot model to Annex 60 from the Buildings library.
- Removed the flow direction dependency of staA1,
- staB1, staA2 and staB2 as
- the efficiency of the Carnot machine should only be computed in the
- design flow direction.
-
- - December 18, 2015, by Michael Wetter:
- Corrected wrong computation of staB1 and
- staB2 which mistakenly used the inStream
- operator for the configuration without flow reversal. This is for
- issue
- 476.
-
- - November 25, 2015 by Michael Wetter:
- Changed sign convention for dTEva_nominal to be
- consistent with other models. The model will still work with the
- old values for dTEva_nominal, but it will write a
- warning so that users can transition their models.
- Corrected assert statement for the efficiency curve.
- This is for issue
- 468.
-
- - September 3, 2015 by Michael Wetter:
- Expanded documentation.
-
- - May 6, 2015 by Michael Wetter:
- Added prescribedHeatFlowRate=true for
- vol2.
-
- - October 9, 2013 by Michael Wetter:
- Reimplemented the computation of the port states to avoid using the
- conditionally removed variables sta_a1,
- sta_a2, sta_b1 and sta_b2.
-
- - May 10, 2013 by Michael Wetter:
- Added electric power P as an output signal.
+ - January 25, 2019, by Michael Wetter:
+ Added start value to avoid warning in JModelica.
- - October 11, 2010 by Michael Wetter:
- Fixed bug in energy balance.
+ - May 30, 2017, by Filip Jorissen:
+ Removed pressure_error as this is replaced by
+ AixLib.Fluid.HeatPumps.Compressors.BaseClasses.TemperatureProtection.
+ See #769.
- - March 3, 2009 by Michael Wetter:
+ - November 11, 2016, by Massimo Cimmino:
First implementation.
-------- Errors --------
-line 16 column 2 - Warning: attribute "align" not allowed for HTML5
-line 24 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 34 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 5 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 11 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/Actuators/Valves/Examples/TwoWayValveTable.mo ----
+---- AixLib/Fluid/FMI/ExportContainers/ThermalZone.mo ----
-------- HTML Code --------
- Test model for a two way valve in which a table is used to specify the
- opening characteristics.
- The valve has the following opening characteristics, which is taken from a test case
- of the IEA EBC Annex 60 project.
-
-
- | y |
- 0 | 0.1667 | 0.3333 | 0.5 | 0.6667 | 1 |
-
- | Kv |
- 0 | 0.19 | 0.35 | 0.45 | 0.5 | 0.65 |
-
-
- The Kv value is the volume flow rate in m3/h at a pressure difference
- of 1 bar.
- Hence, the Kv value of the fully open valve is Kv=0.65.
-
-
- Plotting the variables kv.y versus y.y shows that the valve
- reproduces the Kv values shown in the above table.
-
-
- ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Actuators/Valves/Examples/TwoWayValveTable_kv.png\"/)
+ Model that is used as a container for a single thermal zone
+ that is to be exported as an FMU.
+ Typical use and important parameters
- The parameter filterOpening is set to false,
- as this model is used to plot the flow at different opening signals
- without taking into account the travel time of the actuator.
+ To use this model as a container for an FMU, extend
+ from this model, rather than instantiate it,
+ add your thermal zone and a vector of mass flow rate sensors.
+ By extending from this model, the top-level
+ signal connectors on the left stay at the top-level, and hence
+ will be visible at the FMI interface.
+ Note that
-
- August 12, 2014 by Michael Wetter:
- Added parameter keyword to datVal,
- as this is needed to asssign datVal to a parameter
- in the instance valTab.
- This also avoids an error in OpenModelica.
+ The vector of mass flow rate sensors is used to connect
+ the thermal zone adapter and your thermal zone.
-
- April 2, 2014 by Michael Wetter:
- First implementation.
-
-
-
--------- Corrected Code --------
-
- Test model for a two way valve in which a table is used to specify
- the opening characteristics. The valve has the following opening
- characteristics, which is taken from a test case of the IEA EBC Annex
- 60 project.
-
-
-
- |
- y
- |
-
- 0
- |
-
- 0.1667
- |
-
- 0.3333
- |
-
- 0.5
- |
-
- 0.6667
- |
-
- 1
- |
-
-
- |
- Kv
- |
-
- 0
- |
-
- 0.19
- |
-
- 0.35
- |
-
- 0.45
- |
-
- 0.5
- |
-
- 0.65
- |
-
-
-
- The Kv value is the volume flow rate in
- m3/h at a pressure difference of 1 bar. Hence, the
- Kv value of the fully open valve is
- Kv=0.65.
-
-
- Plotting the variables kv.y versus y.y
- shows that the valve reproduces the Kv values shown
- in the above table.
-
-
-
-
-
- The parameter filterOpening is set to
- false, as this model is used to plot the flow at
- different opening signals without taking into account the travel time
- of the actuator.
-
-
- - August 12, 2014 by Michael Wetter:
- Added parameter keyword to datVal, as
- this is needed to asssign datVal to a parameter in the
- instance valTab. This also avoids an error in
- OpenModelica.
-
- - April 2, 2014 by Michael Wetter:
- First implementation.
-
-
-
--------- Errors --------
-line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 24 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/FMI/ExportContainers/ThermalZone.mo ----
--------- HTML Code --------
-
-
- Model that is used as a container for a single thermal zone
- that is to be exported as an FMU.
-
- Typical use and important parameters
-
- To use this model as a container for an FMU, extend
- from this model, rather than instantiate it,
- add your thermal zone and a vector of mass flow rate sensors.
- By extending from this model, the top-level
- signal connectors on the left stay at the top-level, and hence
- will be visible at the FMI interface.
-
-
- Note that
-
- -
- The vector of mass flow rate sensors is used to connect
- the thermal zone adapter and your thermal zone.
-
- -
- The vector of mass flow rate sensors must have the size
nPorts.
-
- -
- All fluid ports of the mass flow rate sensor must be connected.
-
- -
- If the vector of mass flow rate sensors is not used, and your themal zone
- has fluid ports which are autosized, then a direct connection between
- the thermal zone adpater
theZonAda and your thermal
- zone will be rejected. The reason is because autosized fluid ports
- can only be connected to vector of ports whose sizes are literal.
+ The vector of mass flow rate sensors must have the size nPorts.
+
+ -
+ All fluid ports of the mass flow rate sensor must be connected.
+
+ -
+ If the vector of mass flow rate sensors is not used, and your themal zone
+ has fluid ports which are autosized, then a direct connection between
+ the thermal zone adpater
theZonAda and your thermal
+ zone will be rejected. The reason is because autosized fluid ports
+ can only be connected to vector of ports whose sizes are literal.
@@ -9469,448 +8704,410 @@ line 24 column 2 - Warning: attribute "align" not allowed for HTML5
line 72 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatPumps/ReciprocatingWaterToWater.mo ----
+---- AixLib/Fluid/HeatExchangers/Radiators/RadiatorEN442_2.mo ----
-------- HTML Code --------
- Model for a water to water heat pump with a reciprocating compressor, as
- described in Jin (2002). The thermodynamic heat pump cycle is represented below.
-
-
-
+ This is a model of a radiator that can be used as a dynamic or steady-state model.
+ The required parameters are data that are typically available from
+ manufacturers that follow the European Norm EN 442-2.
- The rate of heat transferred to the evaporator is given by:
-
-
- Q̇Eva = ṁref ( hVap(TEva) - hLiq(TCon) ).
+ However, to allow for varying mass flow rates, the transferred heat is computed
+ using a discretization along the water flow path, and heat is exchanged between
+ each compartment and a uniform room air and radiation temperature.
+ This discretization is different from the computation in EN 442-2, which
+ may yield water outlet temperatures that are below
+ the room temperature at low mass flow rates.
+ Furthermore, rather than using only one room temperature, this model uses
+ a room air and room radiation temperature.
- The power consumed by the compressor is given by a linear efficiency relation:
+ The transferred heat is modeled as follows:
+ Let N denote the number of elements used to discretize the radiator model.
+ For each element i ∈ {1, … , N},
+ the convective and radiative heat transfer
+ Qic and
+ Qir
+ from the radiator to the room is
- P = PTheoretical / η + PLoss,constant.
-
-
- Heat transfer in the evaporator and condenser is calculated using an
- ε-NTU method, assuming constant refrigerant temperature and constant heat
- transfer coefficient between fluid and refrigerant.
-
-
- Variable speed is acheived by multiplying the full load piston displacement
- by the normalized compressor speed. The power and heat transfer rates are forced
- to zero if the resulting heat pump state has higher evaporating pressure than
- condensing pressure.
+ Qic = sign(Ti-Ta)
+ (1-fr) UA ⁄ N |Ti-Ta|n
+
+ Qir = sign(Ti-Tr)
+ fr UA ⁄ N |Ti-Tr|n
- Options
- Parameters TConMax and TEvaMin
- may be used to set an upper or lower bound for the
- condenser and evaporator.
- The compressor is disabled when these conditions
- are not satisfied, or when the
- evaporator temperature is larger
- than the condenser temperature.
- This mimics the temperature protection
- of heat pumps and moreover it avoids
- non-converging algebraic loops of equations,
- or freezing of evaporator medium.
- This option can be disabled by setting
- enable_temperature_protection = false.
+ where
+ Ti is the water temperature of the element,
+ Ta is the temperature of the room air,
+ Tr is the radiative temperature,
+ 0 < fr < 1 is the fraction of radiant to total heat transfer,
+ UA is the UA-value of the radiator,
+ and
+ n is an exponent for the heat transfer.
+ The model computes the UA-value by numerically solving the above equations
+ for given
+ nominal heating power, nominal temperatures, fraction radiant to total heat transfer
+ and exponent for heat transfer.
- Assumptions and limitations
- The compression process is assumed isentropic. The thermal energy
- of superheating is ignored in the evaluation of the heat transferred to the refrigerant
- in the evaporator. There is no supercooling.
+ The parameter energyDynamics (in the Assumptions tab),
+ determines whether the model computes the dynamic or the steady-state response.
+ For the transient response, heat storage is computed using a
+ finite volume approach for the
+ water and the metal mass, which are both assumed to be at the same
+ temperature.
- References
- H. Jin.
-
- Parameter estimation based models of water source heat pumps.
-
- PhD Thesis. Oklahoma State University. Stillwater, Oklahoma, USA. 2002.
+ The default parameters for the heat capacities are valid for a flat plate radiator without fins,
+ with one plate of water carying fluid, and a height of 0.42 meters.
-
- May 30, 2017, by Filip Jorissen:
- Revised documentation for temperature protection.
- See #769.
+ March 7, 2022, by Michael Wetter:
+ Set final massDynamics=energyDynamics.
+ This is for
+ #1542.
-
- November 14, 2016, by Massimo Cimmino:
+ April 14, 2020, by Michael Wetter:
+ Changed homotopyInitialization to a constant.
+ This is for
+ IBPSA, #1341.
+
+ -
+ February 21, 2020, by Michael Wetter:
+ Changed icon to display its operating state.
+ This is for
+ #1294.
+
+ -
+ November 17, 2016, by Filip Jorissen:
+ Added pressure drop equations and parameters.
+ This is for
+ #586.
+
+ -
+ November 3, 2016, by Michael Wetter:
+ Set preHea(final alpha=0) as this allows to simplify the
+ system of equations.
+ This is for
+ #570.
+
+ -
+ March 17, 2016, by Michael Wetter:
+ Reformulated model to reduce the dimension of the nonlinear system of equations.
+ This is for
+ #435.
+
+ -
+ November 19, 2015, by Michael Wetter:
+ Removed assignment of parameter
+ showDesignFlowDirection in extends statement.
+ This is for
+ #349.
+
+ -
+ April 11, 2015, by Filip Jorissen:
+ Propagated vol.massDynamics to
+ top level parameter massDynamics instead of energyDynamics.
+
+ -
+ November 25, 2014, by Carles Ribas Tugores:
+ Interchange position of fraRad parameter and the complementary (1-fraRad)
+ in the equation used to calculate the nominal heating power of each element, QEle_flow_nominal[i].
+
+ -
+ October 29, 2014, by Michael Wetter:
+ Made assignment of mFactor final, and changed computation of
+ density to use default medium states as are also used to compute the
+ specific heat capacity.
+
+ -
+ October 21, 2014, by Filip Jorissen:
+ Added parameter mFactor and removed thermal capacity
+ which can lead to an index reduction.
+
+ -
+ May 29, 2014, by Michael Wetter:
+ Removed undesirable annotation Evaluate=true.
+
+ -
+ October 8, 2013 by Michael Wetter:
+ Removed conditional statement in the declaration of the parameter
+ mDry, as this is incorrect syntax.
+
+ -
+ September 26, 2013 by Michael Wetter:
+ Reformulated implementation to avoid mixing textual and graphical
+ declarations in the equation section.
+
+ -
+ April 4, 2011 by Michael Wetter:
+ Changed the implementation to use
+
+ AixLib.Utilities.Math.Functions.regNonZeroPower.
+ This allows formulating the model without any non-differentiable function
+ inside the equation section.
+
+ -
+ April 2, 2011 by Michael Wetter:
+ Added homotopy operator.
+
+ -
+ February 11, 2011 by Michael Wetter:
+ Revised the initialization to ensure that at the nominal conditions, the
+ amount of transferred heat is excatly the same as the specified nominal power.
+ In the previous implementation, the UA-value was computed using a simplified
+ expression for the temperature difference, leading to a slightly different amount
+ of heat transfer.
+
+ -
+ February 4, 2011 by Michael Wetter:
+ Simplified implementation.
+
+ -
+ January 30, 2009 by Michael Wetter:
First implementation.
-------- Corrected Code --------
- Model for a water to water heat pump with a reciprocating compressor,
- as described in Jin (2002). The thermodynamic heat pump cycle is
- represented below.
-
-
-
+ This is a model of a radiator that can be used as a dynamic or
+ steady-state model. The required parameters are data that are
+ typically available from manufacturers that follow the European Norm
+ EN 442-2.
- The rate of heat transferred to the evaporator is given by:
-
-
- Q̇Eva = ṁref (
- hVap(TEva) - hLiq(TCon)
- ).
+ However, to allow for varying mass flow rates, the transferred heat
+ is computed using a discretization along the water flow path, and
+ heat is exchanged between each compartment and a uniform room air and
+ radiation temperature. This discretization is different from the
+ computation in EN 442-2, which may yield water outlet temperatures
+ that are below the room temperature at low mass flow rates.
+ Furthermore, rather than using only one room temperature, this model
+ uses a room air and room radiation temperature.
- The power consumed by the compressor is given by a linear efficiency
- relation:
+ The transferred heat is modeled as follows: Let N denote the
+ number of elements used to discretize the radiator model. For each
+ element i ∈ {1, … , N}, the convective and radiative heat
+ transfer Qic and
+ Qir from the radiator to the room is
- P = PTheoretical / η + PLoss,constant.
-
-
- Heat transfer in the evaporator and condenser is calculated using an
- ε-NTU method, assuming constant refrigerant temperature and constant
- heat transfer coefficient between fluid and refrigerant.
-
-
- Variable speed is acheived by multiplying the full load piston
- displacement by the normalized compressor speed. The power and heat
- transfer rates are forced to zero if the resulting heat pump state
- has higher evaporating pressure than condensing pressure.
+ Qic = sign(Ti-Ta)
+ (1-fr) UA ⁄ N
+ |Ti-Ta|n
+
+ Qir = sign(Ti-Tr)
+ fr UA ⁄ N |Ti-Tr|n
-
- Options
-
- Parameters TConMax and TEvaMin may be used
- to set an upper or lower bound for the condenser and evaporator. The
- compressor is disabled when these conditions are not satisfied, or
- when the evaporator temperature is larger than the condenser
- temperature. This mimics the temperature protection of heat pumps and
- moreover it avoids non-converging algebraic loops of equations, or
- freezing of evaporator medium. This option can be disabled by setting
- enable_temperature_protection = false.
+ where Ti is the water temperature of the element,
+ Ta is the temperature of the room air,
+ Tr is the radiative temperature, 0 <
+ fr < 1 is the fraction of radiant to total heat
+ transfer, UA is the UA-value of the radiator, and n is
+ an exponent for the heat transfer. The model computes the UA-value by
+ numerically solving the above equations for given nominal heating
+ power, nominal temperatures, fraction radiant to total heat transfer
+ and exponent for heat transfer.
-
- Assumptions and limitations
-
- The compression process is assumed isentropic. The thermal energy of
- superheating is ignored in the evaluation of the heat transferred to
- the refrigerant in the evaporator. There is no supercooling.
+ The parameter energyDynamics (in the Assumptions tab),
+ determines whether the model computes the dynamic or the steady-state
+ response. For the transient response, heat storage is computed using
+ a finite volume approach for the water and the metal mass, which are
+ both assumed to be at the same temperature.
-
- References
-
- H. Jin. Parameter estimation based models of water source heat
- pumps. PhD Thesis. Oklahoma State University. Stillwater,
- Oklahoma, USA. 2002.
+ The default parameters for the heat capacities are valid for a flat
+ plate radiator without fins, with one plate of water carying fluid,
+ and a height of 0.42 meters.
- - May 30, 2017, by Filip Jorissen:
- Revised documentation for temperature protection. See #769.
+ - March 7, 2022, by Michael Wetter:
+ Set final massDynamics=energyDynamics.
+ This is for #1542.
- - November 14, 2016, by Massimo Cimmino:
+ - April 14, 2020, by Michael Wetter:
+ Changed homotopyInitialization to a constant.
+ This is for IBPSA,
+ #1341.
+
+ - February 21, 2020, by Michael Wetter:
+ Changed icon to display its operating state.
+ This is for #1294.
+
+ - November 17, 2016, by Filip Jorissen:
+ Added pressure drop equations and parameters.
+ This is for #586.
+
+ - November 3, 2016, by Michael Wetter:
+ Set preHea(final alpha=0) as this allows to simplify
+ the system of equations.
+ This is for #570.
+
+ - March 17, 2016, by Michael Wetter:
+ Reformulated model to reduce the dimension of the nonlinear system
+ of equations. This is for #435.
+
+ - November 19, 2015, by Michael Wetter:
+ Removed assignment of parameter
+ showDesignFlowDirection in extends
+ statement. This is for #349.
+
+ - April 11, 2015, by Filip Jorissen:
+ Propagated vol.massDynamics to top level parameter
+ massDynamics instead of energyDynamics.
+
+ - November 25, 2014, by Carles Ribas Tugores:
+ Interchange position of fraRad parameter and the
+ complementary (1-fraRad) in the equation used to
+ calculate the nominal heating power of each element,
+ QEle_flow_nominal[i].
+
+ - October 29, 2014, by Michael Wetter:
+ Made assignment of mFactor final, and changed
+ computation of density to use default medium states as are also
+ used to compute the specific heat capacity.
+
+ - October 21, 2014, by Filip Jorissen:
+ Added parameter mFactor and removed thermal capacity
+ which can lead to an index reduction.
+
+ - May 29, 2014, by Michael Wetter:
+ Removed undesirable annotation Evaluate=true.
+
+ - October 8, 2013 by Michael Wetter:
+ Removed conditional statement in the declaration of the parameter
+ mDry, as this is incorrect syntax.
+
+ - September 26, 2013 by Michael Wetter:
+ Reformulated implementation to avoid mixing textual and graphical
+ declarations in the equation section.
+
+ - April 4, 2011 by Michael Wetter:
+ Changed the implementation to use AixLib.Utilities.Math.Functions.regNonZeroPower.
+ This allows formulating the model without any non-differentiable
+ function inside the equation section.
+
+ - April 2, 2011 by Michael Wetter:
+ Added homotopy operator.
+
+ - February 11, 2011 by Michael Wetter:
+ Revised the initialization to ensure that at the nominal
+ conditions, the amount of transferred heat is excatly the same as
+ the specified nominal power. In the previous implementation, the
+ UA-value was computed using a simplified expression for the
+ temperature difference, leading to a slightly different amount of
+ heat transfer.
+
+ - February 4, 2011 by Michael Wetter:
+ Simplified implementation.
+
+ - January 30, 2009 by Michael Wetter:
First implementation.
-------- Errors --------
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
-line 12 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 18 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 26 column 2 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Fluid/FMI/ExportContainers/HVACZones.mo ----
+---- AixLib/Fluid/Geothermal/Borefields/Types.mo ----
-------- HTML Code --------
- Model that is used as a container for an HVAC system that is
- to be exported as an FMU and that serves multiple zones.
-
- Typical use and important parameters
-
- To use this model as a container for an FMU, simply extend
- from this model, rather than instantiate it,
- and add your HVAC system. By extending from this model, the top-level
- signal connectors on the right stay at the top-level, and hence
- will be visible at the FMI interface.
- The example
-
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZones
- shows how a simple HVAC system that serves two rooms can be implemented and exported as
- an FMU.
-
-
-
- The following two parameters need to be assigned by the user:
- Set nZon to the number of thermal zones to which the
- FMU will be connected.
- Set nPorts to the largest number of fluid ports
- that the thermal zones has. For example,
- if nZon=2 and zone 1 has one inlet and one outlet
- (hence it has 2 ports),
- and zone 2 has one inlets and two outlets
- (hence it has 3 ports), then
- set nPorts=3. This will add more fluid ports than are needed
- for zone 1, but this causes no overhead if they are not connected.
+ Enumeration that defines the pipe configuration in the borehole.
- The conversion between the fluid ports and signal ports is done
- in the HVAC adapter hvacAda.
- This adapter has a vector of fluid ports called ports.
- The supply and return air ducts, including any resistance model for the inlet
- diffusor or exhaust grill, need to be connected to these ports.
- Also, if a thermal zone has interzonal air exchange or air infiltration,
- these flows need to be connected to ports.
- This model outputs at the port fluPor the mass flow rate for
- each flow that is connected to ports, together with its
- temperature, water vapor mass fraction per total mass of the air (not per kg dry
- air), and trace substances. These quantities are always as if the flow
- enters the room, even if the flow is zero or negative.
- If a medium has no moisture, e.g., if Medium.nXi=0, or
- if it has no trace substances, e.g., if Medium.nC=0, then
- the output signal for these properties are removed.
- These quantities are always as if the flow
- enters the room, even if the flow is zero or negative.
- Thus, a thermal zone model that uses these signals to compute the
- heat added by the HVAC system need to implement an equation such as
-
-
- Qsen = max(0, ṁsup) cp (Tsup - Tair,zon),
-
-
- where
- Qsen is the sensible heat flow rate added to the thermal zone,
- ṁsup is the supply air mass flow rate from
- the port fluPor (which is negative if it is an exhaust),
- cp is the specific heat capacity at constant pressure,
- Tsup is the supply air temperature and
- Tair,zon is the zone air temperature.
- Note that without the max(·, ·), the energy
- balance would be wrong.
+ The following pipe configurations are available in this enumeration:
+
+ | Enumeration | Description |
|---|
+ | SingleUTube | Single U-tube configuration |
-
- The input signals of this model are the radiative temperature of each zone.
- The the zone air temperatures,
- the water vapor mass fractions per total mass of the air (unless Medium.nXi=0)
- and trace substances (unless Medium.nC=0) are obtained from the connector
- fluPor.backward.
- The outflowing fluid stream(s) at the port ports will be at the
- states obtained from fluPor.backward.
- For any given izon ∈ {1, ..., nzon},
- for each iports ∈ {1, ..., nports}
- all fluid streams at port ports[izon, iports] are at the same
- pressure.
- For convenience, the instance hvacAda also outputs the
- properties obtained from fluPor.backward. These can be used
- to connect a controller. The properties are available for each flow path in
- fluPor.backward. For a thermal zone with mixed air, these are
- all equal, while for a stratified room model, they can be different.
-
-
- See
-
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZones
- for a model that uses this model.
-
-
- For models that only have one thermal zone connected to the HVAC system,
- use the simpler model
-
- AixLib.Fluid.FMI.ExportContainers.HVACZone.
-
- Assumption and limitations
-
- The mass flow rates at ports sum to zero, hence this
- model conserves mass for each thermal zone.
-
-
- This model does not impose any pressure, other than,
- for any given izon ∈ {1, ..., nzon} and
- for each j,k ∈ {1, ..., nports},
- setting the pressure of ports[izon, j].p = ports[izon, k].p
- to be the same.
- The reason is that setting a pressure can lead to non-physical system models,
- for example if a mass flow rate is imposed and the HVAC system is connected
- to a model that sets a pressure boundary condition such as
-
- AixLib.Fluid.Sources.Outside.
- Also, setting a pressure would make it impossible to use multiple instances
- of this model (one for each thermal zone) and build in Modelica an airflow network
- model with pressure driven mass flow rates.
-
-
- The model has no pressure drop. Hence, the pressure drop
- of an air diffuser or of an exhaust grill needs to be modelled
- in models that are connected to ports.
-
+ | DoubleUTubeParallel | Double U-tube configuration with pipes connected in parallel |
+ | DoubleUTubeSeries | Double U-tube configuration with pipes connected in series |
+
-
- January 18, 2019, by Jianjun Hu:
- Limited the media choice to moist air only.
- See #1050.
-
- -
- May 25, 2016, by Michael Wetter:
+ July 15, 2018, by Michael Wetter:
First implementation.
+
+ This package contains type definitions.
+
+
-------- Corrected Code --------
- Model that is used as a container for an HVAC system that is to be
- exported as an FMU and that serves multiple zones.
-
-
- Typical use and important parameters
-
-
- To use this model as a container for an FMU, simply extend from this
- model, rather than instantiate it, and add your HVAC system. By
- extending from this model, the top-level signal connectors on the
- right stay at the top-level, and hence will be visible at the FMI
- interface. The example
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZones shows
- how a simple HVAC system that serves two rooms can be implemented and
- exported as an FMU.
-
-
- The following two parameters need to be assigned by the user: Set
- nZon to the number of thermal zones to which the FMU
- will be connected. Set nPorts to the largest number of
- fluid ports that the thermal zones has. For example, if
- nZon=2 and zone 1 has one inlet and one outlet
- (hence it has 2 ports), and zone 2 has one inlets and two
- outlets (hence it has 3 ports), then set nPorts=3. This
- will add more fluid ports than are needed for zone 1, but this
- causes no overhead if they are not connected.
-
-
- The conversion between the fluid ports and signal ports is done in
- the HVAC adapter hvacAda. This adapter has a vector of
- fluid ports called ports. The supply and return air
- ducts, including any resistance model for the inlet diffusor or
- exhaust grill, need to be connected to these ports. Also, if a
- thermal zone has interzonal air exchange or air infiltration, these
- flows need to be connected to ports. This model outputs
- at the port fluPor the mass flow rate for each flow that
- is connected to ports, together with its temperature,
- water vapor mass fraction per total mass of the air (not per kg dry
- air), and trace substances. These quantities are always as if the
- flow enters the room, even if the flow is zero or negative. If a
- medium has no moisture, e.g., if Medium.nXi=0, or if it
- has no trace substances, e.g., if Medium.nC=0, then the
- output signal for these properties are removed. These quantities are
- always as if the flow enters the room, even if the flow is zero or
- negative. Thus, a thermal zone model that uses these signals to
- compute the heat added by the HVAC system need to implement an
- equation such as
-
-
- Qsen = max(0, ṁsup) cp
- (Tsup - Tair,zon),
-
-
- where Qsen is the sensible heat flow rate added to
- the thermal zone, ṁsup is the supply air mass flow
- rate from the port fluPor (which is negative if it is an
- exhaust), cp is the specific heat capacity at
- constant pressure, Tsup is the supply air
- temperature and Tair,zon is the zone air
- temperature. Note that without the max(·, ·), the energy
- balance would be wrong.
-
-
- The input signals of this model are the radiative temperature of each
- zone. The the zone air temperatures, the water vapor mass fractions
- per total mass of the air (unless Medium.nXi=0) and
- trace substances (unless Medium.nC=0) are obtained from
- the connector fluPor.backward. The outflowing fluid
- stream(s) at the port ports will be at the states
- obtained from fluPor.backward. For any given
- izon ∈ {1, ..., nzon}, for each
- iports ∈ {1, ..., nports} all fluid
- streams at port ports[izon,
- iports] are at the same pressure. For convenience,
- the instance hvacAda also outputs the properties
- obtained from fluPor.backward. These can be used to
- connect a controller. The properties are available for each flow path
- in fluPor.backward. For a thermal zone with mixed air,
- these are all equal, while for a stratified room model, they can be
- different.
-
-
- See
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZones for a
- model that uses this model.
-
-
- For models that only have one thermal zone connected to the HVAC
- system, use the simpler model AixLib.Fluid.FMI.ExportContainers.HVACZone.
-
-
- Assumption and limitations
-
-
- The mass flow rates at ports sum to zero, hence this
- model conserves mass for each thermal zone.
-
-
- This model does not impose any pressure, other than, for any given
- izon ∈ {1, ..., nzon} and for each
- j,k ∈ {1, ..., nports}, setting the pressure of
- ports[izon, j].p = ports[izon,
- k].p to be the same. The reason is that setting a pressure can
- lead to non-physical system models, for example if a mass flow rate
- is imposed and the HVAC system is connected to a model that sets a
- pressure boundary condition such as AixLib.Fluid.Sources.Outside.
- Also, setting a pressure would make it impossible to use multiple
- instances of this model (one for each thermal zone) and build in
- Modelica an airflow network model with pressure driven mass flow
- rates.
+ Enumeration that defines the pipe configuration in the borehole.
- The model has no pressure drop. Hence, the pressure drop of an air
- diffuser or of an exhaust grill needs to be modelled in models that
- are connected to ports.
+ The following pipe configurations are available in this enumeration:
+
+
+ |
+ Enumeration
+ |
+
+ Description
+ |
+
+
+ |
+ SingleUTube
+ |
+
+ Single U-tube configuration
+ |
+
+
+ |
+ DoubleUTubeParallel
+ |
+
+ Double U-tube configuration with pipes connected in parallel
+ |
+
+
+ |
+ DoubleUTubeSeries
+ |
+
+ Double U-tube configuration with pipes connected in series
+ |
+
+
- - January 18, 2019, by Jianjun Hu:
- Limited the media choice to moist air only. See #1050.
-
- - May 25, 2016, by Michael Wetter:
+ - July 15, 2018, by Michael Wetter:
First implementation.
+
+ This package contains type definitions.
+
-------- Errors --------
-line 60 column 2 - Warning: attribute "align" not allowed for HTML5
+line 8 column 2 - Warning: The summary attribute on the
element is obsolete in HTML5
---- AixLib/ThermalZones/ReducedOrder/RC/ThreeElements.mo ----
@@ -10011,1347 +9208,1104 @@ line 60 column 2 - Warning: attribute "align" not allowed for HTML5
line 16 column 4 - Warning:
attribute "align" not allowed for HTML5
----- AixLib/Controls/SetPoints/Examples/SupplyReturnTemperatureReset.mo ----
+---- AixLib/Fluid/Sensors/UsersGuide.mo ----
-------- HTML Code --------
-
- Example that demonstrates the use of the hot water temperature reset
- for a heating system.
- The parameters of the block heaCur
- are for a heating system with
- 60°C supply water temperature and
- 40°C return water temperature at
- an outside temperature of
- -10°C and a room temperature of
- 20°C. The offset for the temperature reset is
- 8 Kelvin, i.e., above
- 12°C outside temperature, there is no heating load.
- The figure below shows the computed supply and return water temperatures.
-
-
- ![\"Supply](\"modelica://AixLib/Resources/Images/Controls/SetPoints/Examples/SupplyReturnTemperatureReset.png\")
-
-
-
- -
- November 21, 2011, by Michael Wetter:
- Added documentation.
-
-
-
--------- Corrected Code --------
- Example that demonstrates the use of the hot water temperature reset
- for a heating system. The parameters of the block heaCur
- are for a heating system with 60°C supply water temperature
- and 40°C return water temperature at an outside temperature of
- -10°C and a room temperature of 20°C. The offset for
- the temperature reset is 8 Kelvin, i.e., above 12°C
- outside temperature, there is no heating load. The figure below shows
- the computed supply and return water temperatures.
-
-
-
+This package contains models of sensors.
+There are models with one and with two fluid ports.
-
- - November 21, 2011, by Michael Wetter:
- Added documentation.
-
-
--------- Errors --------
-line 16 column 2 - Warning: attribute "align" not allowed for HTML5
+
Selection and parameterization of sensor models
+
+When selecting a sensor model, a distinction needs to be made
+whether the measured quantity depends on the direction of the flow or
+not, and whether the sensor output signal is the product of the mass flow rate
+and a medium property.
+
+
+Output signals that depend on the flow direction and are not multiplied by
+the mass flow rate are temperature, relative humidity,
+water vapor concentration X, trace substances C and density.
+For such quantities, sensors with two fluid ports need to be used.
+An exception is if the quantity is measured directly in a fluid volume, which is the case
+for models from the package
+
+AixLib.Fluid.MixingVolumes.
+Therefore, to measure for example the outlet temperature of a heat exchanger, the
+configuration labelled correct use in the figure below should be used, and not the configuration
+labelled not recommended.
+For an explanation, see
+
+Modelica.Fluid.Examples.Explanatory.MeasuringTemperature.
+
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/gFunction.mo ----
--------- HTML Code --------
+
+| Correct use |
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Sensors/twoPortHex.png\")
+ |
+
|---|
+| Not recommended |
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Sensors/onePortHex.png\")
+ |
+
|---|
+
-
- This function implements the g-function evaluation method introduced by
- Cimmino and Bernier (see: Cimmino and Bernier (2014), and Cimmino (2018)) based
- on the g-function function concept first introduced by Eskilson (1987).
- The g-function gives the relation between the variation of the borehole
- wall temperature at a time t and the heat extraction and injection rates
- at all times preceding time t as
-
-
- ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/GFunction_01.png\")
-
-
- where Tb is the borehole wall temperature,
- Tg is the undisturbed ground temperature, Q is the
- heat injection rate into the ground through the borehole wall per unit borehole
- length, ks is the soil thermal conductivity and g is
- the g-function.
-
-
- The g-function is constructed from the combination of the combination of
- the finite line source (FLS) solution (see
-
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.finiteLineSource),
- the cylindrical heat source (CHS) solution (see
-
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.cylindricalHeatSource),
- and the infinite line source (ILS) solution (see
-
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.infiniteLineSource).
- To obtain the g-function of a bore field, each borehole is divided into a
- series of nSeg segments of equal length, each modeled as a line
- source of finite length. The finite line source solution is superimposed in
- space to obtain a system of equations that gives the relation between the heat
- injection rate at each of the segments and the borehole wall temperature at each
- of the segments. The system is solved to obtain the uniform borehole wall
- temperature required at any time to maintain a constant total heat injection
- rate (Qtot = 2πksHtot) into the bore
- field. The uniform borehole wall temperature is then equal to the finite line
- source based g-function.
-
-
- Since this g-function is based on line sources of heat, rather than
- cylinders, the g-function is corrected to consider the cylindrical
- geometry. The correction factor is then the difference between the cylindrical
- heat source solution and the infinite line source solution, as proposed by
- Li et al. (2014) as
-
-
- g(t) = gFLS + (gCHS - gILS)
-
- Implementation
-
- The calculation of the g-function is separated into two regions: the
- short-time region and the long-time region. In the short-time region,
- corresponding to times t < 1 hour, heat interaction between boreholes
- and axial variations of heat injection rate are not considered. The
- g-function is calculated using only one borehole and one segment. In the
- long-time region, corresponding to times t > 1 hour, all boreholes
- are represented as series of nSeg line segments and the
- g-function is evaluated as described above.
-
- References
-
- Cimmino, M. and Bernier, M. 2014. A semi-analytical method to generate
- g-functions for geothermal bore fields. International Journal of Heat and
- Mass Transfer 70: 641-650.
-
-
- Cimmino, M. 2018. Fast calculation of the g-functions of geothermal borehole
- fields using similarities in the evaluation of the finite line source
- solution. Journal of Building Performance Simulation. DOI:
- 10.1080/19401493.2017.1423390.
-
-
- Eskilson, P. 1987. Thermal analysis of heat extraction boreholes. Ph.D.
- Thesis. Department of Mathematical Physics. University of Lund. Sweden.
-
-
- Li, M., Li, P., Chan, V. and Lai, A.C.K. 2014. Full-scale temperature
- response function (G-function) for heat transfer by borehole heat exchangers
- (GHEs) from sub-hour to decades. Applied Energy 136: 197-205.
-
-
-
- -
- March 22, 2018 by Massimo Cimmino:
- First implementation.
-
-
-
--------- Corrected Code --------
- This function implements the g-function evaluation method
- introduced by Cimmino and Bernier (see: Cimmino and Bernier (2014),
- and Cimmino (2018)) based on the g-function function concept
- first introduced by Eskilson (1987). The g-function gives the
- relation between the variation of the borehole wall temperature at a
- time t and the heat extraction and injection rates at all
- times preceding time t as
+Except for the mass flow rate sensor,
+all sensors with two ports can be
+configured as dynamic sensors or as steady-state sensor.
+The list below advices on how to configure sensors.
-
-
+
+-
+
+
+Sensors for quantities that depend on the direction of the mass flow rate but
+not of its magnitude:
+
+Such quantities include density, mass fraction, PPM, relative humidity, specific enthalpy, specific entropy and trace substances.
+Not that these are all quantities that are carried by the fluid that flows through the sensor.
+For these sensors, if the parameter allowFlowReversal=true is set (which is the default setting),
+then it is strongly recommended to configure them
+as a dynamic sensor. This is the default setting.
+Configuring a sensor as a dynamic sensor is done by setting the time constant to a non-zero
+value. Typically, setting tau=10 seconds yields good results.
+For tau=0, numerical problems may occur if the mass flow rate is close to zero
+and allowFlowReversal=true.
+If allowFlowReversal=false, then the measurement of these sensors only depends on properties
+at port_a.
+If the mass flow rate at port_a is ṁa ≤ 0,
+i.e., fluid flows from port_b to port_a,
+the model still assumes ṁa > 0. Hence there are no numerical problems;
+but use of the sensor output may yield wrong results.
+Therefore, only set allowFlowReversal=false if you can guarantee ṁa ≥ 0.
+
+-
- where Tb is the borehole wall temperature,
- Tg is the undisturbed ground temperature, Q
- is the heat injection rate into the ground through the borehole wall
- per unit borehole length, ks is the soil thermal
- conductivity and g is the g-function.
+
+Sensors for quantities that are the product of mass flow rate times a measured fluid property:
+
+Such quantities include volumentric flow rate or enthalpy flow rate.
+For these quantities, sensors are by default configured as steady-state sensor.
+These sensors may be configured by the user
+as a dynamic sensor by setting tau > 0, but there is typically no benefit as these sensors typically
+do not cause numerical problems.
+The reason is that these sensors multiply the quantity that is carried by the flow,
+such as specific enthalpy h by the mass flow rate ṁ
+to compute the measured signal Ḣ=ṁ h.
+Hence, as the mass flow rate goes to zero, the sensor output
+signal also goes to zero, which avoids numerical problems.
+
+-
- The g-function is constructed from the combination of the
- combination of the finite line source (FLS) solution (see
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.finiteLineSource),
- the cylindrical heat source (CHS) solution (see
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.cylindricalHeatSource),
- and the infinite line source (ILS) solution (see
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.infiniteLineSource).
- To obtain the g-function of a bore field, each borehole is
- divided into a series of nSeg segments of equal length,
- each modeled as a line source of finite length. The finite line
- source solution is superimposed in space to obtain a system of
- equations that gives the relation between the heat injection rate at
- each of the segments and the borehole wall temperature at each of the
- segments. The system is solved to obtain the uniform borehole wall
- temperature required at any time to maintain a constant total heat
- injection rate (Qtot =
- 2πksHtot) into the bore field. The uniform
- borehole wall temperature is then equal to the finite line source
- based g-function.
+Static pressure measurements:
+
+For static pressure measurements, sensors always output the instantaneous measurement.
+These sensors cannot be configured to be dynamic.
+
+
- Since this g-function is based on line sources of heat, rather
- than cylinders, the g-function is corrected to consider the
- cylindrical geometry. The correction factor is then the difference
- between the cylindrical heat source solution and the infinite line
- source solution, as proposed by Li et al. (2014) as
-
-
- g(t) = gFLS + (gCHS - gILS)
+The table below summarizes the recommendations for the use of sensors.
-
- Implementation
-
+
+| Measured quantity |
+ One port sensor |
+ Two port sensor |
+
|---|
+steady-state (tau=0) |
+ dynamic (tau > 0) |
+
+temperature
+ relative humidity
+ mass fraction
+ trace substances
+ specific enthalpy
+ specific entropy |
+ use only if connected to a volume |
+ avoid |
+ recommended |
+
+volume flow rate
+ enthalpy flow rate
+ entropy flow rate |
+ - |
+ recommended |
+ recommended |
+
+| pressure |
+ recommended |
+ recommended |
+ recommended |
+
+
+
+Sensor Dynamics
+Dynamic response to fluid flowing through the sensor
- The calculation of the g-function is separated into two
- regions: the short-time region and the long-time region. In the
- short-time region, corresponding to times t < 1 hour, heat
- interaction between boreholes and axial variations of heat injection
- rate are not considered. The g-function is calculated using
- only one borehole and one segment. In the long-time region,
- corresponding to times t > 1 hour, all boreholes are
- represented as series of nSeg line segments and the
- g-function is evaluated as described above.
+If a sensor is configured as a dynamic sensor by setting tau > 0,
+then the measured quantity, say the temperature T, is
+computed as
+
+
+ τ dT ⁄ dt = |ṁ| ⁄ ṁ0 (θ-T),
-
- References
-
- Cimmino, M. and Bernier, M. 2014. A semi-analytical method to
- generate g-functions for geothermal bore fields. International
- Journal of Heat and Mass Transfer 70: 641-650.
+where τ is a user-defined time constant of the sensor (a suggested value is around 10 seconds,
+which is the default setting for the components),
+dT ⁄ dt is the time derivative of the sensor output signal,
+|ṁ| is the absolute value of the mass flow rate,
+ṁ0 is the user-specified nominal value of the mass flow rate and
+θ is the temperature of the medium inside the sensor.
+An equivalent physical model of such a sensor would be a perfectly mixed volume
+with a sensor that outputs the temperature of this volume. In this situation, the size of the volume would
+be V=τ ṁ0 ⁄ ρ, where
+ρ is the density of the fluid.
+Dynamic response to ambient temperature
- Cimmino, M. 2018. Fast calculation of the g-functions of
- geothermal borehole fields using similarities in the evaluation of
- the finite line source solution. Journal of Building Performance
- Simulation. DOI: 10.1080/19401493.2017.1423390.
+For the sensor
+
+AixLib.Fluid.Sensors.TemperatureTwoPort,
+by setting transferHeat = true, heat transfer to a
+fixed ambient can be approximated. The heat transfer is computed as
+
+
+ τHeaTra dT ⁄ dt = (TAmb-T),
- Eskilson, P. 1987. Thermal analysis of heat extraction
- boreholes. Ph.D. Thesis. Department of Mathematical Physics.
- University of Lund. Sweden.
+where τHeaTra is a fixed time constant and
+TAmb is a fixed ambient temperature.
+Setting transferHeat = true is useful if the sensor output T
+is used to switch the mass flow rate on again. If transferHeat = false,
+then the sensor output T remains constant if the mass flow rate is zero
+and hence a fan or pump controller that uses this signal may never switch the device
+on again.
+If the sensor output T is not used to switch on the mass flow rate, then
+in general one can use transferHeat=false.
- Li, M., Li, P., Chan, V. and Lai, A.C.K. 2014. Full-scale
- temperature response function (G-function) for heat transfer by
- borehole heat exchangers (GHEs) from sub-hour to decades. Applied
- Energy 136: 197-205.
+Note that since in practice the heat transfer is due to a combination of ambient
+temperature and upstream or downstream fluid temperature, for example by two-way
+buoyancy-driven flow inside the duct or pipe, the model uses as an approximation
+a fixed ambient temperature.
+Since the sensor is not affecting the temperature of the medium, this approximation
+of the heat transfer does not add or remove heat from the fluid.
-
- - March 22, 2018 by Massimo Cimmino:
- First implementation.
-
-
-
--------- Errors --------
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
-line 49 column 2 - Warning:
attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/Movers/BaseClasses/Characteristics/efficiency.mo ----
--------- HTML Code --------
-
-
- This function computes the fan or pump efficiency for given normalized volume flow rate
- and performance data. The efficiency is
-
-
- η = s(V̇/rN, d),
-
-
- where
- η is the efficiency,
- rN is the normalized fan speed,
- V̇ is the volume flow rate, and
- d are performance data for fan or pump efficiency.
-
- Implementation
-
- The function s(·, ·) is a cubic hermite spline.
- If the data d define a monotone decreasing sequence, then
- s(·, d) is a monotone decreasing function.
-
-
-
- -
- December 2, 2016, by Michael Wetter:
- Removed min attribute as otherwise numerical noise can cause
- the assertion on the limit to fail.
- This is for
- #606.
-
- -
- November 22, 2014, by Michael Wetter:
- Corrected documentation as curve uses V̇
- as an independent variable.
-
- -
- September 30, 2014, by Filip Jorissen:
- Changed polynomial to be evaluated at V_flow
- instead of r_V.
-
- -
- April 19, 2014, by Filip Jorissen:
- Changed polynomial to be evaluated at r_V/r_N
- instead of r_V to properly account for the
- scaling law. See
- #202
- for a discussion and validation.
-
- -
- September 28, 2011, by Michael Wetter:
- First implementation.
-
-
-
--------- Corrected Code --------
+Combined dynamic response
- This function computes the fan or pump efficiency for given
- normalized volume flow rate and performance data. The efficiency is
+For the sensor
+
+AixLib.Fluid.Sensors.TemperatureTwoPort,
+if both dynamic effects are enabled, then
+the output T is computed as
- η = s(V̇/rN, d),
+dT ⁄ dt = |ṁ| ⁄ ṁ0 (θ-T) ⁄ τ +
+(TAmb-T) ⁄ τHeaTra.
+Implementation
- where η is the efficiency, rN is the
- normalized fan speed, V̇ is the volume flow rate, and d
- are performance data for fan or pump efficiency.
+The above equation is implemented in such a way that it is differentiable in the mass flow rate.
+
+
+Note that the implementation of the dynamic sensors does not use the model
+
+AixLib.Fluid.MixingVolumes.
+The reason is that depending on the selected medium model, the
+mixing volume may introduce states for the pressure, species concentration,
+trace substance, specific enthalpy and specific entropy. Not all states are typically needed to
+model the dynamics of a sensor. Moreover, in many building system applications,
+the sensor dynamics is not of concern, but is rather used here to avoid numerical
+problems that steady-state models of sensors cause when flow rates are
+very close to zero.
+
+
+-------- Corrected Code --------
+
+ This package contains models of sensors. There are models with one
+ and with two fluid ports.
- Implementation
+ Selection and parameterization of sensor models
- The function s(·, ·) is a cubic hermite spline. If the data
- d define a monotone decreasing sequence, then s(·, d)
- is a monotone decreasing function.
-
-
- - December 2, 2016, by Michael Wetter:
- Removed min attribute as otherwise numerical noise can
- cause the assertion on the limit to fail.
- This is for #606.
-
- - November 22, 2014, by Michael Wetter:
- Corrected documentation as curve uses V̇ as an independent
- variable.
-
- - September 30, 2014, by Filip Jorissen:
- Changed polynomial to be evaluated at V_flow instead
- of r_V.
-
- - April 19, 2014, by Filip Jorissen:
- Changed polynomial to be evaluated at r_V/r_N instead
- of r_V to properly account for the scaling law. See
- #202
- for a discussion and validation.
-
- - September 28, 2011, by Michael Wetter:
- First implementation.
-
-
-
--------- Errors --------
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/FixedResistances/PressureDrop.mo ----
--------- HTML Code --------
-
-
- Model of a flow resistance with a fixed flow coefficient.
- The mass flow rate is
-
-
- ṁ = k
- √ΔP,
-
-
- where
- k is a constant and
- ΔP is the pressure drop.
- The constant k is equal to
- k=m_flow_nominal/sqrt(dp_nominal),
- where m_flow_nominal and dp_nominal
- are parameters.
-
- Assumptions
-
- In the region
- abs(m_flow) < m_flow_turbulent,
- the square root is replaced by a differentiable function
- with finite slope.
- The value of m_flow_turbulent is
- computed as
- m_flow_turbulent = deltaM * abs(m_flow_nominal),
- where deltaM=0.3 and
- m_flow_nominal are parameters that can be set by the user.
-
-
- The figure below shows the pressure drop for the parameters
- m_flow_nominal=5 kg/s,
- dp_nominal=10 Pa and
- deltaM=0.3.
-
-
- ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/FixedResistances/PressureDrop.png\"/)
-
- Important parameters
-
- The parameter from_dp is used to determine
- whether the mass flow rate is computed as a function of the
- pressure drop (if from_dp=true), or vice versa.
- This setting can affect the size of the nonlinear system of equations.
-
-
- If the parameter linearized is set to true,
- then the pressure drop is computed as a linear function of the
- mass flow rate.
-
-
- Setting allowFlowReversal=false can lead to simpler
- equations. However, this should only be set to false
- if one can guarantee that the flow never reverses its direction.
- This can be difficult to guarantee, as pressure imbalance after
- the initialization, or due to medium expansion and contraction,
- can lead to reverse flow.
-
-
- If the parameter
- show_T is set to true,
- then the model will compute the
- temperature at its ports. Note that this can lead to state events
- when the mass flow rate approaches zero,
- which can increase computing time.
-
- Notes
-
- For more detailed models that compute the actual flow friction,
- models from the package
-
- Modelica.Fluid
- can be used and combined with models from the
- AixLib library.
-
-
- For a model that uses the hydraulic parameter and flow velocity at nominal conditions
- as a parameter, use
-
- AixLib.Fluid.FixedResistances.HydraulicDiameter.
-
- Implementation
-
- The pressure drop is computed by calling a function in the package
-
- AixLib.Fluid.BaseClasses.FlowModels,
- This package contains regularized implementations of the equation
-
-
- m = sign(Δp) k √ Δp
-
-
- and its inverse function.
-
-
- To decouple the energy equation from the mass equations,
- the pressure drop is a function of the mass flow rate,
- and not the volume flow rate.
- This leads to simpler equations.
-
-
-
- -
- September 21, 2018, by Michael Wetter:
- Decrease value of deltaM(min=...) attribute.
- See #1026.
-
- -
- February 3, 2018, by Filip Jorissen:
- Revised implementation of pressure drop equation
- such that it depends on from_dp
- when linearized=true.
- See #884.
-
- -
- December 1, 2016, by Michael Wetter:
- Simplified model by removing the geometry dependent parameters into the new
- model
-
- AixLib.Fluid.FixedResistances.HydraulicDiameter.
-
- -
- November 23, 2016, by Filip Jorissen:
- Removed dp_nominal and
- m_flow_nominal labels from icon.
-
- -
- October 14, 2016, by Michael Wetter:
- Updated comment for parameter use_dh.
-
- -
- November 26, 2014, by Michael Wetter:
- Added the required annotation(Evaluate=true) so
- that the system of nonlinear equations in
-
- AixLib.Fluid.FixedResistances.Validation.PressureDropsExplicit
- remains the same.
-
- -
- November 20, 2014, by Michael Wetter:
- Rewrote the warning message using an assert with
- AssertionLevel.warning
- as this is the proper way to write warnings in Modelica.
-
- -
- August 5, 2014, by Michael Wetter:
- Corrected error in documentation of computation of k.
-
- -
- May 29, 2014, by Michael Wetter:
- Removed undesirable annotation Evaluate=true.
-
- -
- October 8, 2013, by Michael Wetter:
- Removed parameter show_V_flow.
-
- -
- December 14, 2012 by Michael Wetter:
- Renamed protected parameters for consistency with the naming conventions.
-
- -
- January 16, 2012 by Michael Wetter:
- To simplify object inheritance tree, revised base classes
- AixLib.Fluid.BaseClasses.PartialResistance,
- AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve,
- AixLib.Fluid.Actuators.BaseClasses.PartialDamperExponential,
- AixLib.Fluid.Actuators.BaseClasses.PartialActuator
- and model
- AixLib.Fluid.FixedResistances.PressureDrop.
-
- -
- May 30, 2008 by Michael Wetter:
- Added parameters use_dh and deltaM for easier parameterization.
-
- -
- July 20, 2007 by Michael Wetter:
- First implementation.
-
-
-
--------- Corrected Code --------
-
- Model of a flow resistance with a fixed flow coefficient. The mass
- flow rate is
-
-
- ṁ = k √ΔP,
-
-
- where k is a constant and ΔP is the pressure drop. The
- constant k is equal to
- k=m_flow_nominal/sqrt(dp_nominal), where
- m_flow_nominal and dp_nominal are
- parameters.
-
-
- Assumptions
-
-
- In the region abs(m_flow) < m_flow_turbulent, the
- square root is replaced by a differentiable function with finite
- slope. The value of m_flow_turbulent is computed as
- m_flow_turbulent = deltaM * abs(m_flow_nominal), where
- deltaM=0.3 and m_flow_nominal are
- parameters that can be set by the user.
+ When selecting a sensor model, a distinction needs to be made whether
+ the measured quantity depends on the direction of the flow or not,
+ and whether the sensor output signal is the product of the mass flow
+ rate and a medium property.
- The figure below shows the pressure drop for the parameters
- m_flow_nominal=5 kg/s, dp_nominal=10 Pa and
- deltaM=0.3.
-
-
-
+ Output signals that depend on the flow direction and are not
+ multiplied by the mass flow rate are temperature, relative humidity,
+ water vapor concentration X, trace substances C and
+ density. For such quantities, sensors with two fluid ports need to be
+ used. An exception is if the quantity is measured directly in a fluid
+ volume, which is the case for models from the package AixLib.Fluid.MixingVolumes.
+ Therefore, to measure for example the outlet temperature of a heat
+ exchanger, the configuration labelled correct use in the
+ figure below should be used, and not the configuration labelled
+ not recommended. For an explanation, see
+ Modelica.Fluid.Examples.Explanatory.MeasuringTemperature.
-
- Important parameters
-
+
+
+ |
+ Correct use
+ |
+
+
+ |
+
+
+ |
+ Not recommended
+ |
+
+
+ |
+
+
- The parameter from_dp is used to determine whether the
- mass flow rate is computed as a function of the pressure drop (if
- from_dp=true), or vice versa. This setting can affect
- the size of the nonlinear system of equations.
+ Except for the mass flow rate sensor, all sensors with two ports can
+ be configured as dynamic sensors or as steady-state sensor. The list
+ below advices on how to configure sensors.
-
- If the parameter linearized is set to true,
- then the pressure drop is computed as a linear function of the mass
- flow rate.
+
+ -
+
+ Sensors for quantities that depend on the direction of the
+ mass flow rate but not of its magnitude: Such quantities
+ include density, mass fraction, PPM, relative humidity, specific
+ enthalpy, specific entropy and trace substances. Not that these
+ are all quantities that are carried by the fluid that flows
+ through the sensor. For these sensors, if the parameter
+ allowFlowReversal=true is set (which is the default
+ setting), then it is strongly recommended to configure them as a
+ dynamic sensor. This is the default setting.
+ Configuring a sensor as a dynamic sensor is done by setting the
+ time constant to a non-zero value. Typically, setting
+ tau=10 seconds yields good results. For
+ tau=0, numerical problems may occur if the mass flow
+ rate is close to zero and
+ allowFlowReversal=true.
+ If allowFlowReversal=false, then the measurement of
+ these sensors only depends on properties at port_a.
+ If the mass flow rate at port_a is ṁa
+ ≤ 0, i.e., fluid flows from port_b to
+ port_a, the model still assumes ṁa
+ > 0. Hence there are no numerical problems; but use of the
+ sensor output may yield wrong results. Therefore, only set
+ allowFlowReversal=false if you can guarantee
+ ṁa ≥ 0.
+
+
+ -
+
+ Sensors for quantities that are the product of mass flow rate
+ times a measured fluid property: Such quantities include
+ volumentric flow rate or enthalpy flow rate. For these
+ quantities, sensors are by default configured as steady-state
+ sensor. These sensors may be configured by the user as a dynamic
+ sensor by setting tau > 0, but there is typically
+ no benefit as these sensors typically do not cause numerical
+ problems. The reason is that these sensors multiply the quantity
+ that is carried by the flow, such as specific enthalpy h
+ by the mass flow rate ṁ to compute the measured signal
+ Ḣ=ṁ h. Hence, as the mass flow rate goes to zero, the
+ sensor output signal also goes to zero, which avoids numerical
+ problems.
+
+
+ -
+
+ Static pressure measurements: For static pressure
+ measurements, sensors always output the instantaneous
+ measurement. These sensors cannot be configured to be dynamic.
+
+
+
+
+ The table below summarizes the recommendations for the use of
+ sensors.
+
+
+
+ |
+ Measured quantity
+ |
+
+ One port sensor
+ |
+
+ Two port sensor
+ |
+
+
+
+ steady-state (tau=0)
+ |
+
+ dynamic (tau > 0)
+ |
+
+
+
+ temperature
+ relative humidity
+ mass fraction
+ trace substances
+ specific enthalpy
+ specific entropy
+ |
+
+ use only if connected to a volume
+ |
+
+ avoid
+ |
+
+ recommended
+ |
+
+
+
+ volume flow rate
+ enthalpy flow rate
+ entropy flow rate
+ |
+
+ -
+ |
+
+ recommended
+ |
+
+ recommended
+ |
+
+
+ |
+ pressure
+ |
+
+ recommended
+ |
+
+ recommended
+ |
+
+ recommended
+ |
+
+
+
+ Sensor Dynamics
+
+
+ Dynamic response to fluid flowing through the sensor
+
+
+ If a sensor is configured as a dynamic sensor by setting tau
+ > 0, then the measured quantity, say the temperature
+ T, is computed as
+
+
+ τ dT ⁄ dt = |ṁ| ⁄ ṁ0 (θ-T),
- Setting allowFlowReversal=false can lead to simpler
- equations. However, this should only be set to false if
- one can guarantee that the flow never reverses its direction. This
- can be difficult to guarantee, as pressure imbalance after the
- initialization, or due to medium expansion and contraction, can lead
- to reverse flow.
+ where τ is a user-defined time constant of the sensor (a
+ suggested value is around 10 seconds, which is the default setting
+ for the components), dT ⁄ dt is the time derivative of the
+ sensor output signal, |ṁ| is the absolute value of the mass
+ flow rate, ṁ0 is the user-specified nominal value
+ of the mass flow rate and θ is the temperature of the medium
+ inside the sensor. An equivalent physical model of such a sensor
+ would be a perfectly mixed volume with a sensor that outputs the
+ temperature of this volume. In this situation, the size of the volume
+ would be V=τ ṁ0 ⁄ ρ, where ρ is the
+ density of the fluid.
+
+ Dynamic response to ambient temperature
+
- If the parameter show_T is set to true,
- then the model will compute the temperature at its ports. Note that
- this can lead to state events when the mass flow rate approaches
- zero, which can increase computing time.
+ For the sensor AixLib.Fluid.Sensors.TemperatureTwoPort,
+ by setting transferHeat = true, heat transfer to a fixed
+ ambient can be approximated. The heat transfer is computed as
+
+
+ τHeaTra dT ⁄ dt = (TAmb-T),
-
- Notes
-
- For more detailed models that compute the actual flow friction,
- models from the package Modelica.Fluid can be used and
- combined with models from the AixLib library.
+ where τHeaTra is a fixed time constant and
+ TAmb is a fixed ambient temperature. Setting
+ transferHeat = true is useful if the sensor output
+ T is used to switch the mass flow rate on again. If
+ transferHeat = false, then the sensor output T
+ remains constant if the mass flow rate is zero and hence a fan or
+ pump controller that uses this signal may never switch the device on
+ again. If the sensor output T is not used to switch on the
+ mass flow rate, then in general one can use
+ transferHeat=false.
- For a model that uses the hydraulic parameter and flow velocity at
- nominal conditions as a parameter, use AixLib.Fluid.FixedResistances.HydraulicDiameter.
+ Note that since in practice the heat transfer is due to a combination
+ of ambient temperature and upstream or downstream fluid temperature,
+ for example by two-way buoyancy-driven flow inside the duct or pipe,
+ the model uses as an approximation a fixed ambient temperature. Since
+ the sensor is not affecting the temperature of the medium, this
+ approximation of the heat transfer does not add or remove heat from
+ the fluid.
-
- Implementation
-
+
+ Combined dynamic response
+
- The pressure drop is computed by calling a function in the package
- AixLib.Fluid.BaseClasses.FlowModels,
- This package contains regularized implementations of the equation
+ For the sensor AixLib.Fluid.Sensors.TemperatureTwoPort,
+ if both dynamic effects are enabled, then the output T is
+ computed as
- m = sign(Δp) k √ Δp
-
+ dT ⁄ dt = |ṁ| ⁄ ṁ0 (θ-T) ⁄ τ +
+ (TAmb-T) ⁄ τHeaTra.
+
+ Implementation
+
- and its inverse function.
+ The above equation is implemented in such a way that it is
+ differentiable in the mass flow rate.
- To decouple the energy equation from the mass equations, the pressure
- drop is a function of the mass flow rate, and not the volume flow
- rate. This leads to simpler equations.
+ Note that the implementation of the dynamic sensors does not use the
+ model AixLib.Fluid.MixingVolumes.
+ The reason is that depending on the selected medium model, the mixing
+ volume may introduce states for the pressure, species concentration,
+ trace substance, specific enthalpy and specific entropy. Not all
+ states are typically needed to model the dynamics of a sensor.
+ Moreover, in many building system applications, the sensor dynamics
+ is not of concern, but is rather used here to avoid numerical
+ problems that steady-state models of sensors cause when flow rates
+ are very close to zero.
-
- - September 21, 2018, by Michael Wetter:
- Decrease value of deltaM(min=...) attribute. See
- #1026.
-
- - February 3, 2018, by Filip Jorissen:
- Revised implementation of pressure drop equation such that it
- depends on from_dp when linearized=true.
- See #884.
-
- - December 1, 2016, by Michael Wetter:
- Simplified model by removing the geometry dependent parameters into
- the new model AixLib.Fluid.FixedResistances.HydraulicDiameter.
-
- - November 23, 2016, by Filip Jorissen:
- Removed dp_nominal and m_flow_nominal
- labels from icon.
-
- - October 14, 2016, by Michael Wetter:
- Updated comment for parameter use_dh.
-
- - November 26, 2014, by Michael Wetter:
- Added the required annotation(Evaluate=true) so that
- the system of nonlinear equations in
- AixLib.Fluid.FixedResistances.Validation.PressureDropsExplicit
- remains the same.
-
- - November 20, 2014, by Michael Wetter:
- Rewrote the warning message using an assert with
- AssertionLevel.warning as this is the proper way to
- write warnings in Modelica.
-
- - August 5, 2014, by Michael Wetter:
- Corrected error in documentation of computation of k.
-
- - May 29, 2014, by Michael Wetter:
- Removed undesirable annotation Evaluate=true.
-
- - October 8, 2013, by Michael Wetter:
- Removed parameter show_V_flow.
-
- - December 14, 2012 by Michael Wetter:
- Renamed protected parameters for consistency with the naming
- conventions.
-
- - January 16, 2012 by Michael Wetter:
- To simplify object inheritance tree, revised base classes
- AixLib.Fluid.BaseClasses.PartialResistance,
- AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve,
- AixLib.Fluid.Actuators.BaseClasses.PartialDamperExponential,
- AixLib.Fluid.Actuators.BaseClasses.PartialActuator and
- model AixLib.Fluid.FixedResistances.PressureDrop.
-
- - May 30, 2008 by Michael Wetter:
- Added parameters use_dh and deltaM for
- easier parameterization.
-
- - July 20, 2007 by Michael Wetter:
- First implementation.
-
-
-------- Errors --------
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
-line 37 column 2 - Warning:
attribute "align" not allowed for HTML5
-line 90 column 2 - Warning:
attribute "align" not allowed for HTML5
+line 32 column 1 - Warning: The summary attribute on the
element is obsolete in HTML5
+line 105 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+line 33 column 5 - Warning: | attribute "align" not allowed for HTML5
+line 38 column 5 - Warning: | attribute "align" not allowed for HTML5
+line 144 column 1 - Warning: attribute "align" not allowed for HTML5
+line 167 column 1 - Warning: attribute "align" not allowed for HTML5
+line 197 column 1 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Media/Antifreeze/EthyleneGlycolWater.mo ----
+---- AixLib/Fluid/HeatPumps/ScrollWaterToWater.mo ----
-------- HTML Code --------
-
- This base properties model is identical to
-
- Modelica.Media.Water.ConstantPropertyLiquidWater,
- except that the equation
- u = cv_const*(T - reference_T)
- has been replaced by u=h because
- cp_const=cv_const.
- Also, the model checks if the mass fraction of the mixture is within the
- allowed limits.
-
-
-
- Density of propylene antifreeze-water mixture at specified mass fraction
- and temperature, based on Melinder (2010).
-
- References
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
- Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
- IIR/IIF.
-
-
-
-
-
- Dynamic viscosity of antifreeze-water mixture at specified mass fraction and
- temperature, based on Melinder (2010).
-
- References
- Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
- Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
- IIR/IIF.
+ Model for a water to water heat pump with a scroll compressor, as described
+ in Jin (2002). The thermodynamic heat pump cycle is represented below.
-
-
-
-
- Fusion temperature of antifreeze-water mixture at specified mass fraction and
- temperature, based on Melinder (2010).
+
+
- References
- Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
- Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
- IIR/IIF.
+ The rate of heat transferred to the evaporator is given by:
-
-
-
-
- Evaluates a thermophysical property of a mixture, based on correlations proposed
- by Melinder (2010).
+
+ Q̇Eva = ṁref ( hVap(TEva) - hLiq(TCon) ).
- The polynomial has the form
+ The power consumed by the compressor is given by a linear efficiency relation:
- f = a1 (x-xm)0(y-ym)0
- + a2 (x-xm)0(y-ym)1
- + ... +
- any[1] (x-xm)0(y-ym)ny[1]-1
- + ... +
- any[1])+1 (x-xm)1(y-ym)0
- + ... +
- any[1]+ny[2] (x-xm)1(y-ym)ny[2]-1
- + ...
+ P = PTheoretical / η + PLoss,constant.
- References
- Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
- Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
- IIR/IIF.
+ Heat transfer in the evaporator and condenser is calculated using an
+ ε-NTU method, assuming constant refrigerant temperature and constant heat
+ transfer coefficient between fluid and refrigerant.
-
-
- -
- March 16, 2018 by Massimo Cimmino:
- First implementation.
- This function is used models in
-
- AixLib.Media.Antifreeze.
-
-
-
- Specific heat capacity of antifreeze-water mixture at specified mass fraction
- and temperature, based on Melinder (2010).
+ Variable speed is achieved by multiplying the full load suction volume flow rate
+ by the normalized compressor speed. The power and heat transfer rates are forced
+ to zero if the resulting heat pump state has higher evaporating pressure than
+ condensing pressure.
- References
- Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
- Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
- IIR/IIF.
+ The model parameters are obtained by calibration of the heat pump model to
+ manufacturer performance data. Calibrated model parameters for various heat
+ pumps from different manufacturers are found in
+
+ AixLib.Fluid.HeatPumps.Data.ScrollWaterToWater. The calibrated model is
+ located in
+
+ AixLib.Fluid.HeatPumps.Calibration.ScrollWaterToWater.
-
-
-
+ Options
- Thermal conductivity of antifreeze-water mixture at specified mass fraction and
- temperature, based on Melinder (2010).
+ Parameters TConMax and TEvaMin
+ may be used to set an upper or lower bound for the
+ condenser and evaporator.
+ The compressor is disabled when these conditions
+ are not satisfied, or when the
+ evaporator temperature is larger
+ than the condenser temperature.
+ This mimics the temperature protection
+ of heat pumps and moreover it avoids
+ non-converging algebraic loops of equations,
+ or freezing of evaporator medium.
+ This option can be disabled by setting
+ enable_temperature_protection = false.
+
+ Assumptions and limitations
+
+ The compression process is assumed isentropic. The thermal energy
+ of superheating is ignored in the evaluation of the heat transferred to the refrigerant
+ in the evaporator. There is no supercooling.
References
- Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
- Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
- IIR/IIF.
+ H. Jin.
+
+ Parameter estimation based models of water source heat pumps.
+
+ PhD Thesis. Oklahoma State University. Stillwater, Oklahoma, USA. 2002.
-
-
- This medium package models ethylene glycol - water mixtures.
-
-
- The mass density, specific heat capacity, thermal conductivity and viscosity
- are assumed constant and evaluated at a set temperature and mass fraction of
- ethylene glycol within the mixture. The dependence of the four properties
- are shown on the figure below.
-
-
- ![\"Relative](\"modelica://AixLib/Resources/Images/Media/Antifreeze/EthyleneGlycolWaterProperties.png\")
-
-
- The accuracy of the thermophysical properties is dependent on the temperature
- variations encountered during simulations.
- The figure below shows the relative error of the the four properties over a
- 10 °C range around the temperature used to evaluate the constant
- properties. The maximum errors are 0.8 % for mass density, 2.7 %
- for specific heat capacity, 3.2 % for thermal conductivity and 160
- % for dynamic viscosity.
-
-
- ![\"Relative](\"modelica://AixLib/Resources/Images/Media/Antifreeze/EthyleneGlycolWaterError10degC.png\")
-
-
- The figure below shows the relative error of the the four properties over a
- 20 °C range around the temperature used to evaluate the constant
- proepties. The maximum errors are 1.5 % for mass density, 5.3 %
- for specific heat capacity, 5.9 % for thermal conductivity and 500
- % for dynamic viscosity.
-
-
- ![\"Relative](\"modelica://AixLib/Resources/Images/Media/Antifreeze/EthyleneGlycolWaterError20degC.png\")
-
-
- The enthalpy is computed using the convention that h=0
- if T=0 °C.
-
- Limitations
-
- Density, specific heat capacity, thermal conductivity and viscosity are constant.
- The ethylene glycol/water mixture is modeled as an incompressible liquid.
- There are no phase changes. The medium is limited to temperatures below
- 100 °C and mass fractions below 0.60.
- As is the case for AixLib.Media.Water,
- this medium package should not be used if
- the simulation relies on the dynamic viscosity.
-
- Typical use and important parameters
-
- The temperature and mass fraction must be specified for the evaluation of the
- constant thermophysical properties. A typical use of the package is (e.g. for
- a temperature of 20 °C and a mass fraction of 0.40):
-
-
- Medium = AixLib.Media.Antifreeze.EthyleneGlycolWater(property_T=293.15, X_a=0.40)
-
-
-
- -
- August 05, 2020, by Wen HU:
+ May 30, 2017, by Filip Jorissen:
+ Revised documentation for temperature protection.
+ See #769.
+
+ -
+ November 11, 2016, by Massimo Cimmino:
First implementation.
-------- Corrected Code --------
- This base properties model is identical to Modelica.Media.Water.ConstantPropertyLiquidWater,
- except that the equation u = cv_const*(T - reference_T)
- has been replaced by u=h because
- cp_const=cv_const. Also, the model checks if the mass
- fraction of the mixture is within the allowed limits.
+ Model for a water to water heat pump with a scroll compressor, as
+ described in Jin (2002). The thermodynamic heat pump cycle is
+ represented below.
-
- Density of propylene antifreeze-water mixture at specified mass
- fraction and temperature, based on Melinder (2010).
+
+
-
- References
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids
- (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
- Indirect Systems. Paris: IIR/IIF.
+ The rate of heat transferred to the evaporator is given by:
-
-
- Dynamic viscosity of antifreeze-water mixture at specified mass
- fraction and temperature, based on Melinder (2010).
+
+ Q̇Eva = ṁref (
+ hVap(TEva) - hLiq(TCon)
+ ).
-
- References
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids
- (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
- Indirect Systems. Paris: IIR/IIF.
+ The power consumed by the compressor is given by a linear efficiency
+ relation:
-
-
- Fusion temperature of antifreeze-water mixture at specified mass
- fraction and temperature, based on Melinder (2010).
+
+ P = PTheoretical / η + PLoss,constant.
-
- References
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids
- (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
- Indirect Systems. Paris: IIR/IIF.
+ Heat transfer in the evaporator and condenser is calculated using an
+ ε-NTU method, assuming constant refrigerant temperature and constant
+ heat transfer coefficient between fluid and refrigerant.
-
- Evaluates a thermophysical property of a mixture, based on
- correlations proposed by Melinder (2010).
+ Variable speed is achieved by multiplying the full load suction
+ volume flow rate by the normalized compressor speed. The power and
+ heat transfer rates are forced to zero if the resulting heat pump
+ state has higher evaporating pressure than condensing pressure.
- The polynomial has the form
-
-
- f = a1 (x-xm)0(y-ym)0 +
- a2 (x-xm)0(y-ym)1 + ... +
- any[1] (x-xm)0(y-ym)ny[1]-1 + ... +
- any[1])+1 (x-xm)1(y-ym)0 + ... +
- any[1]+ny[2] (x-xm)1(y-ym)ny[2]-1 +
- ...
+ The model parameters are obtained by calibration of the heat pump
+ model to manufacturer performance data. Calibrated model parameters
+ for various heat pumps from different manufacturers are found in
+ AixLib.Fluid.HeatPumps.Data.ScrollWaterToWater.
+ The calibrated model is located in AixLib.Fluid.HeatPumps.Calibration.ScrollWaterToWater.
- References
+ Options
- Melinder, Åke. 2010. Properties of Secondary Working Fluids
- (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
- Indirect Systems. Paris: IIR/IIF.
+ Parameters TConMax and TEvaMin may be used
+ to set an upper or lower bound for the condenser and evaporator. The
+ compressor is disabled when these conditions are not satisfied, or
+ when the evaporator temperature is larger than the condenser
+ temperature. This mimics the temperature protection of heat pumps and
+ moreover it avoids non-converging algebraic loops of equations, or
+ freezing of evaporator medium. This option can be disabled by setting
+ enable_temperature_protection = false.
-
- - March 16, 2018 by Massimo Cimmino:
- First implementation. This function is used models in AixLib.Media.Antifreeze.
-
-
+
+ Assumptions and limitations
+
- Specific heat capacity of antifreeze-water mixture at specified mass
- fraction and temperature, based on Melinder (2010).
+ The compression process is assumed isentropic. The thermal energy of
+ superheating is ignored in the evaluation of the heat transferred to
+ the refrigerant in the evaporator. There is no supercooling.
References
- Melinder, Åke. 2010. Properties of Secondary Working Fluids
- (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
- Indirect Systems. Paris: IIR/IIF.
+ H. Jin. Parameter estimation based models of water source heat
+ pumps. PhD Thesis. Oklahoma State University. Stillwater,
+ Oklahoma, USA. 2002.
- - March 16, 2018 by Massimo Cimmino:
- First implementation. This function is used by AixLib.Media.Antifreeze.EthyleneGlycolWater.
+ - May 30, 2017, by Filip Jorissen:
+ Revised documentation for temperature protection. See #769.
+
+ - November 11, 2016, by Massimo Cimmino:
+ First implementation.
-
- Thermal conductivity of antifreeze-water mixture at specified mass
- fraction and temperature, based on Melinder (2010).
-
-
- References
-
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids
- (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
- Indirect Systems. Paris: IIR/IIF.
-
+
+-------- Errors --------
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+line 18 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/HeatExchangers/BaseClasses/WetCoilDryWetRegime.mo ----
+-------- HTML Code --------
+
+
+ -
+ Jan 21, 2021, by Donghun Kim:
First implementation.
+
+
+
+
+ This model implements the switching algorithm for the dry and wet regime.
+
+
+ The switching criteria for (counter-flow) cooling coil modes are as follows.
+
+ R1: If the coil surface temperature at the air inlet is lower than the dew-point
+ temperature at the inlet to the coil, then the cooling coil surface is fully-wet.
+
+ R2: If the surface temperature at the air outlet section is higher than
+ the dew-point temperature of the air at the inlet, then the cooling coil surface is fully-dry.
+
+ At each point of a simulation time step, the fuzzy-modeling approach determines
+ the weights for R1 and R2 respectively (namely μFW and μFD)
+ from the dew-point and coil surface temperatures.
+
+ It calculates total and sensible heat transfer rates according to the weights as follows.
+
+
+ Q̇tot=μFD Q̇tot,FD+μFW Qtot,FW
+
+
+ Q̇sen=μFD Q̇sen,FD+μFW Qsen,FW
+
+
+ The fuzzy-modeling ensures μFW + μFD = 1,
+ μFW >=0 and μFD >=0, which means the fuzzy
+ model outcomes of Q̇sen and Q̇tot are always convex combinations of heat transfer
+ rates for fully-dry and fully-wet modes and therefore are always bounded by them.
+
+
+ The modeling approach also results in n-th order differentiable model
+ depending on the selection of the underlying membership functions. This cooling
+ coil model is once continuously differentiable at the mode switches.
+
+
+-------- Corrected Code --------
- This medium package models ethylene glycol - water mixtures.
+ This model implements the switching algorithm for the dry and wet
+ regime.
- The mass density, specific heat capacity, thermal conductivity and
- viscosity are assumed constant and evaluated at a set temperature and
- mass fraction of ethylene glycol within the mixture. The dependence
- of the four properties are shown on the figure below.
-
-
-
+ The switching criteria for (counter-flow) cooling coil modes are as
+ follows.
- The accuracy of the thermophysical properties is dependent on the
- temperature variations encountered during simulations. The figure
- below shows the relative error of the the four properties over a
- 10 °C range around the temperature used to evaluate the
- constant properties. The maximum errors are 0.8 % for mass
- density, 2.7 % for specific heat capacity, 3.2 % for
- thermal conductivity and 160 % for dynamic viscosity.
-
-
-
+ R1: If the coil surface temperature at the air inlet is lower than
+ the dew-point temperature at the inlet to the coil, then the cooling
+ coil surface is fully-wet.
- The figure below shows the relative error of the the four properties
- over a 20 °C range around the temperature used to evaluate the
- constant proepties. The maximum errors are 1.5 % for mass
- density, 5.3 % for specific heat capacity, 5.9 % for
- thermal conductivity and 500 % for dynamic viscosity.
-
-
-
+ R2: If the surface temperature at the air outlet section is higher
+ than the dew-point temperature of the air at the inlet, then the
+ cooling coil surface is fully-dry.
- The enthalpy is computed using the convention that h=0 if
- T=0 °C.
+ At each point of a simulation time step, the fuzzy-modeling approach
+ determines the weights for R1 and R2 respectively (namely
+ μFW and μFD) from the dew-point
+ and coil surface temperatures.
-
- Limitations
-
- Density, specific heat capacity, thermal conductivity and viscosity
- are constant. The ethylene glycol/water mixture is modeled as an
- incompressible liquid. There are no phase changes. The medium is
- limited to temperatures below 100 °C and mass fractions below
- 0.60. As is the case for AixLib.Media.Water, this medium
- package should not be used if the simulation relies on the dynamic
- viscosity.
+ It calculates total and sensible heat transfer rates according to the
+ weights as follows.
+
+
+ Q̇tot=μFD Q̇tot,FD+μFW
+ Qtot,FW
+
+
+ Q̇sen=μFD Q̇sen,FD+μFW
+ Qsen,FW
-
- Typical use and important parameters
-
- The temperature and mass fraction must be specified for the
- evaluation of the constant thermophysical properties. A typical use
- of the package is (e.g. for a temperature of 20 °C and a mass
- fraction of 0.40):
+ The fuzzy-modeling ensures μFW + μFD =
+ 1, μFW >=0 and μFD >=0,
+ which means the fuzzy model outcomes of Q̇sen and
+ Q̇tot are always convex combinations of heat
+ transfer rates for fully-dry and fully-wet modes and therefore are
+ always bounded by them.
- Medium =
- AixLib.Media.Antifreeze.EthyleneGlycolWater(property_T=293.15,
- X_a=0.40)
+ The modeling approach also results in n-th order
+ differentiable model depending on the selection of the underlying
+ membership functions. This cooling coil model is once continuously
+ differentiable at the mode switches.
-
- - August 05, 2020, by Wen HU:
- First implementation.
-
-
-------- Errors --------
-line 9 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
-line 11 column 2 - Warning: attribute "align" not allowed for HTML5
-line 24 column 2 - Warning: attribute "align" not allowed for HTML5
-line 35 column 2 - Warning: attribute "align" not allowed for HTML5
+line 20 column 2 - Warning: attribute "align" not allowed for HTML5
+line 23 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/ThermalZones/ReducedOrder/RC/OneElement.mo ----
+---- AixLib/Fluid/Movers/Validation/PowerExact.mo ----
-------- HTML Code --------
- This model merges all thermal masses into one
- element, parameterized by the length of the RC-chain
- nExt, the vector of the capacities CExt[nExt] that is
- connected via the vector of resistances RExt[nExt] and
- RExtRem to the ambient and indoor air.
- By default, the model neglects all
- internal thermal masses that are not directly connected to the ambient.
- However, the thermal capacity of the room air can be increased by
- using the parameter mSenFac.
-
-
- The image below shows the RC-network of this model.
+ This example is identical to
+
+ AixLib.Fluid.Movers.Validation.PowerSimplified, except that the
+ performance data for the flow controlled pumps
+ pump_dp and pump_m_flow contain
+ the pressure curves and efficiency curves.
+ The plot below shows that this leads to a computation of the power consumption
+ that is identical to the one from the speed controlled pump pump_Nrpm.
-
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Movers/Validation/PowerExact.png\"/)
-
+
-
- March 7, 2022, by Michael Wetter:
- Removed massDynamics.
- This is for
- #1542.
+ October 15, 2021, by Hongxiang Fu:
+ Fixed the image in the documentation which was cut off
+ at the y-axis. This is for
+ IBPSA, #1533.
-
- October 9, 2019, by Michael Wetter:
- Refactored addition of moisture to also account for the energy content of the
- water vapor.
- This is for IBPSA, issue 1209.
+ March 2, 2016, by Filip Jorissen:
+ First implementation for
+ #417.
- -
- September 24, 2019, by Martin Kremer:
- Added possibility to consider moisture balance.
- Defined volAir conditional. Added conditional volMoistAir and corresponding in- and output connectors.
-
- -
- July 11, 2019, by Katharina Brinkmann:
- Renamed alphaRad to hRad,
- alphaWin to hConWin,
- alphaExt to hConExt,
- alphaExtWallConst to hConExtWall_const,
- alphaWinConst to hConWin_const
-
- -
- January 25, 2019, by Michael Wetter:
- Added start value to avoid warning in JModelica.
-
- -
- September 26, 2016, by Moritz Lauster:
- Added conditional statements to solar radiation part.
- Deleted conditional statements of
- splitFactor and splitFactorSolRad.
-
- -
- April 17, 2015, by Moritz Lauster:
- First implementation.
-
-------- Corrected Code --------
- This model merges all thermal masses into one element, parameterized
- by the length of the RC-chain nExt, the vector of the
- capacities CExt[nExt] that is connected via the vector
- of resistances RExt[nExt] and RExtRem to
- the ambient and indoor air. By default, the model neglects all
- internal thermal masses that are not directly connected to the
- ambient. However, the thermal capacity of the room air can be
- increased by using the parameter mSenFac.
-
-
- The image below shows the RC-network of this model.
+ This example is identical to AixLib.Fluid.Movers.Validation.PowerSimplified,
+ except that the performance data for the flow controlled pumps
+ pump_dp and pump_m_flow contain the
+ pressure curves and efficiency curves. The plot below shows that this
+ leads to a computation of the power consumption that is identical to
+ the one from the speed controlled pump pump_Nrpm.
-
+
- - March 7, 2022, by Michael Wetter:
- Removed massDynamics.
- This is for #1542.
-
- - October 9, 2019, by Michael Wetter:
- Refactored addition of moisture to also account for the energy
- content of the water vapor.
- This is for IBPSA, issue
- 1209.
-
- - September 24, 2019, by Martin Kremer:
- Added possibility to consider moisture balance.
- Defined volAir conditional. Added conditional
- volMoistAir and corresponding in- and output
- connectors.
-
- - July 11, 2019, by Katharina Brinkmann:
- Renamed alphaRad to hRad,
- alphaWin to hConWin,
- alphaExt to hConExt,
- alphaExtWallConst to hConExtWall_const,
- alphaWinConst to hConWin_const
-
- - January 25, 2019, by Michael Wetter:
- Added start value to avoid warning in JModelica.
-
- - September 26, 2016, by Moritz Lauster:
- Added conditional statements to solar radiation part.
- Deleted conditional statements of splitFactor and
- splitFactorSolRad.
+ - October 15, 2021, by Hongxiang Fu:
+ Fixed the image in the documentation which was cut off at the
+ y-axis. This is for IBPSA,
+ #1533.
- - April 17, 2015, by Moritz Lauster:
- First implementation.
+ - March 2, 2016, by Filip Jorissen:
+ First implementation for #417.
-------- Errors --------
-line 16 column 2 - Warning: attribute "align" not allowed for HTML5
+line 12 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/timeGeometric.mo ----
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/Boreholes/BaseClasses/Functions/convectionResistanceCircularPipe.mo ----
-------- HTML Code --------
- This function attemps to build a vector of length nTim with a geometric
- expansion of the time variable between dt and t_max.
+ This model computes the convection resistance in the pipes of a borehole segment
+ with heigth hSeg using correlations suggested by Bergman et al. (2011).
- If t_max > nTim*dt, then a geometrically expanding vector is built as
+ If the flow is laminar (Re ≤ 2300, with Re being the Reynolds number of the flow),
+ the Nusselt number of the flow is assumed to be constant at 3.66. If the flow is turbulent (Re > 2300),
+ the correlation of Dittus-Boelter is used to find the convection heat transfer coefficient as
-
- t = [dt, dt*(1-r2)/(1-r), ... , dt*(1-rn)/(1-r), ... , tmax],
+
+ Nu = 0.023 Re0.8 Prn,
- where r is the geometric expansion factor.
-
-
- If t_max < nTim*dt, then a linearly expanding vector is built as
+ where Nu is the Nusselt number and
+ Pr is the Prandlt number.
+ A value of n=0.35 is used, as the reference uses n=0.4 for heating and
+ n=0.3 for cooling. To ensure that the function is continuously differentiable,
+ a smooth transition between the laminar and turbulent values is created for the
+ range 2300 < Re < 2400.
-
- t = [dt, 2*dt, ... , n*dt, ... , nTim*dt]
+ References
+
+ Bergman, T. L., Incropera, F. P., DeWitt, D. P., & Lavine, A. S. (2011). Fundamentals of heat and mass
+ transfer (7th ed.). New York: John Wiley & Sons.
-
- June 28, 2018 by Massimo Cimmino:
+ July 10, 2018, by Alex Laferrière:
+ Added laminar flow and smooth laminar-turbulent transition.
+ Revised documentation.
+
+ -
+ February 14, 2014, by Michael Wetter:
+ Removed unused input rBor.
+ Revised documentation.
+
+ -
+ January 24, 2014, by Michael Wetter:
+ Revised implementation.
+ Changed cpFluid to cpMed to use consistent notation.
+ Added regularization for computation of convective heat transfer coefficient to
+ avoid an event and a non-differentiability.
+
+ -
+ January 23, 2014, by Damien Picard:
First implementation.
-------- Corrected Code --------
- This function attemps to build a vector of length nTim
- with a geometric expansion of the time variable between
- dt and t_max.
+ This model computes the convection resistance in the pipes of a
+ borehole segment with heigth hSeg using
+ correlations suggested by Bergman et al. (2011).
- If t_max > nTim*dt, then a geometrically expanding
- vector is built as
+ If the flow is laminar (Re ≤ 2300, with Re being the
+ Reynolds number of the flow), the Nusselt number of the flow is
+ assumed to be constant at 3.66. If the flow is turbulent (Re >
+ 2300), the correlation of Dittus-Boelter is used to find the
+ convection heat transfer coefficient as
-
- t = [dt, dt*(1-r2)/(1-r), ... ,
- dt*(1-rn)/(1-r), ... , tmax],
+
+ Nu = 0.023 Re0.8 Prn,
- where r is the geometric expansion factor.
+ where Nu is the Nusselt number and Pr is the Prandlt
+ number. A value of n=0.35 is used, as the reference uses
+ n=0.4 for heating and n=0.3 for cooling. To ensure that
+ the function is continuously differentiable, a smooth transition
+ between the laminar and turbulent values is created for the range
+ 2300 < Re < 2400.
+
+ References
+
- If t_max < nTim*dt, then a linearly expanding vector
- is built as
+ Bergman, T. L., Incropera, F. P., DeWitt, D. P., & Lavine, A. S.
+ (2011). Fundamentals of heat and mass transfer (7th ed.). New
+ York: John Wiley & Sons.
+
+
+ - July 10, 2018, by Alex Laferrière:
+ Added laminar flow and smooth laminar-turbulent transition. Revised
+ documentation.
+
+ - February 14, 2014, by Michael Wetter:
+ Removed unused input rBor. Revised documentation.
+
+ - January 24, 2014, by Michael Wetter:
+ Revised implementation. Changed cpFluid to
+ cpMed to use consistent notation. Added regularization
+ for computation of convective heat transfer coefficient to avoid an
+ event and a non-differentiability.
+
+ - January 23, 2014, by Damien Picard:
+ First implementation.
+
+
+
+-------- Errors --------
+line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Controls/SetPoints/Examples/OccupancySchedule.mo ----
+-------- HTML Code --------
+
+
+ Example that demonstrates the use of the occupancy schedule.
+ The figure below shows how the time until the next occupancy starts or ends
+ is decreased. The red line hits zero when the schedule indicates an occupied time,
+ and the blue line hits zero when the schedule indicates a non-occupied time.
+
+
+ ![\"Time](\"modelica://AixLib/Resources/Images/Controls/SetPoints/Examples/OccupancySchedule.png\")
+
+
+
+ -
+ November 21, 2011, by Michael Wetter:
+ Added documentation.
+
+
+
+-------- Corrected Code --------
+
+ Example that demonstrates the use of the occupancy schedule. The
+ figure below shows how the time until the next occupancy starts or
+ ends is decreased. The red line hits zero when the schedule indicates
+ an occupied time, and the blue line hits zero when the schedule
+ indicates a non-occupied time.
- t = [dt, 2*dt, ... , n*dt, ... , nTim*dt]
+
- - June 28, 2018 by Massimo Cimmino:
- First implementation.
+ - November 21, 2011, by Michael Wetter:
+ Added documentation.
-------- Errors --------
-line 9 column 2 - Warning: attribute "align" not allowed for HTML5
-line 18 column 2 - Warning: attribute "align" not allowed for HTML5
+line 8 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/ThermalZones/ReducedOrder/RC/FourElements.mo ----
+-------- HTML Code --------
+
+
+ -
+ March 7, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for
+ #1542.
+
+ -
+ December 9, 2019, by Moritz Lauster:
+ Changes nExt to nRoof for
+ RRoof and CRoof
+
+ -
+ July 11, 2019, by Katharina Brinkmann:
+ Renamed alphaRoof to hConRoof,
+ alphaRoofConst to hConRoof_const
+
+ -
+ August 31, 2018 by Moritz Lauster:
+ Updated schema in documentation and fixes
+ orientation and connections of roofRC for
+
+ issue 997.
+
+ -
+ September 11, 2015 by Moritz Lauster:
+ First Implementation.
+
+
+
+
+ This model adds another element for the roof. Roofs commonly
+ exhibit the same excitations as exterior walls but have different coefficients
+ of heat transfer due to their orientation. Adding an extra element for the roof
+ might lead to a finer resolution of the dynamic behaviour but increases
+ calculation times. The roof is parameterized via the length of the RC-chain
+ nRoof,
+ the vector of capacities CRoof[nRoof], the vector of resistances
+ RRoof[nRoof] and remaining resistances RRoofRem.
+
+
+ The image below shows the RC-network of this model.
+
+
+
+
+
+-------- Corrected Code --------
+
+ - March 7, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for #1542.
+
+ - December 9, 2019, by Moritz Lauster:
+ Changes nExt to nRoof for
+ RRoof and CRoof
+
+ - July 11, 2019, by Katharina Brinkmann:
+ Renamed alphaRoof to hConRoof,
+ alphaRoofConst to hConRoof_const
+
+ - August 31, 2018 by Moritz Lauster:
+ Updated schema in documentation and fixes orientation and
+ connections of roofRC for issue 997.
+
+ - September 11, 2015 by Moritz Lauster:
+ First Implementation.
+
+
+
+ This model adds another element for the roof. Roofs commonly exhibit
+ the same excitations as exterior walls but have different
+ coefficients of heat transfer due to their orientation. Adding an
+ extra element for the roof might lead to a finer resolution of the
+ dynamic behaviour but increases calculation times. The roof is
+ parameterized via the length of the RC-chain nRoof, the
+ vector of capacities CRoof[nRoof], the vector of
+ resistances RRoof[nRoof] and remaining resistances
+ RRoofRem.
+
+
+ The image below shows the RC-network of this model.
+
+
+
+
+
+-------- Errors --------
+line 15 column 4 - Warning: attribute "align" not allowed for HTML5
---- AixLib/Fluid/Chillers/Carnot_TEva.mo ----
@@ -11587,10320 +10541,8360 @@ line 29 column 2 - Warning: attribute "align" not allowed for HTML5
line 39 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/CheckValve.mo ----
+---- AixLib/Utilities/Math/Functions/polynomial.mo ----
-------- HTML Code --------
-
- Implementation of a hydraulic check valve.
- Note that the small reverse flows can still occur with this model.
-
- Main equations
-
- The basic flow function
-
-
- m = sign(Δp) k √ Δp ,
-
-
- with regularization near the origin, is used to compute the pressure drop.
- The flow coefficient
-
+ This function computes a polynomial of arbitrary order.
+ The polynomial has the form
- k = m ⁄ √ Δp
-
-
- is increased from l*KV_Si to KV_Si,
- where KV_Si is equal to Kv but in SI units.
- Therefore, the flow coefficient k is set to a value close to zero for negative pressure differences, thereby
- restricting reverse flow to a small value.
- The flow coefficient k saturates to its maximum value at the pressure dpValve_closing.
- For larger pressure drops, the pressure drop is a quadratic function of the flow rate.
-
- Typical use and important parameters
-
- The parameters m_flow_nominal and dpValve_nominal
- determine the flow coefficient of the check valve when it is fully opened.
- A typical value for a nominal flow rate of 1 m/s is
- dpValve_nominal = 3400 Pa.
- The leakage ratio l determines the minimum flow coefficient,
- for negative pressure differences.
- The parameter dpFixed_nominal allows to include a series
- pressure drop with a fixed flow coefficient into the model.
- The parameter dpValve_closing determines when the
- flow coefficient starts to increase,
- which is typically in the order of dpValve_nominal.
-
- Implementation
-
- The check valve implementation approximates the physics
- where a forward pressure difference opens the valve such that
- the valve opening increases, causing a growing orifice area
- and thus increasing the flow coefficient.
- Near dp=dpValve_closing, the valve is fully open and the flow coefficient saturates
- to the flow coefficient value determined by dpValve_nominal and m_flow_nominal.
- For typical valve diameters, the check valve is only fully open
- near nominal mass flow rate. Therefore, the model sets dpValve_closing=dpValve_nominal/2
- by default.
-
-
-
- -
- September 16, 2019, by Kristoff Six and Filip Jorissen:
- Implementation of a hydraulic check valve. This is for
- issue 1198.
-
-
-
--------- Corrected Code --------
-
- Implementation of a hydraulic check valve. Note that the small
- reverse flows can still occur with this model.
-
-
- Main equations
-
-
- The basic flow function
-
-
- m = sign(Δp) k √ Δp
- ,
-
-
- with regularization near the origin, is used to compute the pressure
- drop. The flow coefficient
-
-
- k = m ⁄ √ Δp
-
-
-
- is increased from l*KV_Si to KV_Si, where
- KV_Si is equal to Kv but in SI units.
- Therefore, the flow coefficient k is set to a value
- close to zero for negative pressure differences, thereby restricting
- reverse flow to a small value. The flow coefficient k
- saturates to its maximum value at the pressure
- dpValve_closing. For larger pressure drops, the pressure
- drop is a quadratic function of the flow rate.
-
-
- Typical use and important parameters
-
-
- The parameters m_flow_nominal and
- dpValve_nominal determine the flow coefficient of the
- check valve when it is fully opened. A typical value for a nominal
- flow rate of 1 m/s is dpValve_nominal = 3400 Pa.
- The leakage ratio l determines the minimum flow
- coefficient, for negative pressure differences. The parameter
- dpFixed_nominal allows to include a series pressure drop
- with a fixed flow coefficient into the model. The parameter
- dpValve_closing determines when the flow coefficient
- starts to increase, which is typically in the order of
- dpValve_nominal.
-
-
- Implementation
-
-
- The check valve implementation approximates the physics where a
- forward pressure difference opens the valve such that the valve
- opening increases, causing a growing orifice area and thus increasing
- the flow coefficient. Near dp=dpValve_closing, the valve
- is fully open and the flow coefficient saturates to the flow
- coefficient value determined by dpValve_nominal and
- m_flow_nominal. For typical valve diameters, the check
- valve is only fully open near nominal mass flow rate. Therefore, the
- model sets dpValve_closing=dpValve_nominal/2 by default.
-
-
- - September 16, 2019, by Kristoff Six and Filip Jorissen:
- Implementation of a hydraulic check valve. This is for issue
- 1198.
-
-
-
--------- Errors --------
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
-line 17 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/FixedResistances/BaseClasses/PlugFlowTransportDelay.mo ----
--------- HTML Code --------
-
-
- Calculates time delay at both sides of the pipe as the difference between the
- current simulation time and the inlet time of the fluid at both ends of the pipe.
-
- Main equation
-
- ∂z(x,t)/∂t + v(t) ∂z(x,t)/∂x = 0,
-
-
- where z(x,t) is the spatial distribution as a function of time of any
- property z of the fluid. For the inlet time propagation, z will
- be replaced by the inlet time of the fluid tin.
-
- Implementation
-
- The inlet time is approached as a fluid property and its propagation follows
- the one-dimensional wave equation, implemented using the spatialDistribution
- function. This components requires the mass flow through the pipe and the pipe
- dimensions in order to derive information about the fluid propagation.
-
-
- The component calculates the delay time at the inlet and the outlet port of the pipe.
- For the forward flow, the time delay is exposed at the output tau,
- and for the backward flow, the time delay is exposed at the output tauRev.
-
- Assumption
-
- No axial mixing takes place in the pipe.
+ y = a1 + a2 x + a3 x2 + ...
-
- December 2, 2020, by Philipp Mehrfeld:
- Corrected calculation of tau and tauRev to be be
- only positive.
- This is for
- #1427.
-
- -
- December 14, 2018, by Michael Wetter:
- Corrected argument of spatialDistribution operator to be a parameter
- expression.
+ December 14, 2016, by Michael Wetter:
+ Removed derivative annotation.
This is for
- #1055.
-
- -
- September 9, 2016 by Bram van der Heijde:
- Rename from PDETime_massFlowMod to PlugFlowTransportDelayMod
-
- -
- December 2015 by Carles Ribas Tugores:
- Modification in delay calculation to fix issues.
+ issue 602.
-
- November 6, 2015 by Bram van der Heijde:
- Adapted flow parameter to mass flow rate instead of velocity.
- This change should also fix the reverse and zero flow issues.
+ March 30, 2011, by Michael Wetter:
+ Added zeroDerivative keyword.
-
- October 13, 2015 by Marcus Fuchs:
- Use abs() of normalized velocity input in order to avoid negative
- delay times.
+ March 2, by Michael Wetter:
+ Removed redundant smoothOrder annotation.
-
- July 2015 by Arnout Aertgeerts:
+ February 29, 2009 by Michael Wetter:
First implementation.
-------- Corrected Code --------
-
- Calculates time delay at both sides of the pipe as the difference
- between the current simulation time and the inlet time of the fluid
- at both ends of the pipe.
-
-
- Main equation
-
-
- ∂z(x,t)/∂t + v(t) ∂z(x,t)/∂x = 0,
-
-
- where z(x,t) is the spatial distribution as a function of time
- of any property z of the fluid. For the inlet time
- propagation, z will be replaced by the inlet time of the fluid
- tin.
-
-
- Implementation
-
-
- The inlet time is approached as a fluid property and its propagation
- follows the one-dimensional wave equation, implemented using the
- spatialDistribution function. This components requires the mass flow
- through the pipe and the pipe dimensions in order to derive
- information about the fluid propagation.
-
-
- The component calculates the delay time at the inlet and the outlet
- port of the pipe. For the forward flow, the time delay is exposed at
- the output tau, and for the backward flow, the time
- delay is exposed at the output tauRev.
-
-
- Assumption
-
-
- No axial mixing takes place in the pipe.
+This function computes a polynomial of arbitrary order. The polynomial
+has the form
+
+ y = a1 + a2 x + a3 x2 +
+ ...
- - December 2, 2020, by Philipp Mehrfeld:
- Corrected calculation of tau and tauRev
- to be be only positive.
- This is for #1427.
-
- - December 14, 2018, by Michael Wetter:
- Corrected argument of spatialDistribution operator to
- be a parameter expression.
+ - December 14, 2016, by Michael Wetter:
+ Removed derivative annotation.
This is for #1055.
-
- - September 9, 2016 by Bram van der Heijde:
- Rename from PDETime_massFlowMod to PlugFlowTransportDelayMod
-
- - December 2015 by Carles Ribas Tugores:
- Modification in delay calculation to fix issues.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/602\">issue 602.
- - November 6, 2015 by Bram van der Heijde:
- Adapted flow parameter to mass flow rate instead of velocity. This
- change should also fix the reverse and zero flow issues.
+ - March 30, 2011, by Michael Wetter:
+ Added zeroDerivative keyword.
- - October 13, 2015 by Marcus Fuchs:
- Use abs() of normalized velocity input in order to
- avoid negative delay times.
+ - March 2, by Michael Wetter:
+ Removed redundant smoothOrder annotation.
- - July 2015 by Arnout Aertgeerts:
+ - February 29, 2009 by Michael Wetter:
First implementation.
-------- Errors --------
-line 7 column 2 - Warning: attribute "align" not allowed for HTML5
+line 4 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/cylindricalHeatSource.mo ----
+---- AixLib/ThermalZones/ReducedOrder/RC/BaseClasses/InteriorWall.mo ----
-------- HTML Code --------
-
- This function evaluates the cylindrical heat source solution. This solution
- gives the relation between the constant heat transfer rate (per unit length)
- injected by a cylindrical heat source of infinite length and the temperature
- raise in the medium. The cylindrical heat source solution is defined by
-
-
- ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/CylindricalHeatSource_01.png\")
-
-
- where ΔT(t,r) is the temperature raise after a time t of
- constant heat injection and at a distance r from the cylindrical source,
- Q' is the heat injection rate per unit length, ks is
- the soil thermal conductivity, Fo is the Fourier number,
- aSois is the ground thermal diffusivity,
- rb is the radius of the cylindrical source and G
- is the cylindrical heat source solution.
-
-
- The cylindrical heat source solution is given by:
-
-
- ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/CylindricalHeatSource_02.png\")
-
-
- The integral is solved numerically, with the integrand defined in
-
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.cylindricalHeatSource_Integrand.
-
+ InteriorWall represents heat storage within walls. It links a
+ variable number n of thermal resistances and capacities to a
+ series connection. n thus defines the spatial discretization of
+ thermal effects within the wall. All effects are considered as one-dimensional
+ normal to the wall's surface. This model is thought for interior wall
+ elements that only serve as heat storage elements. The RC-chain is defined via
+ a vector of capacities CInt[n] and a vector of resistances
+ RInt[n].
+ Resistances and capacities are connected alternately, starting with the first
+ resistance RInt[1], from heat port_a into the wall.
+
+
+
+
+ -
+ April 27, 2016, by Michael Wetter:
+ Added graphical connections.
+
+ -
+ April 17, 2015, by Moritz Lauster:
+ Implemented.
+
+
+
+-------- Corrected Code --------
+
+ InteriorWall represents heat storage within walls. It
+ links a variable number n of thermal resistances and
+ capacities to a series connection. n thus defines the
+ spatial discretization of thermal effects within the wall. All
+ effects are considered as one-dimensional normal to the wall's
+ surface. This model is thought for interior wall elements that only
+ serve as heat storage elements. The RC-chain is defined via a vector
+ of capacities CInt[n] and a vector of resistances
+ RInt[n]. Resistances and capacities are connected
+ alternately, starting with the first resistance RInt[1],
+ from heat port_a into the wall.
+
+
+
+
+
+ - April 27, 2016, by Michael Wetter:
+ Added graphical connections.
+
+ - April 17, 2015, by Moritz Lauster:
+ Implemented.
+
+
+
+-------- Errors --------
+line 13 column 4 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Utilities/Math/QuadraticLinear.mo ----
+-------- HTML Code --------
+
+ Block for function quadraticLinear, which computes
+ y = a1 + a2 x1 + a3 x12 + (a4 + a5 x1 + a6 x12) x2
-
- March 22, 2018 by Massimo Cimmino:
- First implementation.
+ November 29, 2013 by Marcus Fuchs:
+ Implementation based on Functions.quadraticLinear.
-------- Corrected Code --------
- This function evaluates the cylindrical heat source solution. This
- solution gives the relation between the constant heat transfer rate
- (per unit length) injected by a cylindrical heat source of infinite
- length and the temperature raise in the medium. The cylindrical heat
- source solution is defined by
-
-
-
-
-
- where ΔT(t,r) is the temperature raise after a time t
- of constant heat injection and at a distance r from the
- cylindrical source, Q' is the heat injection rate per unit
- length, ks is the soil thermal conductivity,
- Fo is the Fourier number, aSois is the
- ground thermal diffusivity, rb is the radius of the
- cylindrical source and G is the cylindrical heat source
- solution.
-
-
- The cylindrical heat source solution is given by:
+ Block for function quadraticLinear, which computes
-
-
-
- The integral is solved numerically, with the integrand defined in
-
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.cylindricalHeatSource_Integrand.
+ y = a1 + a2 x1 + a3 x12 + (a4 + a5 x1 + a6 x12) x2
- - March 22, 2018 by Massimo Cimmino:
- First implementation.
+ - November 29, 2013 by Marcus Fuchs:
+ Implementation based on Functions.quadraticLinear.
-------- Errors --------
-line 8 column 2 - Warning: attribute "align" not allowed for HTML5
-line 23 column 2 - Warning: attribute "align" not allowed for HTML5
+line 3 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Storage/UsersGuide.mo ----
+---- AixLib/ThermalZones/ReducedOrder/RC/BaseClasses/ExteriorWall.mo ----
-------- HTML Code --------
+ ExteriorWall represents heat conduction and heat storage
+ within walls. It links a variable number n of thermal resistances
+ and capacities to a series connection. n thus defines the spatial
+ discretization of thermal effects within the wall. All effects are considered
+ as one-dimensional normal to the wall's surface. This model is thought
+ for exterior wall elements that contribute to heat transfer to the outdoor.
+ The RC-chain is defined via a vector of capacities CExt[n] and a
+ vector of resistances RExt[n]. Resistances and capacities are
+ connected alternately, starting with the first resistance RExt[1],
+ from heat port_a to heat port_b. RExtRem
+ is the resistance between the last capacity CExt[end] and the
+ heat port_b.
+
+
+
+ -
+ April 27, 2016, by Michael Wetter:
+ Added graphical connections.
+
+ -
+ April 17, 2015, by Moritz Lauster:
+ Implemented.
+
+
+
+-------- Corrected Code --------
-This user's guide describes the storage tank models.
-There are three storage tank models in the this package.
-
-
-| Model name | Description |
|---|
-
-|
-
-AixLib.Fluid.Storage.Stratified
- |
-
-
-This is a model of a stratified storage tank as shown in the figure below.
+ ExteriorWall represents heat conduction and heat storage
+ within walls. It links a variable number n of thermal
+ resistances and capacities to a series connection. n
+ thus defines the spatial discretization of thermal effects within the
+ wall. All effects are considered as one-dimensional normal to the
+ wall's surface. This model is thought for exterior wall elements that
+ contribute to heat transfer to the outdoor. The RC-chain is defined
+ via a vector of capacities CExt[n] and a vector of
+ resistances RExt[n]. Resistances and capacities are
+ connected alternately, starting with the first resistance
+ RExt[1], from heat port_a to heat
+ port_b. RExtRem is the resistance between
+ the last capacity CExt[end] and the heat
+ port_b.
-![\"Image]()
-
-
-The tank uses several volumes to model the stratification.
-Heat conduction is modeled between the volumes through the fluid,
-and between the volumes and the ambient.
-
-
-The heat port heaPorVol may be used to connect a temperature sensor
-that measures the fluid temperature of an individual volume. It may also
-be used to add heat to individual volumes, for example if the tank contains
-an electrical resistance heater.
+
+
+ - April 27, 2016, by Michael Wetter:
+ Added graphical connections.
+
+ - April 17, 2015, by Moritz Lauster:
+ Implemented.
+
+
+
+-------- Errors --------
+line 14 column 4 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/BoundaryConditions/Validation/UsersGuide.mo ----
+-------- HTML Code --------
+
-Similarly, the fluid port fluPorVol may be used to connect a fluid pipe
-to an individual volume. This allows for example to draw water from that volume whose temperature
-is close to the temperature required by the consumer.
-Conversely, water could be added to that tank volume whose temperature is close to the
-inlet water temperature.
-If you don't use such a pipe, simply leave the ports unconnected.
+The package AixLib.BoundaryConditions.Validation.BESTEST
+contains the models that are used for the BESTEST validation ASHRAE 2020 for weather data acquisition and postprocessing.
-The tank has nSeg fluid volumes. The top segment has the index 1.
-Thus, to add a heating element to the bottom element, connect a heat input to
-heaPorVol[nSeg].
+Each model represents a different climate with different days as shown in the tables below.
+All examples have a script that runs the simulation according to the specifications and derive the required Json file as reported below.
-The heat ports outside the tank insulation can be
-used to specify an ambient temperature.
-Leave these ports unconnected to force adiabatic boundary conditions.
-Note, however, that all heat conduction elements through the tank wall (but not the top and bottom) are connected to the
-heat port heaPorSid. Thus, not connecting
-heaPorSid means an adiabatic boundary condition in the sense
-that heaPorSid.Q_flow = 0. This, however, still allows heat to flow
-through the tank walls, modeled by conWal, from one fluid volume
-to another one.
+The weather radiation data has to be provided at different orientations and inclinations.
- |
+Table 2: Azimuth and Slope for Surfaces
+
+Azimuth |
+Slope |
-|
-
-AixLib.Fluid.Storage.StratifiedEnhanced
- |
-
-
-The model is identical to
-
-AixLib.Fluid.Storage.Stratified,
-except for the following:
-
+ | Horizontal |
+0° from horizontal |
+
+
+South |
+90° from horizontal |
+
+
+East |
+90° from horizontal |
+
+
+North |
+90° from horizontal |
+
+
+West |
+90° from horizontal |
+
+
+45° East of South |
+90° from horizontal |
+
+
+45° West of South |
+90° from horizontal |
+
+
+East |
+30° from horizontal |
+
+
+South |
+30° from horizontal |
+
+
+West |
+30° from horizontal |
+
+
+
+
Additional parameters and correlations
+- Ground reflectance ρ is set to 0 for cases from WD100 to WD500 and 0.2 for WD600
-
-It adds a correction that reduces the numerical dissipation.
-
--
-It does not contain the fluid ports
fluPorVol that
-connect from the outside to the individual volumes.
+Sky black body temperature
+calculated using Horizontal radiation or dew point temperature and sky cover.
+- Diffused radiation calculated using Perez and
+Isotropic sky models
-
-The correction uses a third order upwind scheme to compute the
-outlet temperatures of the segments in the tank. This model
-is implemented in
-
-AixLib.Fluid.Storage.BaseClasses.ThirdOrderStratifier.
-
-
+Outputs required
+Annual Outputs
+ The following outputs are provided for an annual simulation:
+
+- Average dry bulb temperature (°C)
+- Average relative humidity (%)
+- Average dewpoint temperature (°C)
+- Average humidity ratio (kg moisture/kg dry air)
+- Average wet bulb temperature (°C)
+- Sum of total, beam, and diffuse solar radiation incident on each surface (Wh/m2)
+
+
Hourly Outputs
+The following outputs are provided for each hour of the days specified for each test case in Table 3:
+
+- Dry bulb temperature (°C)
+- Relative humidity (%)
+- Dewpoint temperature (°C)
+- Humidity ratio (kg moisture/kg dry air)
+- Wet bulb temperature (°C)
+- Windspeed (m/s)
+- Wind direction (degrees from north)
+- Station pressure (mbar)
+- Total cloud cover (tenths of sky)
+- Opaque cloud cover (tenths of sky)
+- Sky temperature (°C)
+- Sum of total, beam, and diffuse solar radiation incident on each surface (Wh/m2)
+
+
Table 3: Specific Days for Output
+
+Case |
+Days |
-|
-
-AixLib.Fluid.Storage.StratifiedEnhancedInternalHex
- |
-
-
-This model is identical to
-
-AixLib.Fluid.Storage.StratifiedEnhanced
-except that it adds a heat exchanger to the tank.
-
-
-The modifications consist of adding a heat exchanger
-and fluid ports to connect to the heat exchanger.
-The modifications allow to run a fluid through the tank causing heat transfer to the stored fluid.
-A typical example is a storage tank in a solar hot water system.
-
-
-The heat exchanger model assumes flow through the inside of a helical coil heat exchanger,
-and stagnant fluid on the outside. Parameters are used to describe the
-heat transfer on the inside of the heat exchanger at nominal conditions, and
-geometry of the outside of the heat exchanger. This information is used to compute
-an hA-value for each side of the coil.
-Convection calculations are then performed to identify heat transfer
-between the heat transfer fluid and the fluid in the tank.
-
-
-The location of the heat exchanger can be parameterized as follows:
-The parameters hHex_a and hHex_b are the heights
-of the heat exchanger ports portHex_a and portHex_b,
-measured from the bottom of the tank.
-For example, to place the port portHex_b at the bottom of the tank,
-set hHexB_b=0.
-The parameters hHex_a and hHex_b are then used to provide
-a default value for the parameters
-segHex_a and segHex_b, which are the numbers of the tank
-segments to which the heat exchanger ports portHex_a and portHex_b
-are connected.
-
-
-![\"Image]()
+ | WD100 |
+May 4th, July 14th, September 6th |
+
+
+WD200 |
+May 24th, August 26th |
+
+
+WD300 |
+February 7th, August 13th |
+
+
+WD400 |
+January 24th, July 1st |
+
+
+WD500 |
+March 1st, September 14th |
+
+
+WD600 |
+May 4th, July 14th, September 6th |
+
+
+
Sub-hourly Outputs
+The following outputs are provided at each timestep of the days specified for each test case in Table 3:
+
+- Dry bulb temperature (C)
+- Relative humidity (%)
+- Sum of total, beam, and diffuse solar radiation incident on each surface (Wh/m2)
+
+The following outputs are provided integrated hourly for the days specified for each test case in Table 3:
+
+- Total incident horizontal solar radiation (Wh/m2)
+- Total incident horizontal beam solar radiation (Wh/m2)
+- Total incident horizontal diffuse solar radiation (Wh/m2)
+
+Validation results
+(Not available yet)
+Implementation
+To generate the data shown in this user guide, run
+
+cd AixLib/Resources/Data/BoundaryConditions/Validation/BESTEST
+python3 generateResults.py -p
+
+At the beginning of the Python script there are several options that the user can choose, by default the script will:
+
+- Clone the last master branch of the AixLib repository into a temporary directory
+- Execute all the simulations and create the folders with the .mat and .json files inside the BESTEST/Simulations folder
+
+References
+(Not available yet)
+
+
+-
+March 11, 2020, by Ettore Zanetti:
+first implementation of BESTEST weather validation
+
+
+
+-------- Corrected Code --------
-Optionally, this model computes a dynamic response of the heat exchanger.
-This can be configured using the parameters
-energyDynamicsHexSolid,
-energyDynamicsHex and
-massDynamicsHex.
-For this computation, the fluid volume inside the heat exchanger
-and the heat capacity of the heat
-exchanger wall CHex are approximated.
-Both depend on the length lHex
-of the heat exchanger.
-The model provides default values for these
-parameters, as well as for the heat exchanger material which is
-assumed to be steel. These default values can be overwritten by the user.
-The default values for the heat exchanger geometry are computed assuming
-that there is a cylindrical heat exchanger
-made of steel whose diameter is half the diameter of the tank, e.g.,
-rHex=rTan/2.
-Hence, the length of the heat exchanger is approximated as
-lHex = 2 rHex π h = 2 rTan/2 π h,
-where h is the distance between the heat exchanger inlet and outlet.
-The wall thickness is assumed to be 10% of the heat exchanger
-outer diameter.
-For typical applications, users do not need to change these values.
+ The package AixLib.BoundaryConditions.Validation.BESTEST
+ contains the models that are used for the BESTEST validation ASHRAE
+ 2020 for weather data acquisition and postprocessing.
-Setting energyDynamicsHexSolid to a dynamic balance and
-energyDynamicsHex to a steady-state balance may be of interest
-to remove very fast dynamics of the fluid, while still modeling slower
-dynamics that arises from the metal of the heat exchanger.
-By default, energyDynamicsHexSolid is set
-to the same value as energyDynamicsHex
-as this seems to be the typical configuration.
+ Each model represents a different climate with different days as
+ shown in the tables below. All examples have a script that runs the
+ simulation according to the specifications and derive the required
+ Json file as reported below.
-The heat exchanger is implemented in
-
-AixLib.Fluid.Storage.BaseClasses.IndirectTankHeatExchanger.
+ The weather radiation data has to be provided at different
+ orientations and inclinations.
-
-
-
-
--------- Corrected Code --------
- This user's guide describes the storage tank models. There are three
- storage tank models in the this package.
+ Table 2: Azimuth and Slope for Surfaces
-
+
- |
- Model name
- |
-
- Description
- |
+
+
+ Azimuth
+
+ |
+
+
+ Slope
+
+ |
|
- AixLib.Fluid.Storage.Stratified
+
+ Horizontal
+
|
- This is a model of a stratified storage tank as shown in the
- figure below.
+ 0° from horizontal
-
-
+ |
+
+
+ |
+
+ South
+ |
+
- The tank uses several volumes to model the stratification. Heat
- conduction is modeled between the volumes through the fluid,
- and between the volumes and the ambient.
+ 90° from horizontal
+ |
+
+
+ |
- The heat port heaPorVol may be used to connect a
- temperature sensor that measures the fluid temperature of an
- individual volume. It may also be used to add heat to
- individual volumes, for example if the tank contains an
- electrical resistance heater.
+ East
+ |
+
- Similarly, the fluid port fluPorVol may be used to
- connect a fluid pipe to an individual volume. This allows for
- example to draw water from that volume whose temperature is
- close to the temperature required by the consumer. Conversely,
- water could be added to that tank volume whose temperature is
- close to the inlet water temperature. If you don't use such a
- pipe, simply leave the ports unconnected.
+ 90° from horizontal
+ |
+
+
+ |
- The tank has nSeg fluid volumes. The top segment
- has the index 1. Thus, to add a heating element to
- the bottom element, connect a heat input to
- heaPorVol[nSeg].
+ North
+ |
+
- The heat ports outside the tank insulation can be used to
- specify an ambient temperature. Leave these ports unconnected
- to force adiabatic boundary conditions. Note, however, that all
- heat conduction elements through the tank wall (but not the top
- and bottom) are connected to the heat port
- heaPorSid. Thus, not connecting
- heaPorSid means an adiabatic boundary condition in
- the sense that heaPorSid.Q_flow = 0. This,
- however, still allows heat to flow through the tank walls,
- modeled by conWal, from one fluid volume to
- another one.
+ 90° from horizontal
|
|
- AixLib.Fluid.Storage.StratifiedEnhanced
+
+ West
+
|
- The model is identical to AixLib.Fluid.Storage.Stratified,
- except for the following:
+ 90° from horizontal
-
- - It adds a correction that reduces the numerical
- dissipation.
-
- - It does not contain the fluid ports
fluPorVol
- that connect from the outside to the individual volumes.
-
-
+ |
+
+
+ |
- The correction uses a third order upwind scheme to compute the
- outlet temperatures of the segments in the tank. This model is
- implemented in
- AixLib.Fluid.Storage.BaseClasses.ThirdOrderStratifier.
+ 45° East of South
+
+ |
+
+
+ 90° from horizontal
|
|
- AixLib.Fluid.Storage.StratifiedEnhancedInternalHex
+
+ 45° West of South
+
|
- This model is identical to AixLib.Fluid.Storage.StratifiedEnhanced
- except that it adds a heat exchanger to the tank.
+ 90° from horizontal
+ |
+
+
+ |
- The modifications consist of adding a heat exchanger and fluid
- ports to connect to the heat exchanger. The modifications allow
- to run a fluid through the tank causing heat transfer to the
- stored fluid. A typical example is a storage tank in a solar
- hot water system.
+ East
+ |
+
- The heat exchanger model assumes flow through the inside of a
- helical coil heat exchanger, and stagnant fluid on the outside.
- Parameters are used to describe the heat transfer on the inside
- of the heat exchanger at nominal conditions, and geometry of
- the outside of the heat exchanger. This information is used to
- compute an hA-value for each side of the coil.
- Convection calculations are then performed to identify heat
- transfer between the heat transfer fluid and the fluid in the
- tank.
+ 30° from horizontal
+ |
+
+
+ |
- The location of the heat exchanger can be parameterized as
- follows: The parameters hHex_a and
- hHex_b are the heights of the heat exchanger ports
- portHex_a and portHex_b, measured
- from the bottom of the tank. For example, to place the port
- portHex_b at the bottom of the tank, set
- hHexB_b=0. The parameters hHex_a and
- hHex_b are then used to provide a default value
- for the parameters segHex_a and
- segHex_b, which are the numbers of the tank
- segments to which the heat exchanger ports
- portHex_a and portHex_b are
- connected.
-
-
-
+ South
+ |
+
- Optionally, this model computes a dynamic response of the heat
- exchanger. This can be configured using the parameters
- energyDynamicsHexSolid,
- energyDynamicsHex and
- massDynamicsHex. For this computation, the fluid
- volume inside the heat exchanger and the heat capacity of the
- heat exchanger wall CHex are approximated. Both
- depend on the length lHex of the heat exchanger.
- The model provides default values for these parameters, as well
- as for the heat exchanger material which is assumed to be
- steel. These default values can be overwritten by the user. The
- default values for the heat exchanger geometry are computed
- assuming that there is a cylindrical heat exchanger made of
- steel whose diameter is half the diameter of the tank, e.g.,
- rHex=rTan/2. Hence, the length of
- the heat exchanger is approximated as lHex = 2
- rHex π h = 2 rTan/2 π h, where
- h is the distance between the heat exchanger inlet and
- outlet. The wall thickness is assumed to be 10% of the
- heat exchanger outer diameter. For typical applications, users
- do not need to change these values.
+ 30° from horizontal
+ |
+
+
+ |
- Setting energyDynamicsHexSolid to a dynamic
- balance and energyDynamicsHex to a steady-state
- balance may be of interest to remove very fast dynamics of the
- fluid, while still modeling slower dynamics that arises from
- the metal of the heat exchanger. By default,
- energyDynamicsHexSolid is set to the same value as
- energyDynamicsHex as this seems to be the typical
- configuration.
+ West
+ |
+
- The heat exchanger is implemented in AixLib.Fluid.Storage.BaseClasses.IndirectTankHeatExchanger.
+ 30° from horizontal
|
-
-
--------- Errors --------
-line 6 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
-line 17 column 1 - Warning: attribute "align" not allowed for HTML5
-line 129 column 1 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/HeatExchangers/BaseClasses/PartialEffectivenessNTU.mo ----
--------- HTML Code --------
-
-
- Partial model of a heat exchanger without humidity condensation.
- This model transfers heat in the amount of
-
-
- Q = Qmax ε
- ε = f(NTU, Z, flowRegime),
-
-
- where
- Qmax is the maximum heat that can be transferred,
- ε is the heat transfer effectiveness,
- NTU is the Number of Transfer Units,
- Z is the ratio of minimum to maximum capacity flow rate and
- flowRegime is the heat exchanger flow regime.
- such as
- parallel flow, cross flow or counter flow.
-
-
- The flow regimes depend on the heat exchanger configuration. All configurations
- defined in
-
- AixLib.Fluid.Types.HeatExchangerConfiguration
- are supported.
-
-
- Models that extend from this partial model need to provide an assignment
- for UA.
-
-
-
- -
- February 25, 2021 by Baptiste Ravache:
- Added a warning for when Q_flow_nominal is specified with the wrong sign.
-
- -
- January 10, 2018 by Michael Wetter:
- Removed variable Z that is not used.
- This is for
- issue 1328.
-
- -
- January 10, 2018 by Filip Jorissen:
- Corrected an error where the value of NTU was assigned to Z.
- This is for
- issue 1328.
-
- -
- February 27, 2016 by Michael Wetter:
- Introduced sta1_default and sta2_default
- to enable translation under OpenModelica.
- Removed max=1 attribute for Z. This is needed as near
- zero flow, Z can be larger than one due to the regularization.
- As Z is not used in this model other than for reporting, this bound
- need not be enforced (and the calculation of eps is fine at these small flow rates).
- This is for
- issue 490.
-
- -
- April 29, 2014 by Michael Wetter:
- Changed assert statement to avoid comparing
- enumeration with an integer, which triggers a warning
- in Dymola 2015.
-
- -
- July 30, 2013 by Michael Wetter:
- Updated model to use new variable mWat_flow
- in the base class.
-
- -
- February 12, 2010, by Michael Wetter:
- First implementation.
-
-
-
--------- Corrected Code --------
-
- Partial model of a heat exchanger without humidity condensation. This
- model transfers heat in the amount of
-
-
- Q = Qmax ε
- ε = f(NTU, Z, flowRegime),
-
-
- where Qmax is the maximum heat that can be
- transferred, ε is the heat transfer effectiveness, NTU
- is the Number of Transfer Units, Z is the ratio of minimum to
- maximum capacity flow rate and flowRegime is the heat
- exchanger flow regime. such as parallel flow, cross flow or counter
- flow.
-
-
- The flow regimes depend on the heat exchanger configuration. All
- configurations defined in AixLib.Fluid.Types.HeatExchangerConfiguration
- are supported.
-
+
- Models that extend from this partial model need to provide an
- assignment for UA.
+ Additional parameters and correlations
- - February 25, 2021 by Baptiste Ravache:
- Added a warning for when Q_flow_nominal is specified with the wrong
- sign.
+ - Ground reflectance ρ is set to 0 for cases from WD100 to WD500
+ and 0.2 for WD600
- - January 10, 2018 by Michael Wetter:
- Removed variable Z that is not used. This is for
+ -
issue
- 1328.
-
- - January 10, 2018 by Filip Jorissen:
- Corrected an error where the value of NTU was assigned to Z. This
- is for issue
- 1328.
-
- - February 27, 2016 by Michael Wetter:
- Introduced sta1_default and sta2_default
- to enable translation under OpenModelica. Removed
- max=1 attribute for Z. This is needed as
- near zero flow, Z can be larger than one due to the
- regularization. As Z is not used in this model other
- than for reporting, this bound need not be enforced (and the
- calculation of eps is fine at these small flow rates).
- This is for issue
- 490.
-
- - April 29, 2014 by Michael Wetter:
- Changed assert statement to avoid comparing
- enumeration with an integer, which triggers a warning in Dymola
- 2015.
-
- - July 30, 2013 by Michael Wetter:
- Updated model to use new variable mWat_flow in the
- base class.
+ \"modelica://AixLib.BoundaryConditions.SkyTemperature.BlackBody\">Sky
+ black body temperature calculated using Horizontal radiation or
+ dew point temperature and sky cover.
- - February 12, 2010, by Michael Wetter:
- First implementation.
+ - Diffused radiation calculated using
+ Perez and
+ Isotropic sky models
-
--------- Errors --------
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/HeatExchangers/ConstantEffectiveness.mo ----
--------- HTML Code --------
-
-
- Model for a heat exchanger with constant effectiveness.
-
-
- This model transfers heat in the amount of
-
-
- Q = Qmax ε,
-
-
- where ε is a constant effectiveness and
- Qmax is the maximum heat that can be transferred.
-
-
- For a heat and moisture exchanger, use
-
- AixLib.Fluid.MassExchangers.ConstantEffectiveness
- instead of this model.
-
-
-
- -
- August 13, 2013 by Michael Wetter:
- Corrected error in the documentation.
-
- -
- July 30, 2013 by Michael Wetter:
- Updated model to use new variable mWat_flow
- in the base class.
-
- -
- January 28, 2010, by Michael Wetter:
- Added regularization near zero flow.
-
- -
- October 2, 2009, by Michael Wetter:
- Changed computation of inlet temperatures to use
- state_*_inflow which is already known in base class.
-
- -
- April 28, 2008, by Michael Wetter:
- First implementation.
-
-
-
--------- Corrected Code --------
-
- Model for a heat exchanger with constant effectiveness.
-
-
- This model transfers heat in the amount of
-
-
- Q = Qmax ε,
-
+
+ Outputs required
+
- where ε is a constant effectiveness and Qmax
- is the maximum heat that can be transferred.
+ Annual Outputs
- For a heat and moisture exchanger, use AixLib.Fluid.MassExchangers.ConstantEffectiveness
- instead of this model.
+ The following outputs are provided for an annual
+ simulation:
- - August 13, 2013 by Michael Wetter:
- Corrected error in the documentation.
+ - Average dry bulb temperature (°C)
- - July 30, 2013 by Michael Wetter:
- Updated model to use new variable mWat_flow in the
- base class.
+ - Average relative humidity (%)
- - January 28, 2010, by Michael Wetter:
- Added regularization near zero flow.
+ - Average dewpoint temperature (°C)
- - October 2, 2009, by Michael Wetter:
- Changed computation of inlet temperatures to use
- state_*_inflow which is already known in base class.
+ - Average humidity ratio (kg moisture/kg dry air)
- - April 28, 2008, by Michael Wetter:
- First implementation.
+ - Average wet bulb temperature (°C)
-
-
--------- Errors --------
-line 8 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Utilities/Math/Functions/Examples/CubicHermite.mo ----
--------- HTML Code --------
-
-
- This example demonstrates the use of the function for cubic hermite interpolation
- and linear extrapolation.
- The example use interpolation with two different settings: One settings
- produces a monotone cubic hermite, whereas the other setting
- does not enforce monotonicity.
- The resulting plot should look as shown below, where for better visibility, the support points have been marked with black dots.
- Notice that the red curve is monotone increasing.
-
-
-
-
- -
- March 8, 2013, by Michael Wetter:
- First implementation.
-
-
-
--------- Corrected Code --------
+ Sum of total, beam, and diffuse solar radiation incident on each
+ surface (Wh/m2)
+
+
- This example demonstrates the use of the function for cubic hermite
- interpolation and linear extrapolation. The example use interpolation
- with two different settings: One settings produces a monotone cubic
- hermite, whereas the other setting does not enforce monotonicity. The
- resulting plot should look as shown below, where for better
- visibility, the support points have been marked with black dots.
- Notice that the red curve is monotone increasing.
+ Hourly Outputs
-
-
+
+ The following outputs are provided for each hour of the days
+ specified for each test case in Table 3:
- - March 8, 2013, by Michael Wetter:
- First implementation.
+ - Dry bulb temperature (°C)
-
-
--------- Errors --------
-line 11 column 2 - Warning: attribute "align" not allowed for HTML5
-
+ Relative humidity (%)
+
+ Dewpoint temperature (°C)
+
+ Humidity ratio (kg moisture/kg dry air)
+
+ Wet bulb temperature (°C)
+
+ Windspeed (m/s)
+
+ Wind direction (degrees from north)
+
+ Station pressure (mbar)
+
+ Total cloud cover (tenths of sky)
+
+ Opaque cloud cover (tenths of sky)
+
+ Sky temperature (°C)
+
+ Sum of total, beam, and diffuse solar radiation incident on each
+ surface (Wh/m2)
+
+
+
+ Table 3: Specific Days for Output
+
+
+
+ |
+
+ Case
+
+ |
+
+
+ Days
+
+ |
+
+
+ |
+
+ WD100
+
+ |
+
+
+ May 4th, July 14th, September 6th
+
+ |
+
+
+ |
+
+ WD200
+
+ |
+
+
+ May 24th, August 26th
+
+ |
+
+
+ |
+
+ WD300
+
+ |
+
+
+ February 7th, August 13th
+
+ |
+
+
+ |
+
+ WD400
+
+ |
+
+
+ January 24th, July 1st
+
+ |
+
+
+ |
+
+ WD500
+
+ |
+
+
+ March 1st, September 14th
+
+ |
+
+
+ |
+
+ WD600
+
+ |
+
+
+ May 4th, July 14th, September 6th
+
+ |
+
+
+
+ Sub-hourly Outputs
+
+
+ The following outputs are provided at each timestep of the days
+ specified for each test case in Table 3:
+
+
+ - Dry bulb temperature (C)
+
+ - Relative humidity (%)
+
+ - Sum of total, beam, and diffuse solar radiation incident on each
+ surface (Wh/m2)
+
+
+
+ The following outputs are provided integrated hourly for the days
+ specified for each test case in Table 3:
+
+
+ - Total incident horizontal solar radiation (Wh/m2)
+
+ - Total incident horizontal beam solar radiation (Wh/m2)
+
+ - Total incident horizontal diffuse solar radiation (Wh/m2)
+
+
+
+ Validation results
+
+
+ (Not available yet)
+
+
+ Implementation
+
+
+ To generate the data shown in this user guide, run
+
+
+cd AixLib/Resources/Data/BoundaryConditions/Validation/BESTEST
+python3 generateResults.py -p
+
+
+ At the beginning of the Python script there are several options that
+ the user can choose, by default the script will:
+
+
+ - Clone the last master branch of the AixLib repository into a
+ temporary directory
+
+ - Execute all the simulations and create the folders with the .mat
+ and .json files inside the BESTEST/Simulations folder
+
+
+
+ References
+
+
+ (Not available yet)
+
+
+ - March 11, 2020, by Ettore Zanetti:
+ first implementation of BESTEST weather validation
+
+
----- AixLib/Controls/Continuous/LimPID.mo ----
+-------- Errors --------
+line 14 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+line 98 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+
+
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/LoadAggregation/Validation/ShiftAggregationCells.mo ----
-------- HTML Code --------
- PID controller in the standard form
-
-
- y = k ( e(t) + 1 ⁄ Ti ∫ e(s) ds + Td de(t)⁄dt ),
-
-
- where
- y is the control signal,
- e(t) = us - um is the control error,
- with us being the set point and um being
- the measured quantity,
- k is the gain,
- Ti is the time constant of the integral term and
- Td is the time constant of the derivative term.
-
-
- Note that the units of k are the inverse of the units of the control error,
- while the units of Ti and Td are seconds.
-
-
- For detailed treatment of integrator anti-windup, set-point weights and output limitation, see
- Modelica.Blocks.Continuous.LimPID.
+ This validation case replicates the load-shifting procedure illustred in the figure below by Cimmino (2014).
- Options
- This controller can be configured as follows.
- P, PI, PD, or PID action
-
- Through the parameter controllerType, the controller can be configured
- as P, PI, PD or PID controller. The default configuration is PI.
+
+
- Direct or reverse acting
+ References
- Through the parameter reverseActing, the controller can be configured to
- be reverse or direct acting.
- The above standard form is reverse acting, which is the default configuration.
- For a reverse acting controller, for a constant set point,
- an increase in measurement signal u_m decreases the control output signal y
- (Montgomery and McDowall, 2008).
- Thus,
+ Cimmino, M. 2014. Développement et validation expérimentale de facteurs de réponse
+ thermique pour champs de puits géothermiques,
+ Ph.D. Thesis, École Polytechnique de Montréal.
+
- -
- for a heating coil with a two-way valve, leave
reverseActing = true, but
-
- -
- for a cooling coil with a two-way valve, set
reverseActing = false.
-
+ -
+ July 18, 2018, by Alex Laferrière:
+ First implementation.
+
- Reset of the controller output
-
- The controller can be configured to enable an input port that allows resetting the controller
- output. The controller output can be reset as follows:
-
-
- -
- If
reset = AixLib.Types.Reset.Disabled, which is the default,
- then the controller output is never reset.
-
- -
- If
reset = AixLib.Types.Reset.Parameter, then a boolean
- input signal trigger is enabled. Whenever the value of
- this input changes from false to true,
- the controller output is reset by setting y
- to the value of the parameter y_reset.
-
- -
- If
reset = AixLib.Types.Reset.Input, then a boolean
- input signal trigger and a real input signal y_reset_in
- are enabled. Whenever the value of
- trigger changes from false to true,
- the controller output is reset by setting the value of y
- to y_reset_in.
-
+
+-------- Corrected Code --------
+
+ This validation case replicates the load-shifting procedure illustred
+ in the figure below by Cimmino (2014).
+
+
+
+
+
+ References
+
+
+ Cimmino, M. 2014. Développement et validation expérimentale de
+ facteurs de réponse thermique pour champs de puits géothermiques,
+ Ph.D. Thesis, École Polytechnique de Montréal.
+
+
+ - July 18, 2018, by Alex Laferrière:
+ First implementation.
+
+
+
+-------- Errors --------
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Controls/Continuous/Examples/OffTimer.mo ----
+-------- HTML Code --------
+
+
+ Example that demonstrates the use of the model
+
+ AixLib.Controls.Continuous.OffTimer.
+ The input to the two timers are alternating boolean values.
+ Whenever the input becomes false(=0), the timer is reset.
+ The figures below show the input and output of the blocks.
+
+
+ ![\"Input](\"modelica://AixLib/Resources/Images/Controls/Continuous/Examples/OffTimer1.png\")
+ ![\"Input](\"modelica://AixLib/Resources/Images/Controls/Continuous/Examples/OffTimer2.png\")
+
+
+
+ -
+ November 21, 2011, by Michael Wetter:
+ Added documentation.
+
+
+-------- Corrected Code --------
+
+ Example that demonstrates the use of the model AixLib.Controls.Continuous.OffTimer.
+ The input to the two timers are alternating boolean values. Whenever
+ the input becomes false(=0), the timer is reset. The
+ figures below show the input and output of the blocks.
+
+
+
+
+
+
+ - November 21, 2011, by Michael Wetter:
+ Added documentation.
+
+
+
+-------- Errors --------
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Sources/Outside_CpLowRise.mo ----
+-------- HTML Code --------
+
- Note that this controller implements an integrator anti-windup. Therefore,
- for most applications, keeping the default setting of
- reset = AixLib.Types.Reset.Disabled is sufficient.
- However, if the controller is used in conjuction with equipment that is being
- switched on, better control performance may be achieved by resetting the controller
- output when the equipment is switched on.
- This is in particular the case in situations
- where the equipment control input should continuously increase as the equipment is
- switched on, such as a light dimmer that may slowly increase the luminance, or
- a variable speed drive of a motor that should continuously increase the speed.
+ This model describes boundary conditions for
+ pressure, enthalpy, and species concentration that can be obtained
+ from weather data. The model is identical to
+
+ AixLib.Fluid.Sources.Outside,
+ except that it adds the wind pressure to the
+ pressure at the fluid port ports.
+ The correlation that is used to compute the wind pressure is based
+ on Swami and Chandra (1987) and valid for low-rise buildings
+ with rectangular shape.
+ The same correlation is also implemented in CONTAM (Persily and Ivy, 2001).
+
- References
- R. Montgomery and R. McDowall (2008).
- \"Fundamentals of HVAC Control Systems.\"
- American Society of Heating Refrigerating and Air-Conditioning Engineers Inc. Atlanta, GA.
+ The wind pressure coefficient is computed based on the
+ side ratio of the walls, which is defined as
+
+
+ s = x ⁄ y
+
+
+ where x is the length of the wall that will be connected to
+ this model, and y is the length of the adjacent wall.
+ The wind direction is computed relative to the azimuth of this surface,
+ which is equal to the parameter azi.
+ The surface azimuth is defined in
+
+ AixLib.Types.Azimuth.
+ For example, if an exterior wall is South oriented, i.e., its outside-facing
+ surface is towards South, use
+ AixLib.Types.Azimuth.S.
+
+
+ Based on the surface azimuth, the wind direction and the side ratio
+ of the walls, the model computes how much the wind pressure
+ is attenuated compared to the reference wind pressure Cp0.
+ The reference wind pressure Cp0 is a user-defined parameter,
+ and must be equal to the wind pressure at zero wind incidence angle.
+ Swami and Chandra (1987) recommend Cp0 = 0.6 for
+ all low-rise buildings as this represents the average of
+ various values reported in the literature.
+ The computation of the actual wind pressure coefficient Cp
+ is explained in the function
+
+ Buildings.Airflow.Multizone.BaseClasses.windPressureLowRise
+ that is called by this model.
+
+
+ The pressure p at the port ports is computed as
+
+
+ p = pw + Cp 1 ⁄ 2 v2 ρ,
+
+
+ where
+ pw is the atmospheric pressure from the weather bus,
+ v is the wind speed from the weather bus, and
+ ρ is the fluid density.
+
+ This model differs from
+ AixLib.Fluid.Sources.Outside_CpData by the calculation of the wind pressure coefficient Cp,act.
+ The wind pressure coefficient is defined by an equation in stead of a user-defined table.
+ This model is only suited for low-rise rectangular buildings.
+
+ References
-
- June 1, 2020, by Michael Wetter:
- Corrected wrong convention of reverse and direct action.
- Changed default configuration from PID to PI.
- This is for issue 1365.
-
- -
- March 9, 2020, by Michael Wetter:
- Corrected wrong unit declaration for parameter k.
- This is for issue 1316.
+ Muthusamy V. Swami and
+ Subrato Chandra.
+
+
+ Procedures for
+ Calculating Natural
+ Ventilation Airflow
+ Rates in Buildings.
+ Florida Solar Energy Center, FSEC-CR-163-86. March, 1987.
+ Cape Canaveral, Florida.
-
- October 19, 2019, by Filip Jorissen:
- Disabled homotopy to ensure bounded outputs
- by copying the implementation from MSL 3.2.3 and by
- hardcoding the implementation for homotopyType=NoHomotopy.
- See issue 1221.
+ Andrew K. Persily and Elizabeth M. Ivy.
+
+
+ Input Data for Multizone Airflow and IAQ Analysis.
+ NIST, NISTIR 6585.
+ January, 2001.
+ Gaithersburg, MD.
+
+
+
-
- September 29, 2016, by Michael Wetter:
- Refactored model.
+ February 2, 2022, by Michael Wetter:
+ Revised implementation.
+ This is for
+ IBPSA, #1436.
-
- August 25, 2016, by Michael Wetter:
- Removed parameter limitsAtInit because it was only propagated to
- the instance limiter, but this block no longer makes use of this parameter.
- This is a non-backward compatible change.
- Revised implemenentation, added comments, made some parameter in the instances final.
-
- - July 18, 2016, by Philipp Mehrfeld:
- Added integrator reset.
- This is for issue 494.
+ Jun 28, 2021, by Klaas De Jonge:
+ Documentation changes to explain the difference with
+ AixLib.Fluid.Sources.Outside_CpData.
-
- March 15, 2016, by Michael Wetter:
- Changed the default value to strict=true in order to avoid events
- when the controller saturates.
- This is for issue 433.
+ January 26, 2016, by Michael Wetter:
+ Added unit and quantity attributes.
-
- February 24, 2010, by Michael Wetter:
+ October 26, 2011 by Michael Wetter:
First implementation.
-------- Corrected Code --------
- PID controller in the standard form
-
-
- y = k ( e(t) + 1 ⁄ Ti ∫ e(s) ds +
- Td de(t)⁄dt ),
+ This model describes boundary conditions for pressure, enthalpy, and
+ species concentration that can be obtained from weather data. The
+ model is identical to AixLib.Fluid.Sources.Outside,
+ except that it adds the wind pressure to the pressure at the fluid
+ port ports. The correlation that is used to compute the
+ wind pressure is based on Swami and Chandra (1987) and valid for
+ low-rise buildings with rectangular shape. The same correlation is
+ also implemented in CONTAM (Persily and Ivy, 2001).
+
- where y is the control signal, e(t) = us -
- um is the control error, with us
- being the set point and um being the measured
- quantity, k is the gain, Ti is the time
- constant of the integral term and Td is the time
- constant of the derivative term.
+ The wind pressure coefficient is computed based on the side ratio of
+ the walls, which is defined as
-
- Note that the units of k are the inverse of the units of the
- control error, while the units of Ti and
- Td are seconds.
+
+ s = x ⁄ y
- For detailed treatment of integrator anti-windup, set-point weights
- and output limitation, see Modelica.Blocks.Continuous.LimPID.
+ where x is the length of the wall that will be connected to
+ this model, and y is the length of the adjacent wall. The wind
+ direction is computed relative to the azimuth of this surface, which
+ is equal to the parameter azi. The surface azimuth is
+ defined in AixLib.Types.Azimuth. For
+ example, if an exterior wall is South oriented, i.e., its
+ outside-facing surface is towards South, use
+ AixLib.Types.Azimuth.S.
-
- Options
-This controller can be configured as follows.
-
- P, PI, PD, or PID action
-
- Through the parameter controllerType, the controller can
- be configured as P, PI, PD or PID controller. The default
- configuration is PI.
+ Based on the surface azimuth, the wind direction and the side ratio
+ of the walls, the model computes how much the wind pressure is
+ attenuated compared to the reference wind pressure Cp0.
+ The reference wind pressure Cp0 is a user-defined
+ parameter, and must be equal to the wind pressure at zero wind
+ incidence angle. Swami and Chandra (1987) recommend Cp0
+ = 0.6 for all low-rise buildings as this represents the average
+ of various values reported in the literature. The computation of the
+ actual wind pressure coefficient Cp is explained in
+ the function
+ Buildings.Airflow.Multizone.BaseClasses.windPressureLowRise that
+ is called by this model.
-
- Direct or reverse acting
-
- Through the parameter reverseActing, the controller can
- be configured to be reverse or direct acting. The above standard form
- is reverse acting, which is the default configuration. For a reverse
- acting controller, for a constant set point, an increase in
- measurement signal u_m decreases the control output
- signal y (Montgomery and McDowall, 2008). Thus,
+ The pressure p at the port ports is computed as
+
+
+ p = pw + Cp 1 ⁄ 2 v2 ρ,
-
- - for a heating coil with a two-way valve, leave
-
reverseActing = true, but
-
- - for a cooling coil with a two-way valve, set
reverseActing
- = false.
-
-
-
- Reset of the controller output
-
- The controller can be configured to enable an input port that allows
- resetting the controller output. The controller output can be reset
- as follows:
+ where pw is the atmospheric pressure from the
+ weather bus, v is the wind speed from the weather bus, and
+ ρ is the fluid density.
-
- - If
reset = AixLib.Types.Reset.Disabled, which is the
- default, then the controller output is never reset.
-
- - If
reset = AixLib.Types.Reset.Parameter, then a
- boolean input signal trigger is enabled. Whenever the
- value of this input changes from false to
- true, the controller output is reset by setting
- y to the value of the parameter y_reset.
-
- - If
reset = AixLib.Types.Reset.Input, then a boolean
- input signal trigger and a real input signal
- y_reset_in are enabled. Whenever the value of
- trigger changes from false to
- true, the controller output is reset by setting the
- value of y to y_reset_in.
-
-
- Note that this controller implements an integrator anti-windup.
- Therefore, for most applications, keeping the default setting of
- reset = AixLib.Types.Reset.Disabled is sufficient.
- However, if the controller is used in conjuction with equipment that
- is being switched on, better control performance may be achieved by
- resetting the controller output when the equipment is switched on.
- This is in particular the case in situations where the equipment
- control input should continuously increase as the equipment is
- switched on, such as a light dimmer that may slowly increase the
- luminance, or a variable speed drive of a motor that should
- continuously increase the speed.
+ This model differs from AixLib.Fluid.Sources.Outside_CpData
+ by the calculation of the wind pressure coefficient
+ Cp,act. The wind pressure coefficient is defined by an
+ equation in stead of a user-defined table. This model is only suited
+ for low-rise rectangular buildings.
References
-
- R. Montgomery and R. McDowall (2008). \"Fundamentals of HVAC Control
- Systems.\" American Society of Heating Refrigerating and
- Air-Conditioning Engineers Inc. Atlanta, GA.
-
- - June 1, 2020, by Michael Wetter:
- Corrected wrong convention of reverse and direct action.
- Changed default configuration from PID to PI.
- This is for issue
- 1365.
-
- - March 9, 2020, by Michael Wetter:
- Corrected wrong unit declaration for parameter k.
- This is for issue
- 1316.
-
- - October 19, 2019, by Filip Jorissen:
- Disabled homotopy to ensure bounded outputs by copying the
- implementation from MSL 3.2.3 and by hardcoding the implementation
- for homotopyType=NoHomotopy. See issue
- 1221.
+ - Muthusamy V. Swami and Subrato Chandra. Procedures
+ for Calculating Natural Ventilation Airflow Rates in
+ Buildings. Florida Solar Energy Center, FSEC-CR-163-86.
+ March, 1987. Cape Canaveral, Florida.
- - September 29, 2016, by Michael Wetter:
- Refactored model.
+ - Andrew K. Persily and Elizabeth M. Ivy. Input
+ Data for Multizone Airflow and IAQ Analysis. NIST, NISTIR
+ 6585. January, 2001. Gaithersburg, MD.
- - August 25, 2016, by Michael Wetter:
- Removed parameter limitsAtInit because it was only
- propagated to the instance limiter, but this block no
- longer makes use of this parameter. This is a non-backward
- compatible change.
- Revised implemenentation, added comments, made some parameter in
- the instances final.
+
+
+ - February 2, 2022, by Michael Wetter:
+ Revised implementation.
+ This is for IBPSA,
+ #1436.
- - July 18, 2016, by Philipp Mehrfeld:
- Added integrator reset. This is for issue 494.
+ - Jun 28, 2021, by Klaas De Jonge:
+ Documentation changes to explain the difference with AixLib.Fluid.Sources.Outside_CpData.
- - March 15, 2016, by Michael Wetter:
- Changed the default value to strict=true in order to
- avoid events when the controller saturates. This is for issue 433.
+ - January 26, 2016, by Michael Wetter:
+ Added unit and quantity attributes.
- - February 24, 2010, by Michael Wetter:
+ - October 26, 2011 by Michael Wetter:
First implementation.
-------- Errors --------
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+line 28 column 2 - Warning: attribute "align" not allowed for HTML5
+line 61 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Sources/Outside_CpData.mo ----
+---- AixLib/Fluid/FMI/Adaptors/HVAC.mo ----
-------- HTML Code --------
- This model describes boundary conditions for
- pressure, enthalpy, and species concentration that can be obtained
- from weather data. The model is identical to
-
- AixLib.Fluid.Sources.Outside,
- except that it adds the wind pressure to the
- pressure at the fluid ports ports.
+ The (time varying) vector Real output signal of this block can be defined in its
+ parameter menu via variable y. The purpose is to support the
+ easy definition of vector-valued Real expressions in a block diagram.
+
- The pressure p at the fluid ports is computed as:
+ Adaptor that can be used to connect an HVAC system (with acausal ports)
+ to input/output signals, which then can be exposed in an FMI interface.
+
+
+ The adaptor has a vector of fluid ports called ports.
+ The supply and return air ducts need to be connected to these ports.
+ Also, if a thermal zone has interzonal air exchange or air infiltration,
+ these flow paths also need be connected to ports.
+
+
+ This model outputs at the port fluPor the mass flow rate for
+ each flow that is connected to ports, together with its
+ temperature, water vapor mass fraction per total mass of the air (not per kg dry
+ air), and trace substances. These quantities are always as if the flow
+ enters the room, even if the flow is zero or negative.
+ If a medium has no moisture, e.g., if Medium.nXi=0, or
+ if it has no trace substances, e.g., if Medium.nC=0, then
+ the output signal for these properties are removed.
+ These quantities are always as if the flow
+ enters the room, even if the flow is zero or negative.
+ Thus, a thermal zone model that uses these signals to compute the
+ heat added by the HVAC system need to implement an equation such as
- p = pw + Cp,act Cs v2 ρ ⁄ 2,
+ Qsen = max(0, ṁsup) cp (Tsup - Tair,zon),
- where pw is the atmospheric pressure from the weather bus,
- v is the wind speed from the weather bus, and
- ρ is the fluid density.
+ where
+ Qsen is the sensible heat flow rate added to the thermal zone,
+ ṁsup is the supply air mass flow rate from
+ the port fluPor (which is negative if it is an exhaust),
+ cp is the specific heat capacity at constant pressure,
+ Tsup is the supply air temperature and
+ Tair,zon is the zone air temperature.
+ Note that without the max(·, ·) function, the energy
+ balance would be wrong.
- The wind pressure coefficient Cp,act is a function of the surface wind incidence
- angle and is defined relative to the surface azimuth (normal to the surface is 0).
- The wind incidence angle incAng is computed from the wind direction obtained from the weather file
- with the surface azimuth azi as the base of the angle.
- The relation between the wind pressure coefficient Cp,act and the incidence angle incAng
- is defined by a cubic hermite interpolation of the users table input.
- Typical table values can be obtained from the "AIVC guide to energy efficient ventilation",
- appendix 2 (1996). The default table is appendix 2, table 2.2, face 1.
+ The output signals of this model are the zone air temperature,
+ the water vapor mass fraction per total mass of the air (unless Medium.nXi=0)
+ and trace substances (unless Medium.nC=0).
+ These output connectors can be used to connect to a controller.
+ These values are obtained from the fluid stream(s) that flow into this component
+ at the port fluPor, e.g., from the connector
+ fluPor.backward.
+ Note that there are nPorts of these signals.
+ For a completely mixed room, they will all have the same value, but
+ for a room with non-uniform temperatures, they can have different values.
+ Assumption and limitations
- The wind speed modifier Cs can be used to incorporate the effect of the surroundings on the local wind speed.
+ The mass flow rates at ports sum to zero, hence this
+ model conserves mass.
- Definition of angles
- The angles incAngSurNor for the wind incidence angle relative to the surface normal
- are measured counter-clock wise.
- The figure below shows an example entry, which is also used in the model
-
- AixLib.Fluid.Sources.Examples.Outside_CpData_Specification.
-
-
-
-
- The wind incidence angle and surface azimuths are defined as follows:
- The wind indicience angle is obtained directly from the weather data bus weaBus.winDir.
- This variable contains the data from the weather data file that was read, such as a TMY3 file.
- In accordance to TMY3, the data is as shown in the table below.
-
-
- Value of winDir if the wind blows from different directions.
- | Wind from North:
0
0° | |
- Wind from West:
3π/2
270° | | Wind from East:
π/2
90° |
- | Wind from South:
π
180° | |
-
-
- For the surface azimuth azi, the specification from
- AixLib.Types.Azimuth is
- used, which is as shown in the table below.
+ This model does not impose any pressure, other than setting the pressure
+ of all fluid connections to ports to be equal.
+ The reason is that setting a pressure can lead to non-physical system models,
+ for example if a mass flow rate is imposed and the HVAC system is connected
+ to a model that sets a pressure boundary condition such as
+
+ AixLib.Fluid.Sources.Outside.
+ Also, setting a pressure would make it impossible to use multiple instances
+ of this model (one for each thermal zone) and build in Modelica an airflow network
+ model with pressure driven mass flow rates.
-
-
- Value of azi if the exterior wall faces in the different directions.
- | Wall facing north:
π
180° | |
- Wall facing West:
π/2
90° | | Wall facing east:
3π/2
270° |
- | Wall facing South:
0;
0° | |
-
-
- Related model
- This model differs from
- AixLib.Fluid.Sources.Outside_CpLowRise by the calculation of the wind pressure coefficient
- Cp,act.
- The wind pressure coefficient is defined by a user-defined table instead of a generalized equation
- such that it can be used for all building sizes and situations, for shielded buildings,
- and for buildings with non-rectangular shapes.
+ The model has no pressure drop. Hence, the pressure drop
+ of an air diffuser or of an exhaust grill need to be modelled
+ in models that are connected to ports.
+ Typical use and important parameters
- References
+ See
+
+ AixLib.Fluid.FMI.ExportContainers.HVACZone
+ for a model that uses this model.
-
- - M. W. Liddament, 1996, A guide to energy efficient ventilation. AIVC Annex V.
-
-
- February 2, 2022, by Michael Wetter:
- Revised implementation.
- This is for
- IBPSA, #1436.
+ January 18, 2019, by Jianjun Hu:
+ Limited the media choice to moist air only.
+ See #1050.
-
- Apr 6, 2021, by Klaas De Jonge:
+ September 13, 2017, by Michael Wetter:
+ Removed erroneous each.
+
+ -
+ October 4, 2016, by Michael Wetter:
+ Corrected assignment of quantity in CZon.
+
+ -
+ June 29, 2016, by Michael Wetter:
+ Revised implementation.
+
+ -
+ April 14, 2016, by Michael Wetter:
First implementation.
-------- Corrected Code --------
- This model describes boundary conditions for pressure, enthalpy, and
- species concentration that can be obtained from weather data. The
- model is identical to AixLib.Fluid.Sources.Outside,
- except that it adds the wind pressure to the pressure at the fluid
- ports ports.
+ The (time varying) vector Real output signal of this
+ block can be defined in its parameter menu via variable
+ y. The purpose is to support the easy definition of
+ vector-valued Real expressions in a block diagram.
- The pressure p at the fluid ports is computed as:
+ Adaptor that can be used to connect an HVAC system (with acausal
+ ports) to input/output signals, which then can be exposed in an FMI
+ interface.
-
- p = pw + Cp,act Cs v2 ρ ⁄
- 2,
+
+ The adaptor has a vector of fluid ports called ports.
+ The supply and return air ducts need to be connected to these ports.
+ Also, if a thermal zone has interzonal air exchange or air
+ infiltration, these flow paths also need be connected to
+ ports.
- where pw is the atmospheric pressure from the
- weather bus, v is the wind speed from the weather bus, and
- ρ is the fluid density.
+ This model outputs at the port fluPor the mass flow rate
+ for each flow that is connected to ports, together with
+ its temperature, water vapor mass fraction per total mass of the air
+ (not per kg dry air), and trace substances. These quantities are
+ always as if the flow enters the room, even if the flow is zero or
+ negative. If a medium has no moisture, e.g., if
+ Medium.nXi=0, or if it has no trace substances, e.g., if
+ Medium.nC=0, then the output signal for these properties
+ are removed. These quantities are always as if the flow enters the
+ room, even if the flow is zero or negative. Thus, a thermal zone
+ model that uses these signals to compute the heat added by the HVAC
+ system need to implement an equation such as
+
+
+ Qsen = max(0, ṁsup) cp
+ (Tsup - Tair,zon),
- The wind pressure coefficient Cp,act is a function
- of the surface wind incidence angle and is defined relative to the
- surface azimuth (normal to the surface is 0). The wind
- incidence angle incAng is computed from the wind
- direction obtained from the weather file with the surface azimuth
- azi as the base of the angle. The relation between the
- wind pressure coefficient Cp,act and the incidence
- angle incAng is defined by a cubic hermite interpolation
- of the users table input. Typical table values can be obtained from
- the \"AIVC guide to energy efficient ventilation\", appendix 2 (1996).
- The default table is appendix 2, table 2.2, face 1.
+ where Qsen is the sensible heat flow rate added to
+ the thermal zone, ṁsup is the supply air mass flow
+ rate from the port fluPor (which is negative if it is an
+ exhaust), cp is the specific heat capacity at
+ constant pressure, Tsup is the supply air
+ temperature and Tair,zon is the zone air
+ temperature. Note that without the max(·, ·) function, the
+ energy balance would be wrong.
- The wind speed modifier Cs can be used to
- incorporate the effect of the surroundings on the local wind speed.
+ The output signals of this model are the zone air temperature, the
+ water vapor mass fraction per total mass of the air (unless
+ Medium.nXi=0) and trace substances (unless
+ Medium.nC=0). These output connectors can be used to
+ connect to a controller. These values are obtained from the fluid
+ stream(s) that flow into this component at the port
+ fluPor, e.g., from the connector
+ fluPor.backward. Note that there are nPorts
+ of these signals. For a completely mixed room, they will all have the
+ same value, but for a room with non-uniform temperatures, they can
+ have different values.
- Definition of angles
+ Assumption and limitations
- The angles incAngSurNor for the wind incidence angle
- relative to the surface normal are measured counter-clock wise. The
- figure below shows an example entry, which is also used in the model
-
- AixLib.Fluid.Sources.Examples.Outside_CpData_Specification.
+ The mass flow rates at ports sum to zero, hence this
+ model conserves mass.
-
-
+
+ This model does not impose any pressure, other than setting the
+ pressure of all fluid connections to ports to be equal.
+ The reason is that setting a pressure can lead to non-physical system
+ models, for example if a mass flow rate is imposed and the HVAC
+ system is connected to a model that sets a pressure boundary
+ condition such as AixLib.Fluid.Sources.Outside.
+ Also, setting a pressure would make it impossible to use multiple
+ instances of this model (one for each thermal zone) and build in
+ Modelica an airflow network model with pressure driven mass flow
+ rates.
- The wind incidence angle and surface azimuths are defined as follows:
- The wind indicience angle is obtained directly from the weather data
- bus weaBus.winDir. This variable contains the data from
- the weather data file that was read, such as a TMY3 file. In
- accordance to TMY3, the data is as shown in the table below.
+ The model has no pressure drop. Hence, the pressure drop of an air
+ diffuser or of an exhaust grill need to be modelled in models that
+ are connected to ports.
-
-
- Value of winDir if the wind blows from different
- directions.
-
-
- |
-
- Wind from North:
- 0
- 0°
- |
- |
-
-
-
- Wind from West:
- 3π/2
- 270°
- |
- |
-
- Wind from East:
- π/2
- 90°
- |
-
-
- |
-
- Wind from South:
- π
- 180°
- |
- |
-
-
+
+ Typical use and important parameters
+
- For the surface azimuth azi, the specification from
- AixLib.Types.Azimuth is
- used, which is as shown in the table below.
-
-
-
- Value of azi if the exterior wall faces in the
- different directions.
-
-
- |
-
- Wall facing north:
- π
- 180°
- |
- |
-
-
-
- Wall facing West:
- π/2
- 90°
- |
- |
-
- Wall facing east:
- 3π/2
- 270°
- |
-
-
- |
-
- Wall facing South:
- 0;
- 0°
- |
- |
-
-
-
- Related model
-
-
- This model differs from AixLib.Fluid.Sources.Outside_CpLowRise
- by the calculation of the wind pressure coefficient
- Cp,act. The wind pressure coefficient is defined by
- a user-defined table instead of a generalized equation such that it
- can be used for all building sizes and situations, for shielded
- buildings, and for buildings with non-rectangular shapes.
-
-
- References
+ See AixLib.Fluid.FMI.ExportContainers.HVACZone
+ for a model that uses this model.
- - M. W. Liddament, 1996, A guide to energy efficient
- ventilation. AIVC Annex V.
+
- January 18, 2019, by Jianjun Hu:
+ Limited the media choice to moist air only. See #1050.
-
-
- - February 2, 2022, by Michael Wetter:
- Revised implementation.
- This is for IBPSA,
- #1436.
+ - September 13, 2017, by Michael Wetter:
+ Removed erroneous each.
- - Apr 6, 2021, by Klaas De Jonge:
+ - October 4, 2016, by Michael Wetter:
+ Corrected assignment of quantity in CZon.
+
+ - June 29, 2016, by Michael Wetter:
+ Revised implementation.
+
+ - April 14, 2016, by Michael Wetter:
First implementation.
-------- Errors --------
-line 51 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 63 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 14 column 2 - Warning: attribute "align" not allowed for HTML5
-line 43 column 2 - Warning: attribute "align" not allowed for HTML5
+line 26 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/BaseClasses/FlowModels/basicFlowFunction_m_flow.mo ----
+---- AixLib/Fluid/Actuators/Valves/Examples/TwoWayValveTable.mo ----
-------- HTML Code --------
- Function that computes the pressure drop of flow elements as
+ Test model for a two way valve in which a table is used to specify the
+ opening characteristics.
+ The valve has the following opening characteristics, which is taken from a test case
+ of the IEA EBC Annex 60 project.
-
- Δp = sign(m) (m ⁄ k)2
+
+ | y |
+ 0 | 0.1667 | 0.3333 | 0.5 | 0.6667 | 1 |
+
+ | Kv |
+ 0 | 0.19 | 0.35 | 0.45 | 0.5 | 0.65 |
+
+
+ The Kv value is the volume flow rate in m3/h at a pressure difference
+ of 1 bar.
+ Hence, the Kv value of the fully open valve is Kv=0.65.
- with regularization near the origin.
- Therefore, the flow coefficient is
+ Plotting the variables kv.y versus y.y shows that the valve
+ reproduces the Kv values shown in the above table.
-
- k = m ⁄ √ Δp
+
+
- The input m_flow_turbulent determines the location of the regularization.
+ The parameter filterOpening is set to false,
+ as this model is used to plot the flow at different opening signals
+ without taking into account the travel time of the actuator.
-
- December 9, 2019, by Michael Wetter:
- Added smooth(2, . ), similar to
-
- AixLib.Fluid.BaseClasses.FlowModels.basicFlowFunction_dp.
- See #1240.
-
- -
- January 4, 2019, by Michael Wetter:
- Set `Inline=false`.
- See #1070.
-
- -
- May 1, 2017, by Filip Jorissen:
- Revised implementation such that
-
- AixLib.Fluid.BaseClasses.FlowModels.basicFlowFunction_m_flow
- is C2 continuous.
- See #725.
-
- -
- January 22, 2016, by Michael Wetter:
- Corrected type declaration of pressure difference.
- This is
- for #404.
-
- -
- July 28, 2015, by Michael Wetter:
- Removed double declaration of smooth(..) and smoothOrder
- and changed Inline=true to LateInline=true.
- This is for
- issue 301.
-
- -
- July 15, 2015, by Filip Jorissen:
- New, more efficient implementation based on regularisation using simple polynomial.
- Expanded common subexpressions for function inlining to be possible.
- Set Inline=true for inlining to occur.
- This is for
- #279.
-
- -
- August 10, 2011, by Michael Wetter:
- Removed if-then optimization that set dp=0 if m_flow=0,
- as this causes the derivative to be discontinuous at m_flow=0.
-
- -
- August 4, 2011, by Michael Wetter:
- Removed option to use a linear function. The linear implementation is now done
- in models that call this function. With the previous implementation,
- the symbolic processor may not rearrange the equations, which can lead
- to coupled equations instead of an explicit solution.
+ August 12, 2014 by Michael Wetter:
+ Added parameter keyword to datVal,
+ as this is needed to asssign datVal to a parameter
+ in the instance valTab.
+ This also avoids an error in OpenModelica.
-
- April 13, 2009, by Michael Wetter:
+ April 2, 2014 by Michael Wetter:
First implementation.
-------- Corrected Code --------
- Function that computes the pressure drop of flow elements as
+ Test model for a two way valve in which a table is used to specify
+ the opening characteristics. The valve has the following opening
+ characteristics, which is taken from a test case of the IEA EBC Annex
+ 60 project.
-
- Δp = sign(m) (m ⁄ k)2
+
+
+ |
+ y
+ |
+
+ 0
+ |
+
+ 0.1667
+ |
+
+ 0.3333
+ |
+
+ 0.5
+ |
+
+ 0.6667
+ |
+
+ 1
+ |
+
+
+ |
+ Kv
+ |
+
+ 0
+ |
+
+ 0.19
+ |
+
+ 0.35
+ |
+
+ 0.45
+ |
+
+ 0.5
+ |
+
+ 0.65
+ |
+
+
+
+ The Kv value is the volume flow rate in
+ m3/h at a pressure difference of 1 bar. Hence, the
+ Kv value of the fully open valve is
+ Kv=0.65.
- with regularization near the origin. Therefore, the flow coefficient
- is
+ Plotting the variables kv.y versus y.y
+ shows that the valve reproduces the Kv values shown
+ in the above table.
-
- k = m ⁄ √ Δp
-
+
+
- The input m_flow_turbulent determines the location of
- the regularization.
+ The parameter filterOpening is set to
+ false, as this model is used to plot the flow at
+ different opening signals without taking into account the travel time
+ of the actuator.
- - December 9, 2019, by Michael Wetter:
- Added smooth(2, . ), similar to
- AixLib.Fluid.BaseClasses.FlowModels.basicFlowFunction_dp.
- See #1240.
-
- - January 4, 2019, by Michael Wetter:
- Set `Inline=false`.
- See #1070.
-
- - May 1, 2017, by Filip Jorissen:
- Revised implementation such that
- AixLib.Fluid.BaseClasses.FlowModels.basicFlowFunction_m_flow is
- C2 continuous. See #725.
+ - August 12, 2014 by Michael Wetter:
+ Added parameter keyword to datVal, as
+ this is needed to asssign datVal to a parameter in the
+ instance valTab. This also avoids an error in
+ OpenModelica.
- - January 22, 2016, by Michael Wetter:
- Corrected type declaration of pressure difference. This is for
- #404.
-
- - July 28, 2015, by Michael Wetter:
- Removed double declaration of smooth(..) and
- smoothOrder and changed Inline=true to
- LateInline=true. This is for issue 301.
-
- - July 15, 2015, by Filip Jorissen:
- New, more efficient implementation based on regularisation using
- simple polynomial. Expanded common subexpressions for function
- inlining to be possible. Set Inline=true for inlining
- to occur. This is for #279.
-
- - August 10, 2011, by Michael Wetter:
- Removed if-then optimization that set
- dp=0 if m_flow=0, as this causes the
- derivative to be discontinuous at m_flow=0.
-
- - August 4, 2011, by Michael Wetter:
- Removed option to use a linear function. The linear implementation
- is now done in models that call this function. With the previous
- implementation, the symbolic processor may not rearrange the
- equations, which can lead to coupled equations instead of an
- explicit solution.
-
- - April 13, 2009, by Michael Wetter:
- First implementation.
+ - April 2, 2014 by Michael Wetter:
+ First implementation.
-------- Errors --------
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
-line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 24 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Controls/Continuous/Examples/SignalRanker.mo ----
+---- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/MSLAIT2Nodes.mo ----
-------- HTML Code --------
-
- Example that demonstrates the use of the signal ranker model.
- The figure below shows the input and output signals of the block.
- Note that
- sigRan.y[1] ≥ sigRan.y[2] ≥ sigRan.y[3].
+ The example contains
+
+ experimental data from a real district heating network.
+ This data is used to validate this library's
+ plug flow pipe model
+ in
+ AixLib.Fluid.FixedResistances.Validation.PlugFlowPipes.PlugFlowAIT.
-
-
-
+
+ Note that these three models are identical, except for the pipe model that is used:
-
-
--------- Corrected Code --------
-
- Example that demonstrates the use of the signal ranker model. The
- figure below shows the input and output signals of the block. Note
- that sigRan.y[1] ≥ sigRan.y[2] ≥ sigRan.y[3].
-
-
-
-
-
-
- - October 15, 2021, by Michael Wetter:
- Moved start time of sine input signal to avoid simultaneous state
- event and time event.
- This is for IBPSA,
- #1534.
-
- - November 21, 2011, by Michael Wetter:
- Added documentation.
-
-
-
--------- Errors --------
-line 8 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/HeatExchangers/DryCoilEffectivenessNTU.mo ----
--------- HTML Code --------
-
- Model of a coil without humidity condensation.
- This model transfers heat in the amount of
-
-
- Q̇ = Q̇max ε
- ε = f(NTU, Z, flowRegime),
+ This comparison between different discretization levels and pipe models is made
+ to check the influence of the discretization and pipe model on computation time
+ and simulation accuracy.
-
- where
- Q̇max is the maximum heat that can be transferred,
- ε is the heat transfer effectiveness,
- NTU is the Number of Transfer Units,
- Z is the ratio of minimum to maximum capacity flow rate and
- flowRegime is the heat exchanger flow regime.
- such as
- parallel flow, cross flow or counter flow.
+ The pipes' temperatures are not initialized, thus results of outflow temperature
+ before approximately the first 10000 seconds should not be considered.
+ Test bench schematic
+
+ Calibration
- The flow regimes depend on the heat exchanger configuration. All configurations
- defined in
-
- AixLib.Fluid.Types.HeatExchangerConfiguration
- are supported.
+ To calculate the length specific thermal resistance R of the pipe,
+ the thermal resistance of the surrounding ground is added.
-
- The convective heat transfer coefficients scale proportional to
- (ṁ/ṁ0)n, where
- ṁ is the mass flow rate,
- ṁ0 is the nominal mass flow rate, and
- n=0.8 on the air-side and n=0.85 on the water side.
+
+ R=1/(0.208)+1/(2 lambdag Modelica.Constants.pi) log(1/0.18)
- For a heat and moisture exchanger, use
-
- AixLib.Fluid.MassExchangers.ConstantEffectiveness.
+ Where the thermal conductivity of the ground lambda_g = 2.4 W/(m K).
-
- September 25, 2018, by Michael Wetter:
- Refactored model to use a common base class.
+ March 7, 2020, by Michael Wetter:
+ Replaced measured data from specification in Modelica file to external table,
+ as this reduces the computing time.
+ This is for
+ #1289.
+
+ -
+ May 15, 2019, by Jianjun Hu:
+ Replaced fluid source. This is for
+ #1072.
+
+ - November 28, 2016 by Bram van der Heijde:
Remove pipVol.
+
+ -
+ August 24, 2016 by Bram van der Heijde:
+ Implement validation with MSL pipes for comparison, based on AIT validation.
+
+ -
+ July 4, 2016 by Bram van der Heijde:
Added parameters to test the
+ influence of allowFlowReversal and the presence of explicit volumes in the pipe.
+ - January 26, 2016 by Carles Ribas:
First implementation.
-------- Corrected Code --------
- Model of a coil without humidity condensation. This model transfers
- heat in the amount of
+ The example contains
+ experimental data from a real district heating network. This data
+ is used to validate this library's plug flow
+ pipe model in
+ AixLib.Fluid.FixedResistances.Validation.PlugFlowPipes.PlugFlowAIT.
-
- Q̇ = Q̇max ε
- ε = f(NTU, Z, flowRegime),
+
+ Note that these three models are identical, except for the pipe model
+ that is used:
+
+
+
+ This comparison between different discretization levels and pipe
+ models is made to check the influence of the discretization and pipe
+ model on computation time and simulation accuracy.
- where Q̇max is the maximum heat that can be
- transferred, ε is the heat transfer effectiveness, NTU
- is the Number of Transfer Units, Z is the ratio of minimum to
- maximum capacity flow rate and flowRegime is the heat
- exchanger flow regime. such as parallel flow, cross flow or counter
- flow.
+ The pipes' temperatures are not initialized, thus results of outflow
+ temperature before approximately the first 10000 seconds should not
+ be considered.
+
+ Test bench schematic
+
- The flow regimes depend on the heat exchanger configuration. All
- configurations defined in AixLib.Fluid.Types.HeatExchangerConfiguration
- are supported.
+
+
+ Calibration
+
- The convective heat transfer coefficients scale proportional to
- (ṁ/ṁ0)n, where ṁ is the mass
- flow rate, ṁ0 is the nominal mass flow rate, and
- n=0.8 on the air-side and n=0.85 on the water side.
+ To calculate the length specific thermal resistance R of
+ the pipe, the thermal resistance of the surrounding ground is added.
+
+
+ R=1/(0.208)+1/(2 lambdag Modelica.Constants.pi)
+ log(1/0.18)
- For a heat and moisture exchanger, use AixLib.Fluid.MassExchangers.ConstantEffectiveness.
+ Where the thermal conductivity of the ground lambda_g =
+ 2.4 W/(m K).
- - September 25, 2018, by Michael Wetter:
- Refactored model to use a common base class.
+ - March 7, 2020, by Michael Wetter:
+ Replaced measured data from specification in Modelica file to
+ external table, as this reduces the computing time.
+ This is for #1289.
-
-
--------- Errors --------
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/BoundaryConditions/Validation/BESTEST/WD600.mo ----
--------- HTML Code --------
-
-
- -
- September 6, 2021, by Ettore Zanetti:
- Removed parameter lat as it is now obtained from the weather data bus.
- This is for
- IBPSA, #1477.
-
- -
- March 11, 2020, by Ettore Zanetti:
- First implementation.
-
- -
- April 14, 2020, by Ettore Zanetti:
- Rework after comments from pull request
- #1339.
-
-
-
- WD600: Ground Reflactance
- Weather data file : WD600.epw
- Table 1: Site Data for Weather file WD600.epw
-
- Latitude |
- 39.833° north |
-
-
- Longitude |
- 104.65° west |
-
-
- Altitude |
- 1650 m |
-
-
- Time Zone |
- -7 |
-
-
-
--------- Corrected Code --------
-
- - September 6, 2021, by Ettore Zanetti:
- Removed parameter lat as it is now obtained from the
- weather data bus.
- This is for IBPSA,
- #1477.
+ - May 15, 2019, by Jianjun Hu:
+ Replaced fluid source. This is for #1072.
- - March 11, 2020, by Ettore Zanetti:
- First implementation.
+ - November 28, 2016 by Bram van der Heijde:
+ Remove pipVol.
- - April 14, 2020, by Ettore Zanetti:
- Rework after comments from pull request #1339.
+ - August 24, 2016 by Bram van der Heijde:
+ Implement validation with MSL pipes for comparison, based on AIT
+ validation.
+
+ - July 4, 2016 by Bram van der Heijde:
+ Added parameters to test the influence of allowFlowReversal and the
+ presence of explicit volumes in the pipe.
+
+ - January 26, 2016 by Carles Ribas:
+ First implementation.
-
- WD600: Ground Reflactance
-
-
- Weather data file : WD600.epw
-
-
- Table 1: Site Data for Weather file WD600.epw
-
-
-
- |
-
- Latitude
-
- |
-
-
- 39.833° north
-
- |
-
-
- |
-
- Longitude
-
- |
-
-
- 104.65° west
-
- |
-
-
- |
-
- Altitude
-
- |
-
-
- 1650 m
-
- |
-
-
- |
-
- Time Zone
-
- |
-
-
- -7
-
- |
-
-
-------- Errors --------
-line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 51 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Media/Antifreeze/PropyleneGlycolWater.mo ----
+---- AixLib/Media/Specialized/Water/TemperatureDependentDensity.mo ----
-------- HTML Code --------
- This base properties model is identical to
-
- Modelica.Media.Water.ConstantPropertyLiquidWater,
- except that the equation
- u = cv_const*(T - reference_T)
- has been replaced by u=h because
- cp_const=cv_const.
- Also, the model checks if the mass fraction of the mixture is within the
- allowed limits.
+ Base properties of the medium.
-
- Density of propylene antifreeze-water mixture at specified mass fraction
- and temperature, based on Melinder (2010).
-
- References
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
- Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
- IIR/IIF.
-
-
-
-
- Dynamic viscosity of antifreeze-water mixture at specified mass fraction and
- temperature, based on Melinder (2010).
+ This function computes the density as a function of temperature.
- References
+ Implementation
- Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
- Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
- IIR/IIF.
+ The function is based on the IDA implementation in therpro.nmf, which
+ implements
+
+
+ d := 1000.12 + 1.43711e-2*T_degC -
+ 5.83576e-3*T_degC^2 + 1.5009e-5*T_degC^3;
+
+
+ This has been converted to Kelvin, which resulted in the above expression.
+ In addition, below 5 °C and above 100 °C, the density is replaced
+ by a linear function to avoid inflection points.
+ This linear extension is such that the density is once continuously differentiable.
-
- May 2, 2018 by Massimo Cimmino:
- First implementation.
- This function is used by
-
- AixLib.Media.Antifreeze.PropyleneGlycolWater.
+ December 18, 2013, by Michael Wetter:
+ First implementation, based on the IDA implementation in therpro.nmf,
+ but converted from Celsius to Kelvin and linearly extended.
- Fusion temperature of antifreeze-water mixture at specified mass fraction and
- temperature, based on Melinder (2010).
-
- References
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
- Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
- IIR/IIF.
+ This function computes the dynamic viscosity.
- Evaluates a thermophysical property of a mixture, based on correlations proposed
- by Melinder (2010).
-
-
- The polynomial has the form
-
-
- f = a1 (x-xm)0(y-ym)0
- + a2 (x-xm)0(y-ym)1
- + ... +
- any[1] (x-xm)0(y-ym)ny[1]-1
- + ... +
- any[1])+1 (x-xm)1(y-ym)0
- + ... +
- any[1]+ny[2] (x-xm)1(y-ym)ny[2]-1
- + ...
-
- References
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
- Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
- IIR/IIF.
+ This function computes the specific enthalpy.
-
- March 16, 2018 by Massimo Cimmino:
+ December 11, 2013, by Michael Wetter:
First implementation.
- This function is used models in
-
- AixLib.Media.Antifreeze.
- Specific heat capacity of antifreeze-water mixture at specified mass fraction
- and temperature, based on Melinder (2010).
-
- References
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
- Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
- IIR/IIF.
+ This function computes the specific enthalpy of liquid water.
- Thermal conductivity of antifreeze-water mixture at specified mass fraction and
- temperature, based on Melinder (2010).
+ This function computes the specific internal energy.
- References
+
+
+ -
+ December 11, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
- Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
- IIR/IIF.
+ This function computes the specific entropy.
+
+
+ To obtain the state for a given pressure, entropy and mass fraction, use
+
+ AixLib.Media.Air.setState_psX.
- This medium package models propylene glycol - water mixtures.
+ This function computes the specific Gibbs energy.
+
+
+ -
+ December 2, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- The mass density, specific heat capacity, thermal conductivity and viscosity
- are assumed constant and evaluated at a set temperature and mass fraction of
- propylene glycol within the mixture. The dependence of the four properties
- are shown on the figure below.
+ This function computes the specific Helmholtz energy.
-
- ![\"Relative](\"modelica://AixLib/Resources/Images/Media/Antifreeze/PropyleneGlycolWaterProperties.png\")
+
+
+ -
+ December 2, 2013, by Michael Wetter:
+ First implementation.
+
+
+
+
+ This function computes the specific enthalpy for
+ an isentropic state change from the temperature
+ that corresponds to the state refState
+ to reference_T.
+
+
+ -
+ December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- The accuracy of the thermophysical properties is dependent on the temperature
- variations encountered during simulations.
- The figure below shows the relative error of the the four properties over a
- 10 °C range around the temperature used to evaluate the constant
- properties. The maximum errors are 0.8 % for mass density, 1.5 %
- for specific heat capacity, 3.2 % for thermal conductivity and 250
- % for dynamic viscosity.
+ This function returns the isobaric expansion coefficient,
-
- ![\"Relative](\"modelica://AixLib/Resources/Images/Media/Antifreeze/PropyleneGlycolWaterError10degC.png\")
+
+ βp = - 1 ⁄ v (∂ v ⁄ ∂ T)p,
- The figure below shows the relative error of the the four properties over a
- 20 °C range around the temperature used to evaluate the constant
- proepties. The maximum errors are 1.6 % for mass density, 3.0 %
- for specific heat capacity, 6.2 % for thermal conductivity and 950
- % for dynamic viscosity.
-
-
- ![\"Relative](\"modelica://AixLib/Resources/Images/Media/Antifreeze/PropyleneGlycolWaterError20degC.png\")
+ where
+ v is the specific volume,
+ T is the temperature and
+ p is the pressure.
+
+
+ -
+ December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- The enthalpy is computed using the convention that h=0
- if T=0 °C.
+ This function returns the isothermal compressibility coefficient,
+ which is zero as this medium is incompressible.
+ The isothermal compressibility is defined as
+
+
+ κT = - 1 ⁄ v (∂ v ⁄ ∂ p)T,
- Limitations
- Density, specific heat capacity, thermal conductivity and viscosity are constant.
- The propylene glycol/water mixture is modeled as an incompressible liquid.
- There are no phase changes. The medium is limited to temperatures below
- 100 °C and mass fractions below 0.60.
- As is the case for AixLib.Media.Water,
- this medium package should not be used if
- the simulation relies on the dynamic viscosity.
+ where
+ v is the specific volume,
+ T is the temperature and
+ p is the pressure.
- Typical use and important parameters
+
+
+ -
+ December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- The temperature and mass fraction must be specified for the evaluation of the
- constant thermophysical properties. A typical use of the package is (e.g. for
- a temperature of 20 °C and a mass fraction of 0.40):
+ This function returns the partial derivative of density
+ with respect to pressure at constant temperature,
+ which is zero as the medium is incompressible.
+
+
+ -
+ December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- Medium = AixLib.Media.Antifreeze.PropyleneGlycolWater(property_T=293.15, X_a=0.40)
+ This function computes the derivative of density with respect to temperature
+ at constant pressure.
-
- October 26, 2018, by Filip Jorissen and Michael Wetter:
- Now printing different messages if temperature or mass fraction is above or below its limit,
- and adding instance name as JModelica does not print the full instance name in the assertion.
+ August 17, 2015, by Michael Wetter:
+ Removed dublicate entry of smooth and smoothOrder.
This is for
- #1045.
+ issue 303.
-
- March 16, 2018, by Massimo Cimmino:
+ December 18, 2013, by Michael Wetter:
+ First implementation, based on the IDA implementation in therpro.nmf,
+ but converted from Celsius to Kelvin.
+
+
+
+
+ This function returns the partial derivative of density
+ with respect to mass fraction,
+ which is zero as the medium is a single substance.
+
+
+
+ -
+ December 18, 2013, by Michael Wetter:
First implementation.
--------- Corrected Code --------
-
- This base properties model is identical to Modelica.Media.Water.ConstantPropertyLiquidWater,
- except that the equation u = cv_const*(T - reference_T)
- has been replaced by u=h because
- cp_const=cv_const. Also, the model checks if the mass
- fraction of the mixture is within the allowed limits.
-
-
- Density of propylene antifreeze-water mixture at specified mass
- fraction and temperature, based on Melinder (2010).
-
-
- References
-
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids
- (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
- Indirect Systems. Paris: IIR/IIF.
-
-
-
- Dynamic viscosity of antifreeze-water mixture at specified mass
- fraction and temperature, based on Melinder (2010).
-
-
- References
-
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids
- (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
- Indirect Systems. Paris: IIR/IIF.
-
-
-
- Fusion temperature of antifreeze-water mixture at specified mass
- fraction and temperature, based on Melinder (2010).
-
-
- References
-
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids
- (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
- Indirect Systems. Paris: IIR/IIF.
-
-
-
- Evaluates a thermophysical property of a mixture, based on
- correlations proposed by Melinder (2010).
-
-
- The polynomial has the form
-
-
- f = a1 (x-xm)0(y-ym)0 +
- a2 (x-xm)0(y-ym)1 + ... +
- any[1] (x-xm)0(y-ym)ny[1]-1 + ... +
- any[1])+1 (x-xm)1(y-ym)0 + ... +
- any[1]+ny[2] (x-xm)1(y-ym)ny[2]-1 +
- ...
-
-
- References
-
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids
- (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
- Indirect Systems. Paris: IIR/IIF.
-
-
- - March 16, 2018 by Massimo Cimmino:
- First implementation. This function is used models in AixLib.Media.Antifreeze.
-
-
-
- Specific heat capacity of antifreeze-water mixture at specified mass
- fraction and temperature, based on Melinder (2010).
-
-
- References
-
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids
- (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
- Indirect Systems. Paris: IIR/IIF.
-
-
-
- Thermal conductivity of antifreeze-water mixture at specified mass
- fraction and temperature, based on Melinder (2010).
-
-
- References
-
-
- Melinder, Åke. 2010. Properties of Secondary Working Fluids
- (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
- Indirect Systems. Paris: IIR/IIF.
-
-
-
- This medium package models propylene glycol - water mixtures.
-
-
- The mass density, specific heat capacity, thermal conductivity and
- viscosity are assumed constant and evaluated at a set temperature and
- mass fraction of propylene glycol within the mixture. The dependence
- of the four properties are shown on the figure below.
-
-
-
-
-
- The accuracy of the thermophysical properties is dependent on the
- temperature variations encountered during simulations. The figure
- below shows the relative error of the the four properties over a
- 10 °C range around the temperature used to evaluate the
- constant properties. The maximum errors are 0.8 % for mass
- density, 1.5 % for specific heat capacity, 3.2 % for
- thermal conductivity and 250 % for dynamic viscosity.
-
-
-
-
-
- The figure below shows the relative error of the the four properties
- over a 20 °C range around the temperature used to evaluate the
- constant proepties. The maximum errors are 1.6 % for mass
- density, 3.0 % for specific heat capacity, 6.2 % for
- thermal conductivity and 950 % for dynamic viscosity.
-
-
-
-
-
- The enthalpy is computed using the convention that h=0 if
- T=0 °C.
-
-
- Limitations
-
-
- Density, specific heat capacity, thermal conductivity and viscosity
- are constant. The propylene glycol/water mixture is modeled as an
- incompressible liquid. There are no phase changes. The medium is
- limited to temperatures below 100 °C and mass fractions below
- 0.60. As is the case for AixLib.Media.Water, this medium
- package should not be used if the simulation relies on the dynamic
- viscosity.
-
-
- Typical use and important parameters
-
-
- The temperature and mass fraction must be specified for the
- evaluation of the constant thermophysical properties. A typical use
- of the package is (e.g. for a temperature of 20 °C and a mass
- fraction of 0.40):
-
-
- Medium =
- AixLib.Media.Antifreeze.PropyleneGlycolWater(property_T=293.15,
- X_a=0.40)
-
-
- - October 26, 2018, by Filip Jorissen and Michael Wetter:
- Now printing different messages if temperature or mass fraction is
- above or below its limit, and adding instance name as JModelica
- does not print the full instance name in the assertion. This is for
- #1045.
-
- - March 16, 2018, by Massimo Cimmino:
- First implementation.
-
-
-
--------- Errors --------
-line 9 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
-line 11 column 2 - Warning: attribute "align" not allowed for HTML5
-line 24 column 2 - Warning: attribute "align" not allowed for HTML5
-line 35 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/BoundaryConditions/Validation/BESTEST/WD400.mo ----
--------- HTML Code --------
-
+
+ This function returns the specific heat capacity at constant pressure.
+
+
-
- September 6, 2021, by Ettore Zanetti:
- Removed parameter lat as it is now obtained from the weather data bus.
- This is for
- IBPSA, #1477.
+ December 11, 2013, by Michael Wetter:
+ First implementation.
+
+
+
+ This function computes the specific heat capacity at constant volume.
+
+
+
-
- March 11, 2020, by Ettore Zanetti:
+ December 11, 2013, by Michael Wetter:
First implementation.
+
+
+
+ This function returns the thermal conductivity.
+ The expression is obtained from Ramires et al. (1995).
+
+ References
+
+ Ramires, Maria L. V. and Nieto de Castro, Carlos A. and Nagasaka, Yuchi
+ and Nagashima, Akira and Assael, Marc J. and Wakeham, William A.
+ Standard Reference Data for the Thermal Conductivity of Water.
+ Journal of Physical and Chemical Reference Data, 24, p. 1377-1381, 1995.
+ DOI:10.1063/1.555963.
+
+
+
-
- April 14, 2020, by Ettore Zanetti:
- Rework after comments from pull request
- #1339.
+ December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
+
+ This function returns the pressure.
+
+
+
-
- May 2, 2021, by Ettore Zanetti:
- Updated weather file as explained in #1478.
+ December 18, 2013, by Michael Wetter:
+ First implementation.
- WD400: High Latitude Case
- Weather data file : WD400.epw
- Table 1: Site Data for Weather file WD400.epw
-
- Latitude |
- 71.286° north |
-
-
- Longitude |
- 156.767° west |
-
-
- Altitude |
- 10 m |
-
-
- Time Zone |
- -9 |
-
-
+
+ This function returns the temperature.
+
+
+
+ -
+ December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
--------- Corrected Code --------
-
- - September 6, 2021, by Ettore Zanetti:
- Removed parameter lat as it is now obtained from the
- weather data bus.
- This is for IBPSA,
- #1477.
-
- - March 11, 2020, by Ettore Zanetti:
- First implementation.
-
- - April 14, 2020, by Ettore Zanetti:
- Rework after comments from pull request #1339.
-
- - May 2, 2021, by Ettore Zanetti:
- Updated weather file as explained in #1478.
-
-
-
- WD400: High Latitude Case
-
-
- Weather data file : WD400.epw
-
-
- Table 1: Site Data for Weather file WD400.epw
-
-
-
- |
-
- Latitude
-
- |
-
-
- 71.286° north
-
- |
-
-
- |
-
- Longitude
-
- |
-
-
- 156.767° west
-
- |
-
-
- |
-
- Altitude
-
- |
-
-
- 10 m
-
- |
-
-
- |
-
- Time Zone
-
- |
-
-
- -9
-
- |
-
-
-
--------- Errors --------
-line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-
-
----- AixLib/Controls/Continuous/Examples/OffTimer.mo ----
--------- HTML Code --------
-
- Example that demonstrates the use of the model
-
- AixLib.Controls.Continuous.OffTimer.
- The input to the two timers are alternating boolean values.
- Whenever the input becomes false(=0), the timer is reset.
- The figures below show the input and output of the blocks.
-
-
-
-
+ This function returns the molar mass,
+ which is assumed to be constant.
-
- November 21, 2011, by Michael Wetter:
- Added documentation.
+ December 18, 2013, by Michael Wetter:
+ First implementation.
--------- Corrected Code --------
-
- Example that demonstrates the use of the model AixLib.Controls.Continuous.OffTimer.
- The input to the two timers are alternating boolean values. Whenever
- the input becomes false(=0), the timer is reset. The
- figures below show the input and output of the blocks.
-
-
-
-
-
-
- - November 21, 2011, by Michael Wetter:
- Added documentation.
-
-
-
--------- Errors --------
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/Chillers/Carnot_y.mo ----
--------- HTML Code --------
-
-
- This is model of a chiller whose coefficient of performance COP changes
- with temperatures in the same way as the Carnot efficiency changes.
- The input signal y is the control signal for the compressor.
-
-
- The model allows to either specify the Carnot effectivness
- ηCarnot,0, or
- a COP0
- at the nominal conditions, together with
- the evaporator temperature Teva,0 and
- the condenser temperature Tcon,0, in which
- case the model computes the Carnot effectivness as
-
-
- ηCarnot,0 =
- COP0
- ⁄ (Teva,0 ⁄ (Tcon,0-Teva,0)).
-
- The chiller COP is computed as the product
-
-
- COP = ηCarnot,0 COPCarnot ηPL,
+ This function returns the thermodynamic state for a given pressure,
+ specific enthalpy and composition.
+
+
+ -
+ December 11, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- where COPCarnot is the Carnot efficiency and
- ηPL is a polynomial in the cooling part load ratio yPL
- that can be used to take into account a change in COP at part load
- conditions.
- This polynomial has the form
-
-
- ηPL = a1 + a2 yPL + a3 yPL2 + ...
+ This function returns the thermodynamic state for a given pressure,
+ temperature and composition.
+
+
+ -
+ December 11, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- where the coefficients ai
- are declared by the parameter a.
+ This function returns the thermodynamic state based on pressure,
+ specific entropy and mass fraction.
- On the Dynamics tag, the model can be parametrized to compute a transient
- or steady-state response.
- The transient response of the model is computed using a first
- order differential equation for the evaporator and condenser fluid volumes.
- The chiller outlet temperatures are equal to the temperatures of these lumped volumes.
-
- Typical use and important parameters
+ The state is computed by symbolically solving
+
+ AixLib.Media.Specialized.Water.TemperatureDependentDensity.specificEntropy
+ for temperature.
+
+
+
+ -
+ April 11, 2016 by Michael Wetter:
+ Corrected wrong hyperlink in documentation for
+ issue 450.
+
+ -
+ December 11, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- When using this component, make sure that the evaporator and the condenser have sufficient mass flow rate.
- Based on the mass flow rates, the compressor power, temperature difference and the efficiencies,
- the model computes how much heat will be added to the condenser and removed at the evaporator.
- If the mass flow rates are too small, very high temperature differences can result.
+ This function computes the derivative of the specific heat capacity
+ at constant pressure with respect to the state.
+
+
+ -
+ December 11, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- The evaporator heat flow rate QEva_flow_nominal is used to assign
- the default value for the mass flow rates, which are used for the pressure drop
- calculations.
- It is also used to compute the part load efficiency.
- Hence, make sure that QEva_flow_nominal is set to a reasonable value.
+ This function computes the temperature derivative of the enthalpy of liquid water
+ per unit mass.
+
+
+ -
+ December 11, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- The maximum cooling capacity is set by the parameter QEva_flow_min,
- which is by default set to negative infinity.
+ This function computes the kinematic viscosity as a function of temperature.
+ Implementation
- The coefficient of performance depends on the
- evaporator and condenser leaving temperature
- since otherwise the second law of thermodynamics may be violated.
+ The function is based on the IDA implementation in therpro.nmf.
+ The original equation is
- Notes
+
+ kinVis :=1E-6*Modelica.Math.exp(0.577449 - 3.253945e-2*T_degC + 2.17369e-4*
+ T_degC^2 - 7.22111e-7*T_degC^3);
+
- For a similar model that can be used as a heat pump, see
- AixLib.Fluid.HeatPumps.Carnot_y.
+ This has been converted to Kelvin, which resulted in the above expression.
+ In addition, at 5 °C the kinematic viscosity is linearly extrapolated
+ to avoid a large gradient at very low temperatures.
+ We selected the same point for the linearization as we used for the density,
+ as the density and the kinematic viscosity are combined in
+
+ AixLib.Media.Specialized.Water.TemperatureDependentDensity.dynamicViscosity.
-
- January 2, 2017, by Filip Jorissen:
- Removed parameters
- effInpEva and effInpCon
- and updated documentation.
- This is for
-
- issue 497.
+ April 11, 2016 by Michael Wetter:
+ Corrected wrong hyperlink in documentation for
+ issue 450.
-
- August 8, 2016, by Michael Wetter:
- Changed default temperature to compute COP to be the leaving temperature as
- use of the entering temperature can violate the 2nd law if the temperature
- lift is small.
- This is for
-
- Annex 60, issue 497.
-
- -
- January 26, 2016, by Michael Wetter:
- Refactored model to use the same base class as
- AixLib.Fluid.HeatPumps.Carnot_y.
-
- Changed part load efficiency to depend on cooling part load ratio rather than on the compressor
- part load ratio.
- Changed sign convention of dTEva_nominal to be negative rather than positive.
- For positive values, the simulation will stop with an assertion.
+ December 18, 2013, by Michael Wetter:
+ First implementation, based on the IDA implementation in therpro.nmf,
+ but converted from Celsius to Kelvin.
+
+
+
+ This medium package models liquid water.
+
+
+ The mass density is computed using a 3rd order polynomial, which yields the
+ density as a function of temperature as shown in the figure below. Note, however,
+ that computing density as a function of temperature can lead to considerably
+ slower computing time compared to using
+
+ AixLib.Media.Water
+ in which the density is a constant. We therefore recommend to use
+
+ AixLib.Media.Water
+ for typical building energy simulations.
+
+
+ ![\"Mass](\"modelica://AixLib/Resources/Images/Media/Water/plotRho.png\")
+
+
+ For the specific heat capacities at constant pressure and at constant volume,
+ a constant value of 4184 J/(kg K), which corresponds to 20°C
+ is used.
+ The figure below shows the relative error of the specific heat capacity that
+ is introduced by this simplification.
+ Using a constant value for the specific heat capacity allows to compute
+ temperature from enthalpy without having to solve an implicit equation,
+ and therefore leads to faster simulation.
+
+
+
+
+
+
+
+ Thermal conductivity is calculated as a function of temperature as shown in the figure below.
+ The correlation used to calculate the thermal conductivity is
+
+
+
+ λ(T) = λ(298.15 K) ⋅ (-1.48445+4.12292⋅(T/298.15)-1.63866⋅(T/298.15)2),
+
+
+ where λ(298.15 K) = 0.6065 W/(m ⋅ K) is the adopted standard value
+ of the thermal conductivity of water at 298.15 K and 0.1 MPa.
+
+
+ ![\"Thermal](\"modelica://AixLib/Resources/Images/Media/Water/plotLambda.png\")
+
+
+
+ Dynamic viscosity is calculated as the product of density and kinematic viscosity,
+ both temperature dependent. However, the kinematic viscosity
+ has its own temperature dependent correlation, implemented at
+
+ AixLib.Media.Specialized.Water.TemperatureDependentDensity.kinematicViscosity.
+ Results of the kinematic viscosity as a function of temperature are shown in the figure below.
+
+
+ ![\"Kinematic](\"modelica://AixLib/Resources/Images/Media/Water/plotkinVis.png\")
+
+
+
+ The enthalpy is computed using the convention that h=0
+ if T=0 °C.
+
+ Limitations
+
+ Phase changes are not modeled.
+
+
+
-
- December 18, 2015, by Michael Wetter:
- Corrected wrong computation of staB1 and staB2
- which mistakenly used the inStream operator
- for the configuration without flow reversal.
+ April 5, 2022, by Michael Wetter:
+ Corrected assignment of R_s in BaseProperties to avoid a unit error.
This is for
-
- issue 476.
+ #1603.
-
- November 25, 2015 by Michael Wetter:
- Changed sign convention for dTEva_nominal to be consistent with
- other models.
- The model will still work with the old values for dTEva_nominal,
- but it will write a warning so that users can transition their models.
-
- Corrected assert statement for the efficiency curve.
+ July 7, 2016, by Carles Ribas Tugores:
+ Correct Documentation. This is for
+ #487.
+
+ -
+ June 6, 2015, by Michael Wetter:
+ Set AbsolutePressure(start=p_default)
+ and Temperature(start=T_default)
+ to have to have conistent start values.
+ See also revision notes of
+
+ AixLib.Media.Water.
This is for
-
- issue 468.
+ #266.
-
- September 3, 2015 by Michael Wetter:
- Expanded documentation.
+ May 1, 2015, by Michael Wetter:
+ Added Inline=true for
+
+ issue 227.
-
- May 6, 2015 by Michael Wetter:
- Added prescribedHeatFlowRate=true for vol2.
+ February 25, 2015, by Michael Wetter:
+ Removed stateSelect attribute on pressure as this caused
+
+ AixLib.Examples.Tutorial.SpaceCooling.System3
+ to fail with the error message
+ \"differentiated if-then-else was not continuous\".
-
- October 9, 2013 by Michael Wetter:
- Reimplemented the computation of the port states to avoid using
- the conditionally removed variables sta_a1,
- sta_a2, sta_b1 and sta_b2.
+ February 3, 2015, by Michael Wetter:
+ Removed stateSelect.prefer for temperature.
+ This is for
+ #160.
-
- May 10, 2013 by Michael Wetter:
- Added electric power P as an output signal.
+ October 15, 2014, by Michael Wetter:
+ Renamed from AixLib.Media.Water to
+ AixLib.Media.Water.Detailed to allow addition of
+ AixLib.Media.Water.Simple.
-
- October 11, 2010 by Michael Wetter:
- Fixed bug in energy balance.
+ September 12, 2014, by Michael Wetter:
+ Set T(start=T_default) and p(start=p_default) in the
+ ThermodynamicState record. Setting the start value for
+ T is required to avoid an error due to conflicting start values
+ when checking
+ AixLib.Examples.VAVReheat.ClosedLoop in pedantic mode.
-
- March 3, 2009 by Michael Wetter:
+ December 18, 2013, by Michael Wetter:
First implementation.
-------- Corrected Code --------
- This is model of a chiller whose coefficient of performance COP
- changes with temperatures in the same way as the Carnot efficiency
- changes. The input signal y is the control signal for the
- compressor.
+ Base properties of the medium.
- The model allows to either specify the Carnot effectivness
- ηCarnot,0, or a COP0 at the
- nominal conditions, together with the evaporator temperature
- Teva,0 and the condenser temperature
- Tcon,0, in which case the model computes the Carnot
- effectivness as
-
-
- ηCarnot,0 = COP0 ⁄ (Teva,0 ⁄
- (Tcon,0-Teva,0)).
+ This function computes the density as a function of temperature.
+
+ Implementation
+
- The chiller COP is computed as the product
-
-
- COP = ηCarnot,0 COPCarnot ηPL,
+ The function is based on the IDA implementation in
+ therpro.nmf, which implements
+
+ d := 1000.12 + 1.43711e-2*T_degC -
+ 5.83576e-3*T_degC^2 + 1.5009e-5*T_degC^3;
+
- where COPCarnot is the Carnot efficiency and
- ηPL is a polynomial in the cooling part load ratio
- yPL that can be used to take into account a change
- in COP at part load conditions. This polynomial has the form
-
-
- ηPL = a1 + a2 yPL +
- a3 yPL2 + ...
+ This has been converted to Kelvin, which resulted in the above
+ expression. In addition, below 5 °C and above 100 °C, the density is
+ replaced by a linear function to avoid inflection points. This linear
+ extension is such that the density is once continuously
+ differentiable.
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation, based on the IDA implementation in
+ therpro.nmf, but converted from Celsius to Kelvin and
+ linearly extended.
+
+
- where the coefficients ai are declared by the
- parameter a.
+ This function computes the dynamic viscosity.
+
+ - December 2, 2013, by Michael Wetter:
+ First implementation.
+
+
- On the Dynamics tag, the model can be parametrized to
- compute a transient or steady-state response. The transient response
- of the model is computed using a first order differential equation
- for the evaporator and condenser fluid volumes. The chiller outlet
- temperatures are equal to the temperatures of these lumped volumes.
+ This function computes the specific enthalpy.
-
- Typical use and important parameters
-
+
+ - December 11, 2013, by Michael Wetter:
+ First implementation.
+
+
- When using this component, make sure that the evaporator and the
- condenser have sufficient mass flow rate. Based on the mass flow
- rates, the compressor power, temperature difference and the
- efficiencies, the model computes how much heat will be added to the
- condenser and removed at the evaporator. If the mass flow rates are
- too small, very high temperature differences can result.
+ This function computes the specific enthalpy of liquid water.
+
+ - December 2, 2013, by Michael Wetter:
+ First implementation.
+
+
- The evaporator heat flow rate QEva_flow_nominal is used
- to assign the default value for the mass flow rates, which are used
- for the pressure drop calculations. It is also used to compute the
- part load efficiency. Hence, make sure that
- QEva_flow_nominal is set to a reasonable value.
+ This function computes the specific internal energy.
+
+ - December 11, 2013, by Michael Wetter:
+ First implementation.
+
+
- The maximum cooling capacity is set by the parameter
- QEva_flow_min, which is by default set to negative
- infinity.
+ This function computes the specific entropy.
- The coefficient of performance depends on the evaporator and
- condenser leaving temperature since otherwise the second law of
- thermodynamics may be violated.
+ To obtain the state for a given pressure, entropy and mass fraction,
+ use AixLib.Media.Air.setState_psX.
-
- Notes
-
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
- For a similar model that can be used as a heat pump, see AixLib.Fluid.HeatPumps.Carnot_y.
+ This function computes the specific Gibbs energy.
- - January 2, 2017, by Filip Jorissen:
- Removed parameters effInpEva and
- effInpCon and updated documentation. This is for
- issue
- 497.
+ - December 2, 2013, by Michael Wetter:
+ First implementation.
- - August 8, 2016, by Michael Wetter:
- Changed default temperature to compute COP to be the leaving
- temperature as use of the entering temperature can violate the 2nd
- law if the temperature lift is small.
- This is for Annex 60,
- issue 497.
+
+
+ This function computes the specific Helmholtz energy.
+
+
+ - December 2, 2013, by Michael Wetter:
+ First implementation.
- - January 26, 2016, by Michael Wetter:
- Refactored model to use the same base class as AixLib.Fluid.HeatPumps.Carnot_y.
-
- Changed part load efficiency to depend on cooling part load ratio
- rather than on the compressor part load ratio.
- Changed sign convention of dTEva_nominal to be
- negative rather than positive. For positive values, the simulation
- will stop with an assertion.
+
+
+ This function computes the specific enthalpy for an isentropic state
+ change from the temperature that corresponds to the state
+ refState to reference_T.
+
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
- - December 18, 2015, by Michael Wetter:
- Corrected wrong computation of staB1 and
- staB2 which mistakenly used the inStream
- operator for the configuration without flow reversal. This is for
- issue
- 476.
+
+
+ This function returns the isobaric expansion coefficient,
+
+
+ βp = - 1 ⁄ v (∂ v ⁄ ∂ T)p,
+
+
+ where v is the specific volume, T is the temperature
+ and p is the pressure.
+
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
- - November 25, 2015 by Michael Wetter:
- Changed sign convention for dTEva_nominal to be
- consistent with other models. The model will still work with the
- old values for dTEva_nominal, but it will write a
- warning so that users can transition their models.
- Corrected assert statement for the efficiency curve.
- This is for issue
- 468.
+
+
+ This function returns the isothermal compressibility coefficient,
+ which is zero as this medium is incompressible. The isothermal
+ compressibility is defined as
+
+
+ κT = - 1 ⁄ v (∂ v ⁄ ∂ p)T,
+
+
+ where v is the specific volume, T is the temperature
+ and p is the pressure.
+
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
- - September 3, 2015 by Michael Wetter:
- Expanded documentation.
+
+
+ This function returns the partial derivative of density with respect
+ to pressure at constant temperature, which is zero as the medium is
+ incompressible.
+
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
- - May 6, 2015 by Michael Wetter:
- Added prescribedHeatFlowRate=true for
- vol2.
+
+
+ This function computes the derivative of density with respect to
+ temperature at constant pressure.
+
+
+ - August 17, 2015, by Michael Wetter:
+ Removed dublicate entry of smooth and
+ smoothOrder. This is for issue 303.
- - October 9, 2013 by Michael Wetter:
- Reimplemented the computation of the port states to avoid using the
- conditionally removed variables sta_a1,
- sta_a2, sta_b1 and sta_b2.
+ - December 18, 2013, by Michael Wetter:
+ First implementation, based on the IDA implementation in
+ therpro.nmf, but converted from Celsius to Kelvin.
- - May 10, 2013 by Michael Wetter:
- Added electric power P as an output signal.
+
+
+ This function returns the partial derivative of density with respect
+ to mass fraction, which is zero as the medium is a single substance.
+
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
- - October 11, 2010 by Michael Wetter:
- Fixed bug in energy balance.
+
+
+ This function returns the specific heat capacity at constant
+ pressure.
+
+
+ - December 11, 2013, by Michael Wetter:
+ First implementation.
- - March 3, 2009 by Michael Wetter:
+
+
+ This function computes the specific heat capacity at constant volume.
+
+
+ - December 11, 2013, by Michael Wetter:
First implementation.
-
--------- Errors --------
-line 16 column 2 - Warning: attribute "align" not allowed for HTML5
-line 24 column 2 - Warning: attribute "align" not allowed for HTML5
-line 34 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Media/Specialized/Air/PerfectGas.mo ----
--------- HTML Code --------
-
- Function to set the state for given pressure, enthalpy and species concentration.
-
- The thermodynamic state record
- is computed from density d, temperature T and composition X.
-
- Saturation pressure of water above the triple point temperature is computed from temperature. It's range of validity is between
- 273.16 and 373.16 K. Outside these limits a less accurate result is returned.
-
- Derivative function of
-
- AixLib.Media.Specialized.Air.PerfectGas.saturationPressureLiquid
-
- Pressure is returned from the thermodynamic state record input as a simple assignment.
-
- Temperature is returned from the thermodynamic state record input as a simple assignment.
-
- Density is computed from pressure, temperature and composition in the thermodynamic state record applying the ideal gas law.
-
- Specific entropy is calculated from the thermodynamic state record, assuming ideal gas behavior and including entropy of mixing. Liquid or solid water is not taken into account, the entire water content X[1] is assumed to be in the vapor state (relative humidity below 1.0).
-
- Temperature as a function of specific enthalpy and species concentration.
- The pressure is input for compatibility with the medium models, but the temperature
- is independent of the pressure.
-
-
- This data record contains the coefficients for perfect gases.
-
-
-
- -
- June 6, 2015, by Michael Wetter:
- Set AbsolutePressure(start=p_default)
- and Temperature(start=T_default)
- to have to have conistent start values.
- See also revision notes of
-
- AixLib.Media.Water.
- This is for
- #266.
-
- -
- May 1, 2015, by Michael Wetter:
- Added Inline=true for
-
- issue 227.
-
- -
- September 12, 2014, by Michael Wetter:
- Corrected the wrong location of the preferredView
- and the revisions annotation.
-
- -
- November 21, 2013, by Michael Wetter:
- First implementation.
-
-
-
-
- This package contains a thermally perfect model of moist air.
-
-
- A medium is called thermally perfect if
-
-
- -
- it is in thermodynamic equilibrium,
-
-
- it is chemically not reacting, and
-
-
- internal energy and enthalpy are functions of temperature only.
-
-
-
- In addition, this medium model is calorically perfect, i.e., the
- specific heat capacities at constant pressure cp
- and constant volume cv are both constant (Bower 1998).
-
-
- This medium uses the ideal gas law
-
-
- ρ = p ⁄(R T),
-
-
- where
- ρ is the density,
- p is the pressure,
- R is the gas constant and
- T is the temperature.
-
-
- The enthalpy is computed using the convention that h=0
- if T=0 °C and no water vapor is present.
-
-
- Note that for typical building simulations, the media
- AixLib.Media.Air
- should be used as it leads generally to faster simulation.
-
- References
-
- Bower, William B. A primer in fluid mechanics: Dynamics of flows in one
- space dimension. CRC Press. 1998.
-
-
-
- -
- October 26, 2018, by Filip Jorissen and Michael Wetter:
- Now printing different messages if temperature is above or below its limit,
- and adding instance name as JModelica does not print the full instance name in the assertion.
- This is for
- #1045.
-
- -
- March 15, 2016, by Michael Wetter:
- Replaced spliceFunction with regStep.
- This is for
- issue 300.
-
- -
- November 13, 2014, by Michael Wetter:
- Removed phi and removed non-required computations.
-
- -
- March 29, 2013, by Michael Wetter:
- Added final standardOrderComponents=true in the
- BaseProperties declaration. This avoids an error
- when models are checked in Dymola 2014 in the pedenatic mode.
-
- -
- April 12, 2012, by Michael Wetter:
- Added keyword each to Xi(stateSelect=...).
-
- -
- April 4, 2012, by Michael Wetter:
- Added redeclaration of ThermodynamicState to avoid a warning
- during model check and translation.
-
- -
- January 27, 2010, by Michael Wetter:
- Added function enthalpyOfNonCondensingGas and its derivative.
-
- -
- January 27, 2010, by Michael Wetter:
- Fixed bug with temperature offset in T_phX.
-
- -
- August 18, 2008, by Michael Wetter:
- First implementation.
-
-
-
--------- Corrected Code --------
-Function to set the state for given pressure, enthalpy and species
-concentration.
-The thermodynamic state record is computed from density d, temperature
-T and composition X.
-Saturation pressure of water above the triple point temperature is
-computed from temperature. It's range of validity is between 273.16 and
-373.16 K. Outside these limits a less accurate result is returned.
-Derivative function of
-AixLib.Media.Specialized.Air.PerfectGas.saturationPressureLiquid
-Pressure is returned from the thermodynamic state record input as a
-simple assignment.
-Temperature is returned from the thermodynamic state record input as a
-simple assignment.
-Density is computed from pressure, temperature and composition in the
-thermodynamic state record applying the ideal gas law.
-Specific entropy is calculated from the thermodynamic state record,
-assuming ideal gas behavior and including entropy of mixing. Liquid or
-solid water is not taken into account, the entire water content X[1] is
-assumed to be in the vapor state (relative humidity below 1.0).
-Temperature as a function of specific enthalpy and species
-concentration. The pressure is input for compatibility with the medium
-models, but the temperature is independent of the pressure.
- This data record contains the coefficients for perfect gases.
+ This function returns the thermal conductivity. The expression is
+ obtained from Ramires et al. (1995).
+
+
+ References
+
+
+ Ramires, Maria L. V. and Nieto de Castro, Carlos A. and Nagasaka,
+ Yuchi and Nagashima, Akira and Assael, Marc J. and Wakeham, William
+ A. Standard Reference Data for the Thermal Conductivity of Water.
+ Journal of Physical and Chemical Reference Data, 24, p.
+ 1377-1381, 1995. DOI:10.1063/1.555963.
- - June 6, 2015, by Michael Wetter:
- Set AbsolutePressure(start=p_default) and
- Temperature(start=T_default) to have to have conistent
- start values. See also revision notes of AixLib.Media.Water. This is for
- #266.
-
- - May 1, 2015, by Michael Wetter:
- Added Inline=true for issue 227.
-
- - September 12, 2014, by Michael Wetter:
- Corrected the wrong location of the preferredView and
- the revisions annotation.
-
- - November 21, 2013, by Michael Wetter:
+ - December 18, 2013, by Michael Wetter:
First implementation.
- This package contains a thermally perfect model of moist air.
-
-
- A medium is called thermally perfect if
+ This function returns the pressure.
- - it is in thermodynamic equilibrium,
-
- - it is chemically not reacting, and
-
- - internal energy and enthalpy are functions of temperature only.
+
- December 18, 2013, by Michael Wetter:
+ First implementation.
- In addition, this medium model is calorically perfect, i.e.,
- the specific heat capacities at constant pressure
- cp and constant volume cv are
- both constant (Bower 1998).
+ This function returns the temperature.
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
- This medium uses the ideal gas law
-
-
- ρ = p ⁄(R T),
+ This function returns the molar mass, which is assumed to be
+ constant.
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
- where ρ is the density, p is the pressure, R is
- the gas constant and T is the temperature.
+ This function returns the thermodynamic state for a given pressure,
+ specific enthalpy and composition.
+
+ - December 11, 2013, by Michael Wetter:
+ First implementation.
+
+
- The enthalpy is computed using the convention that h=0 if
- T=0 °C and no water vapor is present.
+ This function returns the thermodynamic state for a given pressure,
+ temperature and composition.
+
+ - December 11, 2013, by Michael Wetter:
+ First implementation.
+
+
- Note that for typical building simulations, the media AixLib.Media.Air should be used as
- it leads generally to faster simulation.
+ This function returns the thermodynamic state based on pressure,
+ specific entropy and mass fraction.
-
- References
-
- Bower, William B. A primer in fluid mechanics: Dynamics of flows
- in one space dimension. CRC Press. 1998.
+ The state is computed by symbolically solving
+ AixLib.Media.Specialized.Water.TemperatureDependentDensity.specificEntropy
+ for temperature.
- - October 26, 2018, by Filip Jorissen and Michael Wetter:
- Now printing different messages if temperature is above or below
- its limit, and adding instance name as JModelica does not print the
- full instance name in the assertion. This is for #1045.
-
- - March 15, 2016, by Michael Wetter:
- Replaced spliceFunction with regStep.
- This is for issue 300.
-
- - November 13, 2014, by Michael Wetter:
- Removed phi and removed non-required computations.
-
- - March 29, 2013, by Michael Wetter:
- Added final standardOrderComponents=true in the
- BaseProperties declaration. This avoids an error when
- models are checked in Dymola 2014 in the pedenatic mode.
-
- - April 12, 2012, by Michael Wetter:
- Added keyword each to
- Xi(stateSelect=...).
-
- - April 4, 2012, by Michael Wetter:
- Added redeclaration of ThermodynamicState to avoid a
- warning during model check and translation.
-
- - January 27, 2010, by Michael Wetter:
- Added function enthalpyOfNonCondensingGas and its
- derivative.
-
- - January 27, 2010, by Michael Wetter:
- Fixed bug with temperature offset in T_phX.
+ - April 11, 2016 by Michael Wetter:
+ Corrected wrong hyperlink in documentation for issue 450.
- - August 18, 2008, by Michael Wetter:
+ - December 11, 2013, by Michael Wetter:
First implementation.
-
--------- Errors --------
-line 25 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Utilities/Math/Biquadratic.mo ----
--------- HTML Code --------
-
-
- This block computes
-
-
- y = a1 + a2 x1
- + a3 x12
- + a4 x2 + a5 x22
- + a6 x1 x2
-
-
-
- -
- Sep. 8, 2010, by Michael Wetter:
- First implementation.
-
-
-
--------- Corrected Code --------
- This block computes
-
-
- y = a1 + a2 x1 + a3
- x12 + a4 x2 +
- a5 x22 + a6 x1
- x2
+ This function computes the derivative of the specific heat capacity
+ at constant pressure with respect to the state.
- - Sep. 8, 2010, by Michael Wetter:
+ - December 11, 2013, by Michael Wetter:
First implementation.
-
--------- Errors --------
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/Actuators/Valves/ThreeWayTable.mo ----
--------- HTML Code --------
-
-
- Three way valve with table-specified opening characteristics.
- A separate characteristic for each flow path is used.
-
-
- Each flow path uses an instance of the model
-
- AixLib.Fluid.Actuators.Valves.TwoWayTable.
- Therefore, this model needs to be parameterized the same way as
-
- AixLib.Fluid.Actuators.Valves.TwoWayTable.
- Specifically,
- the mass flow rate for the fully open valve is determined based
- on the value of the parameter CvData.
- For the different valve positions y ∈ [0, 1], this nominal flow rate is
- scaled by the values of the parameter
- flowCharacteristics1 and flowCharacteristics3, respectively.
- These parameters declare a table of the form
-
-
-
- | y | 0 | ... | 1 |
-
-
- | φ | l | ... | 1 |
-
-
-
- where l = Kv(y=0)/Kv(y=1) > 0 is the valve leakage.
- The first row is the valve opening, and the second row is the
- mass flow rate, relative to the mass flow rate of the fully open
- valve, under the assumption of a constant pressure difference across the
- valve.
- A suggested value for the valve leakage is l=0.0001.
- If l = 0, then this model will replace it with
- l = 10-8 for numerical reasons.
- For example, if a valve has Kv=0.5 [m3/h/bar1/2] and
- a linear opening characteristics and
- a valve leakage of l=0.0001, then one would set
-
-
- CvData=AixLib.Fluid.Types.CvTypes.Kv
- Kv = 0.5
- flowCharacteristics1(y={0,1}, phi={0.0001,1})
- flowCharacteristics3(y={0,1}, phi={0.0001,1})
-
-
- Note, however, that
-
- AixLib.Fluid.Actuators.Valves.ThreeWayLinear provides a more
- efficient implementation for this simple case.
-
-
- The parameters flowCharacteristics1 and flowCharacteristics3 must meet the following
- requirements, otherwise the model stops with an error:
-
-
- -
- Their arrays
-
y and phi
- must be strictly monotonic increasing.
-
- -
- The first value must satisfy
-
y[1]=0, and
- phi[1] must be equal to the
- leakage flow rate, which must be bigger than zero.
- Otherwise, a default value of 1E-8 is used.
-
- -
- The last values must satisfy
-
y[end]=1 and
- phi[end]=1.
-
-
-
- This model is based on the partial valve model
-
- AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve.
- Check this model for more information, such
- as the regularization near the origin.
-
-
- For an example that specifies an opening characteristics, see
-
- AixLib.Fluid.Actuators.Valves.Examples.TwoWayValveTable.
-
-
-
-
- -
- March 7, 2022, by Michael Wetter:
- Set final massDynamics=energyDynamics.
- This is for
- #1542.
-
- -
- June 10, 2021, by Michael Wetter:
- Changed implementation of the filter and changed the parameter order to a constant
- as most users need not change this value.
- This is for
- #1498.
-
- -
- November 28, 2019, by Michael Wetter:
- Revised implementation.
-
- -
- November 15, 2019, by Alexander Kümpel:
- First implementation.
-
-
-
--------- Corrected Code --------
- Three way valve with table-specified opening characteristics. A
- separate characteristic for each flow path is used.
+ This function computes the temperature derivative of the enthalpy of
+ liquid water per unit mass.
+
+ - December 11, 2013, by Michael Wetter:
+ First implementation.
+
+
- Each flow path uses an instance of the model AixLib.Fluid.Actuators.Valves.TwoWayTable.
- Therefore, this model needs to be parameterized the same way as
- AixLib.Fluid.Actuators.Valves.TwoWayTable.
- Specifically, the mass flow rate for the fully open valve is
- determined based on the value of the parameter CvData.
- For the different valve positions y ∈ [0, 1], this nominal
- flow rate is scaled by the values of the parameter
- flowCharacteristics1 and
- flowCharacteristics3, respectively. These parameters
- declare a table of the form
+ This function computes the kinematic viscosity as a function of
+ temperature.
-
-
- |
- y
- |
-
- 0
- |
-
- ...
- |
-
- 1
- |
-
-
- |
- φ
- |
-
- l
- |
-
- ...
- |
-
- 1
- |
-
-
+
+ Implementation
+
- where l = Kv(y=0)/Kv(y=1) > 0 is the
- valve leakage. The first row is the valve opening, and the second row
- is the mass flow rate, relative to the mass flow rate of the fully
- open valve, under the assumption of a constant pressure difference
- across the valve. A suggested value for the valve leakage is
- l=0.0001. If l = 0, then this model will replace it
- with l = 10-8 for numerical reasons. For example,
- if a valve has Kv=0.5
- [m3/h/bar1/2] and a linear opening
- characteristics and a valve leakage of l=0.0001, then one
- would set
+ The function is based on the IDA implementation in
+ therpro.nmf. The original equation is
- CvData=AixLib.Fluid.Types.CvTypes.Kv
- Kv = 0.5
- flowCharacteristics1(y={0,1}, phi={0.0001,1})
- flowCharacteristics3(y={0,1}, phi={0.0001,1})
-
-
- Note, however, that AixLib.Fluid.Actuators.Valves.ThreeWayLinear
- provides a more efficient implementation for this simple case.
-
+ kinVis :=1E-6*Modelica.Math.exp(0.577449 - 3.253945e-2*T_degC + 2.17369e-4*
+ T_degC^2 - 7.22111e-7*T_degC^3);
+
- The parameters flowCharacteristics1 and
- flowCharacteristics3 must meet the following
- requirements, otherwise the model stops with an error:
+ This has been converted to Kelvin, which resulted in the above
+ expression. In addition, at 5 °C the kinematic viscosity is linearly
+ extrapolated to avoid a large gradient at very low temperatures. We
+ selected the same point for the linearization as we used for the
+ density, as the density and the kinematic viscosity are combined in
+
+ AixLib.Media.Specialized.Water.TemperatureDependentDensity.dynamicViscosity.
- - Their arrays
y and phi must be strictly
- monotonic increasing.
-
- - The first value must satisfy
y[1]=0, and
- phi[1] must be equal to the leakage flow rate, which
- must be bigger than zero. Otherwise, a default value of
- 1E-8 is used.
+ - April 11, 2016 by Michael Wetter:
+ Corrected wrong hyperlink in documentation for issue 450.
- - The last values must satisfy
y[end]=1 and
- phi[end]=1.
+ - December 18, 2013, by Michael Wetter:
+ First implementation, based on the IDA implementation in
+ therpro.nmf, but converted from Celsius to Kelvin.
- This model is based on the partial valve model AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve.
- Check this model for more information, such as the regularization
- near the origin.
+ This medium package models liquid water.
- For an example that specifies an opening characteristics, see
-
- AixLib.Fluid.Actuators.Valves.Examples.TwoWayValveTable.
+ The mass density is computed using a 3rd order polynomial, which
+ yields the density as a function of temperature as shown in the
+ figure below. Note, however, that computing density as a function of
+ temperature can lead to considerably slower computing time compared
+ to using AixLib.Media.Water in which the
+ density is a constant. We therefore recommend to use AixLib.Media.Water for typical
+ building energy simulations.
-
- - March 7, 2022, by Michael Wetter:
- Set final massDynamics=energyDynamics.
- This is for #1542.
-
- - June 10, 2021, by Michael Wetter:
- Changed implementation of the filter and changed the parameter
- order to a constant as most users need not change this
- value.
- This is for #1498.
+
+
+
+
+ For the specific heat capacities at constant pressure and at constant
+ volume, a constant value of 4184 J/(kg K), which corresponds
+ to 20°C is used. The figure below shows the relative error of
+ the specific heat capacity that is introduced by this simplification.
+ Using a constant value for the specific heat capacity allows to
+ compute temperature from enthalpy without having to solve an implicit
+ equation, and therefore leads to faster simulation.
+
+
+
+
+
+ Thermal conductivity is calculated as a function of temperature as
+ shown in the figure below. The correlation used to calculate the
+ thermal conductivity is
+
+
+ λ(T) = λ(298.15 K) ⋅
+ (-1.48445+4.12292⋅(T/298.15)-1.63866⋅(T/298.15)2),
+
+
+ where λ(298.15 K) = 0.6065 W/(m ⋅ K) is the adopted standard
+ value of the thermal conductivity of water at 298.15 K and
+ 0.1 MPa.
+
+
+
+
+
+ Dynamic viscosity is calculated as the product of density and
+ kinematic viscosity, both temperature dependent. However, the
+ kinematic viscosity has its own temperature dependent correlation,
+ implemented at
+ AixLib.Media.Specialized.Water.TemperatureDependentDensity.kinematicViscosity.
+ Results of the kinematic viscosity as a function of temperature are
+ shown in the figure below.
+
+
+
+
+
+ The enthalpy is computed using the convention that h=0 if
+ T=0 °C.
+
+
+ Limitations
+
+
+ Phase changes are not modeled.
+
+
+ - April 5, 2022, by Michael Wetter:
+ Corrected assignment of R_s in
+ BaseProperties to avoid a unit error.
+ This is for #1603.
- - November 28, 2019, by Michael Wetter:
- Revised implementation.
+ - July 7, 2016, by Carles Ribas Tugores:
+ Correct Documentation. This is for #487.
- - November 15, 2019, by Alexander Kümpel:
+ - June 6, 2015, by Michael Wetter:
+ Set AbsolutePressure(start=p_default) and
+ Temperature(start=T_default) to have to have conistent
+ start values. See also revision notes of AixLib.Media.Water. This is for
+ #266.
+
+ - May 1, 2015, by Michael Wetter:
+ Added Inline=true for issue 227.
+
+ - February 25, 2015, by Michael Wetter:
+ Removed stateSelect attribute on pressure as this
+ caused AixLib.Examples.Tutorial.SpaceCooling.System3
+ to fail with the error message \"differentiated if-then-else was not
+ continuous\".
+
+ - February 3, 2015, by Michael Wetter:
+ Removed stateSelect.prefer for temperature. This is
+ for #160.
+
+ - October 15, 2014, by Michael Wetter:
+ Renamed from AixLib.Media.Water to
+ AixLib.Media.Water.Detailed to allow addition of
+ AixLib.Media.Water.Simple.
+
+ - September 12, 2014, by Michael Wetter:
+ Set T(start=T_default) and
+ p(start=p_default) in the
+ ThermodynamicState record. Setting the start value for
+ T is required to avoid an error due to conflicting
+ start values when checking AixLib.Examples.VAVReheat.ClosedLoop
+ in pedantic mode.
+
+ - December 18, 2013, by Michael Wetter:
First implementation.
-------- Errors --------
-line 21 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Sensors/LatentEnthalpyFlowRate.mo ----
+line 7 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+line 17 column 2 - Warning: attribute "align" not allowed for HTML5
+line 31 column 2 - Warning: attribute "align" not allowed for HTML5
+line 42 column 2 - Warning: attribute "align" not allowed for HTML5
+line 49 column 2 - Warning: attribute "align" not allowed for HTML5
+line 62 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/FixedResistances/PressureDrop.mo ----
-------- HTML Code --------
- This model outputs the latent enthalphy flow rate of the medium in the flow
- between its fluid ports. In particular, if the total enthalpy flow rate is
+ Model of a flow resistance with a fixed flow coefficient.
+ The mass flow rate is
- Ḣtot = Ḣsen + Ḣlat,
+ ṁ = k
+ √ΔP,
where
- Ḣsen = ṁ (1-Xw) cp,air,
- then this sensor outputs Ḣ = Ḣlat.
+ k is a constant and
+ ΔP is the pressure drop.
+ The constant k is equal to
+ k=m_flow_nominal/sqrt(dp_nominal),
+ where m_flow_nominal and dp_nominal
+ are parameters.
+ Assumptions
- If the parameter tau is non-zero, then the measured
- specific latent enthalpy hout that is used to
- compute the latent enthalpy flow rate
- Ḣlat = ṁ hout
- is computed using a first order differential equation.
- See
- AixLib.Fluid.Sensors.UsersGuide for an explanation.
+ In the region
+ abs(m_flow) < m_flow_turbulent,
+ the square root is replaced by a differentiable function
+ with finite slope.
+ The value of m_flow_turbulent is
+ computed as
+ m_flow_turbulent = deltaM * abs(m_flow_nominal),
+ where deltaM=0.3 and
+ m_flow_nominal are parameters that can be set by the user.
- For a sensor that measures
- Ḣtot, use
-
- AixLib.Fluid.Sensors.EnthalpyFlowRate.
- For a sensor that measures
- Ḣsen, use
-
- AixLib.Fluid.Sensors.SensibleEnthalpyFlowRate.
+ The figure below shows the pressure drop for the parameters
+ m_flow_nominal=5 kg/s,
+ dp_nominal=10 Pa and
+ deltaM=0.3.
+
+
+
+
+ Important parameters
+
+ The parameter from_dp is used to determine
+ whether the mass flow rate is computed as a function of the
+ pressure drop (if from_dp=true), or vice versa.
+ This setting can affect the size of the nonlinear system of equations.
- The sensor is ideal, i.e., it does not influence the fluid.
- The sensor can only be used with medium models that implement the function
- enthalpyOfNonCondensingGas(T).
+ If the parameter linearized is set to true,
+ then the pressure drop is computed as a linear function of the
+ mass flow rate.
+
+
+ Setting allowFlowReversal=false can lead to simpler
+ equations. However, this should only be set to false
+ if one can guarantee that the flow never reverses its direction.
+ This can be difficult to guarantee, as pressure imbalance after
+ the initialization, or due to medium expansion and contraction,
+ can lead to reverse flow.
+
+
+ If the parameter
+ show_T is set to true,
+ then the model will compute the
+ temperature at its ports. Note that this can lead to state events
+ when the mass flow rate approaches zero,
+ which can increase computing time.
+
+ Notes
+
+ For more detailed models that compute the actual flow friction,
+ models from the package
+
+ Modelica.Fluid
+ can be used and combined with models from the
+ AixLib library.
+
+
+ For a model that uses the hydraulic parameter and flow velocity at nominal conditions
+ as a parameter, use
+
+ AixLib.Fluid.FixedResistances.HydraulicDiameter.
+
+ Implementation
+
+ The pressure drop is computed by calling a function in the package
+
+ AixLib.Fluid.BaseClasses.FlowModels,
+ This package contains regularized implementations of the equation
+
+
+ m = sign(Δp) k √ Δp
+
+
+ and its inverse function.
+
+
+ To decouple the energy equation from the mass equations,
+ the pressure drop is a function of the mass flow rate,
+ and not the volume flow rate.
+ This leads to simpler equations.
-
- October 19, 2020, by Antoine Gautier:
- Changed default value for tau from 1 to 0.
- This is for
- #1406.
+ September 21, 2018, by Michael Wetter:
+ Decrease value of deltaM(min=...) attribute.
+ See #1026.
-
- February 25, 2020, by Michael Wetter:
- Changed icon to display its operating state.
- This is for
- #1294.
+ February 3, 2018, by Filip Jorissen:
+ Revised implementation of pressure drop equation
+ such that it depends on from_dp
+ when linearized=true.
+ See #884.
-
- January 18, 2016 by Filip Jorissen:
- Using parameter tauInv
- since this now exists in
- AixLib.Fluid.Sensors.BaseClasses.PartialDynamicFlowSensor.
- This is for
- #372.
+ December 1, 2016, by Michael Wetter:
+ Simplified model by removing the geometry dependent parameters into the new
+ model
+
+ AixLib.Fluid.FixedResistances.HydraulicDiameter.
-
- September 10, 2013, by Michael Wetter:
- Changed medium declaration in the extends statement
- to replaceable to avoid a translation error in
- OpenModelica.
+ November 23, 2016, by Filip Jorissen:
+ Removed dp_nominal and
+ m_flow_nominal labels from icon.
-
- August 31, 2013, by Michael Wetter:
- Removed default value tau=0 as the base class
- already sets tau=1.
- This change was made so that all sensors use the same default value.
+ October 14, 2016, by Michael Wetter:
+ Updated comment for parameter use_dh.
-
- December 18, 2012, by Michael Wetter:
- Moved computation of i_w to new base class
-
- AixLib.Fluid.BaseClasses.IndexWater.
- The value of this parameter is now assigned dynamically and does not require to be specified
- by the user.
+ November 26, 2014, by Michael Wetter:
+ Added the required annotation(Evaluate=true) so
+ that the system of nonlinear equations in
+
+ AixLib.Fluid.FixedResistances.Validation.PressureDropsExplicit
+ remains the same.
-
- November 3, 2011, by Michael Wetter:
- Moved der(h_out) := 0; from the initial algorithm section to
- the initial equation section
- as this assignment does not conform to the Modelica specification.
+ November 20, 2014, by Michael Wetter:
+ Rewrote the warning message using an assert with
+ AssertionLevel.warning
+ as this is the proper way to write warnings in Modelica.
-
- August 10, 2011 by Michael Wetter:
- Added parameter i_w and an assert statement to
- make sure it is set correctly. Without this change, Dymola
- cannot differentiate the model when reducing the index of the DAE.
+ August 5, 2014, by Michael Wetter:
+ Corrected error in documentation of computation of k.
-
- June 3, 2011 by Michael Wetter:
- Revised implementation to add dynamics in such a way that
- the time constant increases as the mass flow rate tends to zero.
- This can improve the numerics.
+ May 29, 2014, by Michael Wetter:
+ Removed undesirable annotation Evaluate=true.
-
- February 22, by Michael Wetter:
- Improved code that searches for index of 'water' in medium model.
+ October 8, 2013, by Michael Wetter:
+ Removed parameter show_V_flow.
-
- September 9, 2009 by Michael Wetter:
+ December 14, 2012 by Michael Wetter:
+ Renamed protected parameters for consistency with the naming conventions.
+
+ -
+ January 16, 2012 by Michael Wetter:
+ To simplify object inheritance tree, revised base classes
+ AixLib.Fluid.BaseClasses.PartialResistance,
+ AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve,
+ AixLib.Fluid.Actuators.BaseClasses.PartialDamperExponential,
+ AixLib.Fluid.Actuators.BaseClasses.PartialActuator
+ and model
+ AixLib.Fluid.FixedResistances.PressureDrop.
+
+ -
+ May 30, 2008 by Michael Wetter:
+ Added parameters use_dh and deltaM for easier parameterization.
+
+ -
+ July 20, 2007 by Michael Wetter:
First implementation.
- Implementation is based on enthalpy sensor of Modelica.Fluid.
-------- Corrected Code --------
- This model outputs the latent enthalphy flow rate of the
- medium in the flow between its fluid ports. In particular, if the
- total enthalpy flow rate is
+ Model of a flow resistance with a fixed flow coefficient. The mass
+ flow rate is
- Ḣtot = Ḣsen + Ḣlat,
+ ṁ = k √ΔP,
- where Ḣsen = ṁ (1-Xw)
- cp,air, then this sensor outputs Ḣ =
- Ḣlat.
+ where k is a constant and ΔP is the pressure drop. The
+ constant k is equal to
+ k=m_flow_nominal/sqrt(dp_nominal), where
+ m_flow_nominal and dp_nominal are
+ parameters.
+
+ Assumptions
+
- If the parameter tau is non-zero, then the measured
- specific latent enthalpy hout that is used to
- compute the latent enthalpy flow rate Ḣlat = ṁ
- hout is computed using a first order differential
- equation. See AixLib.Fluid.Sensors.UsersGuide
- for an explanation.
+ In the region abs(m_flow) < m_flow_turbulent, the
+ square root is replaced by a differentiable function with finite
+ slope. The value of m_flow_turbulent is computed as
+ m_flow_turbulent = deltaM * abs(m_flow_nominal), where
+ deltaM=0.3 and m_flow_nominal are
+ parameters that can be set by the user.
- For a sensor that measures Ḣtot, use AixLib.Fluid.Sensors.EnthalpyFlowRate.
-
- For a sensor that measures Ḣsen, use AixLib.Fluid.Sensors.SensibleEnthalpyFlowRate.
+ The figure below shows the pressure drop for the parameters
+ m_flow_nominal=5 kg/s, dp_nominal=10 Pa and
+ deltaM=0.3.
+
+
+
+
+ Important parameters
+
- The sensor is ideal, i.e., it does not influence the fluid. The
- sensor can only be used with medium models that implement the
- function enthalpyOfNonCondensingGas(T).
+ The parameter from_dp is used to determine whether the
+ mass flow rate is computed as a function of the pressure drop (if
+ from_dp=true), or vice versa. This setting can affect
+ the size of the nonlinear system of equations.
+
+
+ If the parameter linearized is set to true,
+ then the pressure drop is computed as a linear function of the mass
+ flow rate.
+
+
+ Setting allowFlowReversal=false can lead to simpler
+ equations. However, this should only be set to false if
+ one can guarantee that the flow never reverses its direction. This
+ can be difficult to guarantee, as pressure imbalance after the
+ initialization, or due to medium expansion and contraction, can lead
+ to reverse flow.
+
+
+ If the parameter show_T is set to true,
+ then the model will compute the temperature at its ports. Note that
+ this can lead to state events when the mass flow rate approaches
+ zero, which can increase computing time.
+
+
+ Notes
+
+
+ For more detailed models that compute the actual flow friction,
+ models from the package Modelica.Fluid can be used and
+ combined with models from the AixLib library.
+
+
+ For a model that uses the hydraulic parameter and flow velocity at
+ nominal conditions as a parameter, use AixLib.Fluid.FixedResistances.HydraulicDiameter.
+
+
+ Implementation
+
+
+ The pressure drop is computed by calling a function in the package
+ AixLib.Fluid.BaseClasses.FlowModels,
+ This package contains regularized implementations of the equation
+
+
+ m = sign(Δp) k √ Δp
+
+
+
+ and its inverse function.
+
+
+ To decouple the energy equation from the mass equations, the pressure
+ drop is a function of the mass flow rate, and not the volume flow
+ rate. This leads to simpler equations.
- - October 19, 2020, by Antoine Gautier:
- Changed default value for tau from 1 to
- 0.
- This is for #1406.
-
- - February 25, 2020, by Michael Wetter:
- Changed icon to display its operating state.
- This is for #1294.
-
- - January 18, 2016 by Filip Jorissen:
- Using parameter tauInv since this now exists in
+ - September 21, 2018, by Michael Wetter:
+ Decrease value of deltaM(min=...) attribute. See
- AixLib.Fluid.Sensors.BaseClasses.PartialDynamicFlowSensor. This
- is for #372.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/1026\">#1026.
- - September 10, 2013, by Michael Wetter:
- Changed medium declaration in the extends statement to
- replaceable to avoid a translation error in
- OpenModelica.
+ - February 3, 2018, by Filip Jorissen:
+ Revised implementation of pressure drop equation such that it
+ depends on from_dp when linearized=true.
+ See #884.
- - August 31, 2013, by Michael Wetter:
- Removed default value tau=0 as the base class already
- sets tau=1. This change was made so that all sensors
- use the same default value.
+ - December 1, 2016, by Michael Wetter:
+ Simplified model by removing the geometry dependent parameters into
+ the new model AixLib.Fluid.FixedResistances.HydraulicDiameter.
- - December 18, 2012, by Michael Wetter:
- Moved computation of i_w to new base class AixLib.Fluid.BaseClasses.IndexWater.
- The value of this parameter is now assigned dynamically and does
- not require to be specified by the user.
+ - November 23, 2016, by Filip Jorissen:
+ Removed dp_nominal and m_flow_nominal
+ labels from icon.
- - November 3, 2011, by Michael Wetter:
- Moved der(h_out) := 0; from the initial algorithm
- section to the initial equation section as this assignment does not
- conform to the Modelica specification.
+ - October 14, 2016, by Michael Wetter:
+ Updated comment for parameter use_dh.
- - August 10, 2011 by Michael Wetter:
- Added parameter i_w and an assert statement to make
- sure it is set correctly. Without this change, Dymola cannot
- differentiate the model when reducing the index of the DAE.
+ - November 26, 2014, by Michael Wetter:
+ Added the required annotation(Evaluate=true) so that
+ the system of nonlinear equations in
+ AixLib.Fluid.FixedResistances.Validation.PressureDropsExplicit
+ remains the same.
- - June 3, 2011 by Michael Wetter:
- Revised implementation to add dynamics in such a way that the time
- constant increases as the mass flow rate tends to zero. This can
- improve the numerics.
+ - November 20, 2014, by Michael Wetter:
+ Rewrote the warning message using an assert with
+ AssertionLevel.warning as this is the proper way to
+ write warnings in Modelica.
- - February 22, by Michael Wetter:
- Improved code that searches for index of 'water' in medium model.
+ - August 5, 2014, by Michael Wetter:
+ Corrected error in documentation of computation of k.
- - September 9, 2009 by Michael Wetter:
- First implementation. Implementation is based on enthalpy sensor of
- Modelica.Fluid.
+ - May 29, 2014, by Michael Wetter:
+ Removed undesirable annotation Evaluate=true.
+
+ - October 8, 2013, by Michael Wetter:
+ Removed parameter show_V_flow.
+
+ - December 14, 2012 by Michael Wetter:
+ Renamed protected parameters for consistency with the naming
+ conventions.
+
+ - January 16, 2012 by Michael Wetter:
+ To simplify object inheritance tree, revised base classes
+ AixLib.Fluid.BaseClasses.PartialResistance,
+ AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve,
+ AixLib.Fluid.Actuators.BaseClasses.PartialDamperExponential,
+ AixLib.Fluid.Actuators.BaseClasses.PartialActuator and
+ model AixLib.Fluid.FixedResistances.PressureDrop.
+
+ - May 30, 2008 by Michael Wetter:
+ Added parameters use_dh and deltaM for
+ easier parameterization.
+
+ - July 20, 2007 by Michael Wetter:
+ First implementation.
-------- Errors --------
line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+line 37 column 2 - Warning: attribute "align" not allowed for HTML5
+line 90 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Sensors/UsersGuide.mo ----
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/cylindricalHeatSource.mo ----
-------- HTML Code --------
+
+ This function evaluates the cylindrical heat source solution. This solution
+ gives the relation between the constant heat transfer rate (per unit length)
+ injected by a cylindrical heat source of infinite length and the temperature
+ raise in the medium. The cylindrical heat source solution is defined by
+
+
+
+
+
+ where ΔT(t,r) is the temperature raise after a time t of
+ constant heat injection and at a distance r from the cylindrical source,
+ Q' is the heat injection rate per unit length, ks is
+ the soil thermal conductivity, Fo is the Fourier number,
+ aSois is the ground thermal diffusivity,
+ rb is the radius of the cylindrical source and G
+ is the cylindrical heat source solution.
+
+
+ The cylindrical heat source solution is given by:
+
+
+
+
+
+ The integral is solved numerically, with the integrand defined in
+
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.cylindricalHeatSource_Integrand.
+
+
+
+ -
+ March 22, 2018 by Massimo Cimmino:
+ First implementation.
+
+
+
+-------- Corrected Code --------
-This package contains models of sensors.
-There are models with one and with two fluid ports.
-
-
-Selection and parameterization of sensor models
-
-When selecting a sensor model, a distinction needs to be made
-whether the measured quantity depends on the direction of the flow or
-not, and whether the sensor output signal is the product of the mass flow rate
-and a medium property.
+ This function evaluates the cylindrical heat source solution. This
+ solution gives the relation between the constant heat transfer rate
+ (per unit length) injected by a cylindrical heat source of infinite
+ length and the temperature raise in the medium. The cylindrical heat
+ source solution is defined by
-
-
-Output signals that depend on the flow direction and are not multiplied by
-the mass flow rate are temperature, relative humidity,
-water vapor concentration X, trace substances C and density.
-For such quantities, sensors with two fluid ports need to be used.
-An exception is if the quantity is measured directly in a fluid volume, which is the case
-for models from the package
-
-AixLib.Fluid.MixingVolumes.
-Therefore, to measure for example the outlet temperature of a heat exchanger, the
-configuration labelled correct use in the figure below should be used, and not the configuration
-labelled not recommended.
-For an explanation, see
-
-Modelica.Fluid.Examples.Explanatory.MeasuringTemperature.
+
+
-
-
-| Correct use |
-
-
- |
-
|---|
-| Not recommended |
-
-
- |
-
|---|
-
-
-Except for the mass flow rate sensor,
-all sensors with two ports can be
-configured as dynamic sensors or as steady-state sensor.
-The list below advices on how to configure sensors.
+ where ΔT(t,r) is the temperature raise after a time t
+ of constant heat injection and at a distance r from the
+ cylindrical source, Q' is the heat injection rate per unit
+ length, ks is the soil thermal conductivity,
+ Fo is the Fourier number, aSois is the
+ ground thermal diffusivity, rb is the radius of the
+ cylindrical source and G is the cylindrical heat source
+ solution.
-
--
-
-Sensors for quantities that depend on the direction of the mass flow rate but
-not of its magnitude:
-
-Such quantities include density, mass fraction, PPM, relative humidity, specific enthalpy, specific entropy and trace substances.
-Not that these are all quantities that are carried by the fluid that flows through the sensor.
-For these sensors, if the parameter allowFlowReversal=true is set (which is the default setting),
-then it is strongly recommended to configure them
-as a dynamic sensor. This is the default setting.
-Configuring a sensor as a dynamic sensor is done by setting the time constant to a non-zero
-value. Typically, setting tau=10 seconds yields good results.
-For tau=0, numerical problems may occur if the mass flow rate is close to zero
-and allowFlowReversal=true.
-If allowFlowReversal=false, then the measurement of these sensors only depends on properties
-at port_a.
-If the mass flow rate at port_a is ṁa ≤ 0,
-i.e., fluid flows from port_b to port_a,
-the model still assumes ṁa > 0. Hence there are no numerical problems;
-but use of the sensor output may yield wrong results.
-Therefore, only set allowFlowReversal=false if you can guarantee ṁa ≥ 0.
+ The cylindrical heat source solution is given by:
-
--
-
-
-Sensors for quantities that are the product of mass flow rate times a measured fluid property:
-
-Such quantities include volumentric flow rate or enthalpy flow rate.
-For these quantities, sensors are by default configured as steady-state sensor.
-These sensors may be configured by the user
-as a dynamic sensor by setting tau > 0, but there is typically no benefit as these sensors typically
-do not cause numerical problems.
-The reason is that these sensors multiply the quantity that is carried by the flow,
-such as specific enthalpy h by the mass flow rate ṁ
-to compute the measured signal Ḣ=ṁ h.
-Hence, as the mass flow rate goes to zero, the sensor output
-signal also goes to zero, which avoids numerical problems.
+
+
-
--
-Static pressure measurements:
-
-For static pressure measurements, sensors always output the instantaneous measurement.
-These sensors cannot be configured to be dynamic.
+ The integral is solved numerically, with the integrand defined in
+
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.cylindricalHeatSource_Integrand.
-
+
+ - March 22, 2018 by Massimo Cimmino:
+ First implementation.
+
-
-The table below summarizes the recommendations for the use of sensors.
-
-
-| Measured quantity |
- One port sensor |
- Two port sensor |
-
|---|
-steady-state (tau=0) |
- dynamic (tau > 0) |
-
-temperature
- relative humidity
- mass fraction
- trace substances
- specific enthalpy
- specific entropy |
- use only if connected to a volume |
- avoid |
- recommended |
-
-volume flow rate
- enthalpy flow rate
- entropy flow rate |
- - |
- recommended |
- recommended |
-
-| pressure |
- recommended |
- recommended |
- recommended |
-
-
-Sensor Dynamics
-Dynamic response to fluid flowing through the sensor
-
-If a sensor is configured as a dynamic sensor by setting tau > 0,
-then the measured quantity, say the temperature T, is
-computed as
-
-
- τ dT ⁄ dt = |ṁ| ⁄ ṁ0 (θ-T),
-
-
-where τ is a user-defined time constant of the sensor (a suggested value is around 10 seconds,
-which is the default setting for the components),
-dT ⁄ dt is the time derivative of the sensor output signal,
-|ṁ| is the absolute value of the mass flow rate,
-ṁ0 is the user-specified nominal value of the mass flow rate and
-θ is the temperature of the medium inside the sensor.
-An equivalent physical model of such a sensor would be a perfectly mixed volume
-with a sensor that outputs the temperature of this volume. In this situation, the size of the volume would
-be V=τ ṁ0 ⁄ ρ, where
-ρ is the density of the fluid.
-
-Dynamic response to ambient temperature
-
-For the sensor
-
-AixLib.Fluid.Sensors.TemperatureTwoPort,
-by setting transferHeat = true, heat transfer to a
-fixed ambient can be approximated. The heat transfer is computed as
-
-
- τHeaTra dT ⁄ dt = (TAmb-T),
-
-
-where τHeaTra is a fixed time constant and
-TAmb is a fixed ambient temperature.
-Setting transferHeat = true is useful if the sensor output T
-is used to switch the mass flow rate on again. If transferHeat = false,
-then the sensor output T remains constant if the mass flow rate is zero
-and hence a fan or pump controller that uses this signal may never switch the device
-on again.
-If the sensor output T is not used to switch on the mass flow rate, then
-in general one can use transferHeat=false.
-
-
-Note that since in practice the heat transfer is due to a combination of ambient
-temperature and upstream or downstream fluid temperature, for example by two-way
-buoyancy-driven flow inside the duct or pipe, the model uses as an approximation
-a fixed ambient temperature.
-Since the sensor is not affecting the temperature of the medium, this approximation
-of the heat transfer does not add or remove heat from the fluid.
-
-Combined dynamic response
-
-For the sensor
-
-AixLib.Fluid.Sensors.TemperatureTwoPort,
-if both dynamic effects are enabled, then
-the output T is computed as
-
-
-dT ⁄ dt = |ṁ| ⁄ ṁ0 (θ-T) ⁄ τ +
-(TAmb-T) ⁄ τHeaTra.
-
-Implementation
-
-The above equation is implemented in such a way that it is differentiable in the mass flow rate.
-
-
-Note that the implementation of the dynamic sensors does not use the model
-
-AixLib.Fluid.MixingVolumes.
-The reason is that depending on the selected medium model, the
-mixing volume may introduce states for the pressure, species concentration,
-trace substance, specific enthalpy and specific entropy. Not all states are typically needed to
-model the dynamics of a sensor. Moreover, in many building system applications,
-the sensor dynamics is not of concern, but is rather used here to avoid numerical
-problems that steady-state models of sensors cause when flow rates are
-very close to zero.
-
+-------- Errors --------
+line 8 column 2 - Warning: attribute "align" not allowed for HTML5
+line 23 column 2 - Warning: attribute "align" not allowed for HTML5
--------- Corrected Code --------
-
- This package contains models of sensors. There are models with one
- and with two fluid ports.
-
-
- Selection and parameterization of sensor models
-
-
- When selecting a sensor model, a distinction needs to be made whether
- the measured quantity depends on the direction of the flow or not,
- and whether the sensor output signal is the product of the mass flow
- rate and a medium property.
-
-
- Output signals that depend on the flow direction and are not
- multiplied by the mass flow rate are temperature, relative humidity,
- water vapor concentration X, trace substances C and
- density. For such quantities, sensors with two fluid ports need to be
- used. An exception is if the quantity is measured directly in a fluid
- volume, which is the case for models from the package AixLib.Fluid.MixingVolumes.
- Therefore, to measure for example the outlet temperature of a heat
- exchanger, the configuration labelled correct use in the
- figure below should be used, and not the configuration labelled
- not recommended. For an explanation, see
- Modelica.Fluid.Examples.Explanatory.MeasuringTemperature.
-
-
-
- |
- Correct use
- |
-
-
- |
-
-
- |
- Not recommended
- |
-
-
- |
-
-
-
- Except for the mass flow rate sensor, all sensors with two ports can
- be configured as dynamic sensors or as steady-state sensor. The list
- below advices on how to configure sensors.
-
-
- -
-
- Sensors for quantities that depend on the direction of the
- mass flow rate but not of its magnitude: Such quantities
- include density, mass fraction, PPM, relative humidity, specific
- enthalpy, specific entropy and trace substances. Not that these
- are all quantities that are carried by the fluid that flows
- through the sensor. For these sensors, if the parameter
- allowFlowReversal=true is set (which is the default
- setting), then it is strongly recommended to configure them as a
- dynamic sensor. This is the default setting.
- Configuring a sensor as a dynamic sensor is done by setting the
- time constant to a non-zero value. Typically, setting
- tau=10 seconds yields good results. For
- tau=0, numerical problems may occur if the mass flow
- rate is close to zero and
- allowFlowReversal=true.
- If allowFlowReversal=false, then the measurement of
- these sensors only depends on properties at port_a.
- If the mass flow rate at port_a is ṁa
- ≤ 0, i.e., fluid flows from port_b to
- port_a, the model still assumes ṁa
- > 0. Hence there are no numerical problems; but use of the
- sensor output may yield wrong results. Therefore, only set
- allowFlowReversal=false if you can guarantee
- ṁa ≥ 0.
-
-
- -
-
- Sensors for quantities that are the product of mass flow rate
- times a measured fluid property: Such quantities include
- volumentric flow rate or enthalpy flow rate. For these
- quantities, sensors are by default configured as steady-state
- sensor. These sensors may be configured by the user as a dynamic
- sensor by setting tau > 0, but there is typically
- no benefit as these sensors typically do not cause numerical
- problems. The reason is that these sensors multiply the quantity
- that is carried by the flow, such as specific enthalpy h
- by the mass flow rate ṁ to compute the measured signal
- Ḣ=ṁ h. Hence, as the mass flow rate goes to zero, the
- sensor output signal also goes to zero, which avoids numerical
- problems.
-
-
- -
-
- Static pressure measurements: For static pressure
- measurements, sensors always output the instantaneous
- measurement. These sensors cannot be configured to be dynamic.
-
-
-
-
- The table below summarizes the recommendations for the use of
- sensors.
-
-
-
- |
- Measured quantity
- |
-
- One port sensor
- |
-
- Two port sensor
- |
-
-
-
- steady-state (tau=0)
- |
-
- dynamic (tau > 0)
- |
-
-
-
- temperature
- relative humidity
- mass fraction
- trace substances
- specific enthalpy
- specific entropy
- |
-
- use only if connected to a volume
- |
-
- avoid
- |
-
- recommended
- |
-
-
-
- volume flow rate
- enthalpy flow rate
- entropy flow rate
- |
-
- -
- |
-
- recommended
- |
-
- recommended
- |
-
-
- |
- pressure
- |
-
- recommended
- |
-
- recommended
- |
-
- recommended
- |
-
-
-
- Sensor Dynamics
-
-
- Dynamic response to fluid flowing through the sensor
-
-
- If a sensor is configured as a dynamic sensor by setting tau
- > 0, then the measured quantity, say the temperature
- T, is computed as
-
-
- τ dT ⁄ dt = |ṁ| ⁄ ṁ0 (θ-T),
-
-
- where τ is a user-defined time constant of the sensor (a
- suggested value is around 10 seconds, which is the default setting
- for the components), dT ⁄ dt is the time derivative of the
- sensor output signal, |ṁ| is the absolute value of the mass
- flow rate, ṁ0 is the user-specified nominal value
- of the mass flow rate and θ is the temperature of the medium
- inside the sensor. An equivalent physical model of such a sensor
- would be a perfectly mixed volume with a sensor that outputs the
- temperature of this volume. In this situation, the size of the volume
- would be V=τ ṁ0 ⁄ ρ, where ρ is the
- density of the fluid.
-
-
- Dynamic response to ambient temperature
-
-
- For the sensor AixLib.Fluid.Sensors.TemperatureTwoPort,
- by setting transferHeat = true, heat transfer to a fixed
- ambient can be approximated. The heat transfer is computed as
-
-
- τHeaTra dT ⁄ dt = (TAmb-T),
-
-
- where τHeaTra is a fixed time constant and
- TAmb is a fixed ambient temperature. Setting
- transferHeat = true is useful if the sensor output
- T is used to switch the mass flow rate on again. If
- transferHeat = false, then the sensor output T
- remains constant if the mass flow rate is zero and hence a fan or
- pump controller that uses this signal may never switch the device on
- again. If the sensor output T is not used to switch on the
- mass flow rate, then in general one can use
- transferHeat=false.
-
-
- Note that since in practice the heat transfer is due to a combination
- of ambient temperature and upstream or downstream fluid temperature,
- for example by two-way buoyancy-driven flow inside the duct or pipe,
- the model uses as an approximation a fixed ambient temperature. Since
- the sensor is not affecting the temperature of the medium, this
- approximation of the heat transfer does not add or remove heat from
- the fluid.
-
-
- Combined dynamic response
-
-
- For the sensor AixLib.Fluid.Sensors.TemperatureTwoPort,
- if both dynamic effects are enabled, then the output T is
- computed as
-
-
- dT ⁄ dt = |ṁ| ⁄ ṁ0 (θ-T) ⁄ τ +
- (TAmb-T) ⁄ τHeaTra.
-
-
- Implementation
-
-
- The above equation is implemented in such a way that it is
- differentiable in the mass flow rate.
-
-
- Note that the implementation of the dynamic sensors does not use the
- model AixLib.Fluid.MixingVolumes.
- The reason is that depending on the selected medium model, the mixing
- volume may introduce states for the pressure, species concentration,
- trace substance, specific enthalpy and specific entropy. Not all
- states are typically needed to model the dynamics of a sensor.
- Moreover, in many building system applications, the sensor dynamics
- is not of concern, but is rather used here to avoid numerical
- problems that steady-state models of sensors cause when flow rates
- are very close to zero.
-
-
--------- Errors --------
-line 32 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
-line 105 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
-line 33 column 5 - Warning: | attribute "align" not allowed for HTML5
-line 38 column 5 - Warning: | attribute "align" not allowed for HTML5
-line 144 column 1 - Warning: attribute "align" not allowed for HTML5
-line 167 column 1 - Warning: attribute "align" not allowed for HTML5
-line 197 column 1 - Warning: attribute "align" not allowed for HTML5
-
----- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/PlugFlowULg.mo ----
+---- AixLib/Media/Air.mo ----
-------- HTML Code --------
- The example contains
- experimental data from a real district heating network.
+ Model with basic thermodynamic properties.
- This model compares the results with the original Modelica Standard Library pipes.
+ This model provides equation for the following thermodynamic properties:
- The pipes' temperatures are not initialized. Therefore, results of
- outflow temperature before approximately the first 10000 seconds should not be
- considered.
+
+ | Variable |
+ Unit |
+ Description |
+ | T |
+ K |
+ temperature |
+ | p |
+ Pa |
+ absolute pressure |
+ | d |
+ kg/m3 |
+ density |
+ | h |
+ J/kg |
+ specific enthalpy |
+ | u |
+ J/kg |
+ specific internal energy |
+ | Xi[nXi] |
+ kg/kg |
+ independent mass fractions m_i/m |
+ | R |
+ J/kg.K |
+ gas constant |
+ | M |
+ kg/mol |
+ molar mass |
+
+
+
+ -
+ September 22, 2020, by Michael Wetter:
+ First implementation based on Modelica Standard Library,
+ but with noEvent added to check of bounds.
+
+
+
+ Density is computed from pressure, temperature and composition in the thermodynamic state record applying the ideal gas law.
+
+
+ This function returns the dynamic viscosity.
- Test bench schematic
-
- Calibration
+ Implementation
- There are some uncertainties about the heat loss coefficient between pipe and
- surrounding air as well as regarding the heat conductivity of the insulation
- material.
- With the
- given data, the length specific thermal resistance is R = 2.164
- ((m K)/W), calculated as follows:
+ The function is based on the 5th order polynomial
+ of
+
+ Modelica.Media.Air.MoistAir.dynamicViscosity.
+ However, for the typical range of temperatures encountered
+ in building applications, a linear function sufficies.
+ This implementation is therefore the above 5th order polynomial,
+ linearized around 20°C.
+ The relative error of this linearization is
+ 0.4% at -20°C,
+ and less then
+ 0.2% between -5°C and +50°C.
-
- R=((1/(2*pipe.kIns)*log((0.0603+2*pipe.dIns)/(0.0603)))+1/(5*(0.0603+2*pipe.dIns)))/Modelica.Constants.pi
-
- U = 1/R = 0.462 W/(m K)
-
- March 7, 2020, by Michael Wetter:
- Replaced measured data from specification in Modelica file to external table,
- as this reduces the computing time.
- This is for
- #1289.
-
- -
- November 24, 2016 by Bram van der Heijde:
Add pipe thickness for wall
- capacity calculation and expand documentation section.
- - April 2, 2016 by Bram van der Heijde:
Change thermal conductivity and
- put boundary condition in K.
-
- - Januar 26, 2016 by Carles Ribas:
First implementation.
+ December 19, 2013, by Michael Wetter:
+ First implementation.
--------- Corrected Code --------
-
- The example contains experimental data from a real district heating
- network.
-
-
- This model compares the results with the original Modelica Standard
- Library pipes.
-
-
- The pipes' temperatures are not initialized. Therefore, results of
- outflow temperature before approximately the first 10000 seconds
- should not be considered.
-
-
- Test bench schematic
-
-
-
-
-
- Calibration
-
-
- There are some uncertainties about the heat loss coefficient between
- pipe and surrounding air as well as regarding the heat conductivity
- of the insulation material. With the
- given data, the length specific thermal resistance is R =
- 2.164 ((m K)/W), calculated as follows:
-
-
- R=((1/(2*pipe.kIns)*log((0.0603+2*pipe.dIns)/(0.0603)))+1/(5*(0.0603+2*pipe.dIns)))/Modelica.Constants.pi
-
-
- U = 1/R = 0.462 W/(m K)
-
-
- - March 7, 2020, by Michael Wetter:
- Replaced measured data from specification in Modelica file to
- external table, as this reduces the computing time.
- This is for #1289.
-
- - November 24, 2016 by Bram van der Heijde:
- Add pipe thickness for wall capacity calculation and expand
- documentation section.
-
- - April 2, 2016 by Bram van der Heijde:
- Change thermal conductivity and put boundary condition in K.
-
- - Januar 26, 2016 by Carles Ribas:
- First implementation.
-
-
-
--------- Errors --------
-line 25 column 2 - Warning: attribute "align" not allowed for HTML5
-line 27 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/Humidifiers/SprayAirWasher_X.mo ----
--------- HTML Code --------
-
+ The ideal gas constant for moist air is computed from thermodynamic state assuming that all water is in the gas phase.
+
+ Pressure is returned from the thermodynamic state record input as a simple assignment.
+
- Model for a spray air washer with a prescribed outlet water vapor mass fraction
- in kg/kg total air.
+ This function returns the isobaric expansion coefficient at constant pressure,
+ which is zero for this medium.
+ The isobaric expansion coefficient at constant pressure is
-
- This model forces the outlet water mass fraction at port_b to be
- no lower than the
- input signal X_wSet, subject to optional limits on the
- maximum water vapor mass flow rate that is added, as
- described by the parameter mWatMax_flow.
- By default, the model has unlimited capacity.
+
+ βp = - 1 ⁄ v (∂ v ⁄ ∂ T)p = 0,
- The output signal mWat_flow ≥ 0 is the moisture added
- to the medium if the flow rate is from port_a to port_b.
- If the flow is reversed, then mWat_flow = 0.
- The outlet specific enthalpy at port_b is increased by
- the enthalpy of liquid water at 10°C times the mass of water that was added.
- Therefore, the temperature of the leaving fluid is below the inlet temperature.
+ where
+ v is the specific volume,
+ T is the temperature and
+ p is the pressure.
+
+
+ -
+ December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- The outlet conditions at port_a are not affected by this model,
- other than for a possible pressure difference due to flow friction.
+ This function returns the isothermal compressibility coefficient.
+ The isothermal compressibility is
+
+
+ κT = -1 ⁄ v (∂ v ⁄ ∂ p)T
+ = -1 ⁄ p,
- If the parameter energyDynamics is different from
- Modelica.Fluid.Types.Dynamics.SteadyState,
- the component models the dynamic response using a first order differential equation.
- The time constant of the component is equal to the parameter tau.
- This time constant is adjusted based on the mass flow rate using
+ where
+ v is the specific volume,
+ T is the temperature and
+ p is the pressure.
+
+
+
+ -
+ December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
+
+
+ This function computes the specific entropy.
+
+
+ The specific entropy of the mixture is obtained from
- τeff = τ |ṁ| ⁄ ṁnom
+ s = ss + sm,
where
- τeff is the effective time constant for the given mass flow rate
- ṁ and
- τ is the time constant at the nominal mass flow rate
- ṁnom.
- This type of dynamics is equal to the dynamics that a completely mixed
- control volume would have.
+ ss is the entropy change due to the state change
+ (relative to the reference temperature) and
+ sm is the entropy change due to mixing
+ of the dry air and water vapor.
- Optionally, this model can have a flow resistance.
- Set dp_nominal = 0 to disable the flow friction calculation.
+ The entropy change due to change in state is obtained from
+
+
+ ss = cv ln(T/T0) + R ln(v/v0)
+ = cv ln(T/T0) + R ln(ρ0/ρ)
+
+ If we assume ρ = p0/(R T),
+ and because cp = cv + R,
+ we can write
+
+
+ ss = cv ln(T/T0) + R ln(T/T0)
+ =cp ln(T/T0).
- For a model that uses a control signal u ∈ [0, 1] and multiplies
- this with the nominal water mass flow rate, use
-
- AixLib.Fluid.Humidifiers.Humidifier_u
-
+ Next, the entropy of mixing is obtained from a reversible isothermal
+ expansion process. Hence,
+
+
+ sm = -R ∑i( Xi ⁄ Mi
+ ln(Yi p/p0)),
- Limitations
- This model only adds water vapor for the flow from
- port_a to port_b.
- The water vapor of the reverse flow is not affected by this model.
+ where R is the gas constant,
+ X is the mass fraction,
+ M is the molar mass, and
+ Y is the mole fraction.
- This model does not affect the enthalpy of the air. Therefore,
- if water is added, the temperature will decrease, e.g., the humidification
- is adiabatic.
+ To obtain the state for a given pressure, entropy and mass fraction, use
+
+ AixLib.Media.Air.setState_psX.
+
+ Limitations
+
+ This function is only valid for a relative humidity below 100%.
-
- March 8, 2022, by Michael Wetter:
- Renamed parameter massDynamics to energyDynamics for consistency with other models.
-
- -
- December 14, 2018, by Michael Wetter:
- Restricted base class for medium to one that implements
- the function enthalpyOfLiquid.
- This is for
- #1057.
-
- -
- May 3, 2017, by Michael Wetter:
+ November 27, 2013, by Michael Wetter:
First implementation.
--------- Corrected Code --------
-
- Model for a spray air washer with a prescribed outlet water vapor
- mass fraction in kg/kg total air.
-
-
- This model forces the outlet water mass fraction at
- port_b to be no lower than the input signal
- X_wSet, subject to optional limits on the maximum water
- vapor mass flow rate that is added, as described by the parameter
- mWatMax_flow. By default, the model has unlimited
- capacity.
-
-
- The output signal mWat_flow ≥ 0 is the moisture added to
- the medium if the flow rate is from port_a to
- port_b. If the flow is reversed, then mWat_flow =
- 0. The outlet specific enthalpy at port_b is
- increased by the enthalpy of liquid water at 10°C times the
- mass of water that was added. Therefore, the temperature of the
- leaving fluid is below the inlet temperature.
-
-
- The outlet conditions at port_a are not affected by this
- model, other than for a possible pressure difference due to flow
- friction.
-
-
- If the parameter energyDynamics is different from
- Modelica.Fluid.Types.Dynamics.SteadyState, the component
- models the dynamic response using a first order differential
- equation. The time constant of the component is equal to the
- parameter tau. This time constant is adjusted based on
- the mass flow rate using
-
-
- τeff = τ |ṁ| ⁄ ṁnom
-
-
- where τeff is the effective time constant for the
- given mass flow rate ṁ and τ is the time constant at
- the nominal mass flow rate ṁnom. This type of
- dynamics is equal to the dynamics that a completely mixed control
- volume would have.
-
-
- Optionally, this model can have a flow resistance. Set
- dp_nominal = 0 to disable the flow friction calculation.
-
-
- For a model that uses a control signal u ∈ [0, 1] and
- multiplies this with the nominal water mass flow rate, use AixLib.Fluid.Humidifiers.Humidifier_u
-
-
- Limitations
-
-
- This model only adds water vapor for the flow from
- port_a to port_b. The water vapor of the
- reverse flow is not affected by this model.
-
-
- This model does not affect the enthalpy of the air. Therefore, if
- water is added, the temperature will decrease, e.g., the
- humidification is adiabatic.
-
-
- - March 8, 2022, by Michael Wetter:
- Renamed parameter massDynamics to
- energyDynamics for consistency with other models.
-
- - December 14, 2018, by Michael Wetter:
- Restricted base class for medium to one that implements the
- function enthalpyOfLiquid.
- This is for #1057.
-
- - May 3, 2017, by Michael Wetter:
- First implementation.
-
-
-
--------- Errors --------
-line 33 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/BoundaryConditions/Validation/BESTEST/WD500.mo ----
--------- HTML Code --------
-
+
+ This function returns the partial derivative of density
+ with respect to pressure at constant temperature.
+
+
-
- September 6, 2021, by Ettore Zanetti:
- Removed parameter lat as it is now obtained from the weather data bus.
- This is for
- IBPSA, #1477.
-
- -
- March 11, 2020, by Ettore Zanetti:
+ December 18, 2013, by Michael Wetter:
First implementation.
+
+
+
+ This function computes the derivative of density with respect to temperature
+ at constant pressure.
+
+
+
-
- April 14, 2020, by Ettore Zanetti:
- Rework after comments from pull request
- #1339.
+ December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
+
+ This function returns the partial derivative of density
+ with respect to mass fraction.
+ This value is zero because in this medium, density is proportional
+ to pressure, but independent of the species concentration.
+
+
+
-
- May 2, 2021, by Ettore Zanetti:
- Updated weather file as explained in #1478.
+ December 18, 2013, by Michael Wetter:
+ First implementation.
- WD500: Time Zone Case
- Weather data file : WD500.epw
- Table 1: Site Data for Weather file WD500epw
-
- Latitude |
- 28.567° north |
-
-
- Longitude |
- 77.103° east |
-
-
- Altitude |
- 236.9 m |
-
-
- Time Zone |
- 5.5 |
-
-
+
+ The thermodynamic state record
+ is computed from density d, temperature T and composition X.
+
--------- Corrected Code --------
-
- - September 6, 2021, by Ettore Zanetti:
- Removed parameter lat as it is now obtained from the
- weather data bus.
- This is for IBPSA,
- #1477.
-
- - March 11, 2020, by Ettore Zanetti:
- First implementation.
-
- - April 14, 2020, by Ettore Zanetti:
- Rework after comments from pull request #1339.
-
- - May 2, 2021, by Ettore Zanetti:
- Updated weather file as explained in #1478.
-
-
-
- WD500: Time Zone Case
-
-
- Weather data file : WD500.epw
-
-
- Table 1: Site Data for Weather file WD500epw
-
-
-
- |
-
- Latitude
-
- |
-
-
- 28.567° north
-
- |
-
-
- |
-
- Longitude
-
- |
-
-
- 77.103° east
-
- |
-
-
- |
-
- Altitude
-
- |
-
-
- 236.9 m
-
- |
-
-
- |
-
- Time Zone
-
- |
-
-
- 5.5
-
- |
-
-
-
--------- Errors --------
-line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-
-
----- AixLib/Fluid/Movers/Data/Pumps/Wilo/Stratos25slash1to6.mo ----
--------- HTML Code --------
-
- Data from
-
- http://productfinder.wilo.com/en/COM/product/00000018000028040002003a/fc_product_datasheet
+ The
+ thermodynamic state record is computed from pressure p, specific enthalpy h and composition X.
+
+ The
+ thermodynamic state record is computed from pressure p, temperature T and composition X.
+
+
+ This function returns the thermodynamic state based on pressure,
+ specific entropy and mass fraction.
- The nominal rpm is arbitrarily chosen as the rpm of the pump curve
- in the data sheet that has the highest rpm,
- without being limited by the maximum power limitation
- (see dotted curve on figure below).
- Pump curves (H(m_flow) and P(m_flow)) from the data sheets
- are digitized using
- web plot digitizer.
+ The state is computed by symbolically solving
+
+ AixLib.Media.Air.specificEntropy
+ for temperature.
- Limitations:
+
- - The pump curve cap at high rpm that can be seen is not enforced
- by the model.
+
-
+ November 27, 2013, by Michael Wetter:
+ First implementation.
+
+
+ Specific enthalpy as a function of temperature and species concentration.
+ The pressure is input for compatibility with the medium models, but the specific enthalpy
+ is independent of the pressure.
+
+
-
- The pump curve may be altered slightly to guarantee that dp/dm<0
+ April 30, 2015, by Filip Jorissen and Michael Wetter:
+ Added Inline=true for
+
+ issue 227.
+
- The figure below illustrates a digitized pump curve.
+ This function computes the specific enthalpy for
+ an isentropic state change from the temperature
+ that corresponds to the state refState
+ to reference_T.
-
- ![\"Pump](\"modelica://AixLib/Resources/Images/Fluid/Movers/Data/stratoscurve.png\"/)
-
- February 17, 2016, by Michael Wetter:
- Updated parameter names for
- #396.
+ December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
+ Temperature is returned from the thermodynamic state record input as a simple assignment.
+
+
+ This function returns the molar mass.
+
+
+
-
- December 12, 2014, by Michael Wetter:
- Added defaultComponentPrefixes and
- defaultComponentName annotations.
-
- - April 17, 2014
- by Filip Jorissen:
- Initial version
+ December 18, 2013, by Michael Wetter:
+ First implementation.
--------- Corrected Code --------
-
- Data from
- http://productfinder.wilo.com/en/COM/product/00000018000028040002003a/fc_product_datasheet
-
-
- The nominal rpm is arbitrarily chosen as the rpm of the pump curve in
- the data sheet that has the highest rpm, without being limited by the
- maximum power limitation (see dotted curve on figure below). Pump
- curves (H(m_flow) and P(m_flow)) from the data sheets are digitized
- using web plot
- digitizer.
-
-
- Limitations:
-
-
- - The pump curve cap at high rpm that can be seen is not enforced
- by the model.
-
- - The pump curve may be altered slightly to guarantee that
- dp/dm<0
-
-
-
- The figure below illustrates a digitized pump curve.
-
-
-
-
-
- - February 17, 2016, by Michael Wetter:
- Updated parameter names for #396.
-
- - December 12, 2014, by Michael Wetter:
- Added defaultComponentPrefixes and
- defaultComponentName annotations.
-
- - April 17, 2014 by Filip Jorissen:
- Initial version
-
-
-
--------- Errors --------
-line 27 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/HeatExchangers/BaseClasses/WetCoilDryWetRegime.mo ----
--------- HTML Code --------
-
+ Temperature as a function of specific enthalpy and species concentration.
+ The pressure is input for compatibility with the medium models, but the temperature
+ is independent of the pressure.
+
-
- Jan 21, 2021, by Donghun Kim:
First implementation.
+ April 30, 2015, by Filip Jorissen and Michael Wetter:
+ Added Inline=true for
+
+ issue 227.
- This model implements the switching algorithm for the dry and wet regime.
+ This data record contains the coefficients for perfect gases.
+
+
+ -
+ September 12, 2014, by Michael Wetter:
+ Corrected the wrong location of the preferredView
+ and the revisions annotation.
+
+ -
+ November 21, 2013, by Michael Wetter:
+ First implementation.
+
+
+
- The switching criteria for (counter-flow) cooling coil modes are as follows.
-
- R1: If the coil surface temperature at the air inlet is lower than the dew-point
- temperature at the inlet to the coil, then the cooling coil surface is fully-wet.
-
- R2: If the surface temperature at the air outlet section is higher than
- the dew-point temperature of the air at the inlet, then the cooling coil surface is fully-dry.
-
- At each point of a simulation time step, the fuzzy-modeling approach determines
- the weights for R1 and R2 respectively (namely μFW and μFD)
- from the dew-point and coil surface temperatures.
-
- It calculates total and sensible heat transfer rates according to the weights as follows.
+ This medium package models moist air using a gas law in which pressure and temperature
+ are independent, which often leads to significantly faster and more robust computations.
+ The specific heat capacities at constant pressure and at constant volume are constant.
+ The air is assumed to be not saturated.
-
- Q̇tot=μFD Q̇tot,FD+μFW Qtot,FW
+
+ This medium uses the gas law
- Q̇sen=μFD Q̇sen,FD+μFW Qsen,FW
+ ρ/ρstp = p/pstp,
- The fuzzy-modeling ensures μFW + μFD = 1,
- μFW >=0 and μFD >=0, which means the fuzzy
- model outcomes of Q̇sen and Q̇tot are always convex combinations of heat transfer
- rates for fully-dry and fully-wet modes and therefore are always bounded by them.
+ where
+ pstd and ρstp are constant reference
+ temperature and density, rathern than the ideal gas law
-
- The modeling approach also results in n-th order differentiable model
- depending on the selection of the underlying membership functions. This cooling
- coil model is once continuously differentiable at the mode switches.
+
+ ρ = p ⁄(R T),
-
--------- Corrected Code --------
-
- - Jan 21, 2021, by Donghun Kim:
- First implementation.
-
-
-
- This model implements the switching algorithm for the dry and wet
- regime.
-
-
- The switching criteria for (counter-flow) cooling coil modes are as
- follows.
-
-
- R1: If the coil surface temperature at the air inlet is lower than
- the dew-point temperature at the inlet to the coil, then the cooling
- coil surface is fully-wet.
-
-
- R2: If the surface temperature at the air outlet section is higher
- than the dew-point temperature of the air at the inlet, then the
- cooling coil surface is fully-dry.
-
-
- At each point of a simulation time step, the fuzzy-modeling approach
- determines the weights for R1 and R2 respectively (namely
- μFW and μFD) from the dew-point
- and coil surface temperatures.
-
-
- It calculates total and sensible heat transfer rates according to the
- weights as follows.
-
-
- Q̇tot=μFD Q̇tot,FD+μFW
- Qtot,FW
-
-
- Q̇sen=μFD Q̇sen,FD+μFW
- Qsen,FW
-
-
- The fuzzy-modeling ensures μFW + μFD =
- 1, μFW >=0 and μFD >=0,
- which means the fuzzy model outcomes of Q̇sen and
- Q̇tot are always convex combinations of heat
- transfer rates for fully-dry and fully-wet modes and therefore are
- always bounded by them.
-
-
- The modeling approach also results in n-th order
- differentiable model depending on the selection of the underlying
- membership functions. This cooling coil model is once continuously
- differentiable at the mode switches.
-
-
--------- Errors --------
-line 20 column 2 - Warning: attribute "align" not allowed for HTML5
-line 23 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/FMI/ExportContainers/HVACZone.mo ----
--------- HTML Code --------
-
- Model that is used as a container for an HVAC system that is
- to be exported as an FMU and that serves a single zone.
+ where R is the gas constant and T is the temperature.
- Typical use and important parameters
- To use this model as a container for an FMU, extend
- from this model, rather than instantiate it,
- and add your HVAC system. By extending from this model, the top-level
- signal connectors on the right stay at the top-level, and hence
- will be visible at the FMI interface.
- The example
-
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZone
- shows how a simple HVAC system can be implemented and exported as
- an FMU.
-
+ This formulation often leads to smaller systems of nonlinear equations
+ because equations for pressure and temperature are decoupled.
+ Therefore, if air inside a control volume such as room air is heated, it
+ does not increase its specific volume. Consequently, merely heating or cooling
+ a control volume does not affect the air flow calculations in a duct network
+ that may be connected to that volume.
+ Note that multizone air exchange simulation in which buoyancy drives the
+ air flow is still possible as the models in
+
+ AixLib.Airflow.Multizone compute the mass density using the function
+
+ AixLib.Utilities.Psychrometrics.Functions.density_pTX in which density
+ is a function of temperature.
- The conversion between the fluid ports and signal ports is done
- in the HVAC adapter hvacAda.
- This adapter has a vector of fluid ports called ports.
- The supply and return air ducts, including any resistance model for the inlet
- diffusor or exhaust grill, need to be connected to these ports.
- Also, if a thermal zone has interzonal air exchange or air infiltration,
- these flows need to be connected to ports.
- This model outputs at the port fluPor the mass flow rate for
- each flow that is connected to ports, together with its
- temperature, water vapor mass fraction per total mass of the air (not per kg dry
- air), and trace substances. These quantities are always as if the flow
- enters the room, even if the flow is zero or negative.
- If a medium has no moisture, e.g., if Medium.nXi=0, or
- if it has no trace substances, e.g., if Medium.nC=0, then
- the output signal for these properties are removed.
- These quantities are always as if the flow
- enters the room, even if the flow is zero or negative.
- Thus, a thermal zone model that uses these signals to compute the
- heat added by the HVAC system needs to implement an equation such as
+ Note that models in this package implement the equation for the internal energy as
- Qsen = max(0, ṁsup) cp (Tsup - Tair,zon),
+ u = h - pstp ⁄ ρstp,
where
- Qsen is the sensible heat flow rate added to the thermal zone,
- ṁsup is the supply air mass flow rate from
- the port fluPor (which is negative if it is an exhaust),
- cp is the specific heat capacity at constant pressure,
- Tsup is the supply air temperature and
- Tair,zon is the zone air temperature.
- Note that without the max(·, ·), the energy
- balance would be wrong.
-
-
- The input signals of this model are the zone radiative temperature.
- The the zone air temperature,
- the water vapor mass fraction per total mass of the air (unless Medium.nXi=0)
- and trace substances (unless Medium.nC=0) are obtained from the connector
- fluPor.backward.
- The outflowing fluid stream(s) at the port ports will be at the
- states obtained from fluPor.backward.
- All fluid streams at port ports are at the same
- pressure.
- For convenience, the instance hvacAda also outputs the
- properties obtained from fluPor.backward. These can be used
- to connect a controller. The properties are available for each flow path in
- fluPor.backward. For a thermal zone with mixed air, these are
- all equal, while for a stratified room model, they can be different.
+ u is the internal energy per unit mass,
+ h is the enthalpy per unit mass,
+ pstp is the static pressure and
+ ρstp is the mass density at standard pressure and temperature.
+ The reason for this implementation is that in general,
-
-
- See
-
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZone
- for a model that uses this model.
+
+ h = u + p v,
- For models that multiple thermal zones connected to the HVAC system,
- use the model
-
- AixLib.Fluid.FMI.ExportContainers.HVACZones.
+ from which follows that
- Assumption and limitations
-
- The mass flow rates at ports sum to zero, hence this
- model conserves mass.
+
+ u = h - p v = h - p ⁄ ρ = h - pstp ⁄ ρstd,
- This model does not impose any pressure, other than setting the pressure
- of all fluid connections to ports to be equal.
- The reason is that setting a pressure can lead to non-physical system models,
- for example if a mass flow rate is imposed and the HVAC system is connected
- to a model that sets a pressure boundary condition such as
-
- AixLib.Fluid.Sources.Outside.
- Also, setting a pressure would make it impossible to use multiple instances
- of this model (one for each thermal zone) and build in Modelica an airflow network
- model with pressure driven mass flow rates.
+ because p ⁄ ρ = pstp ⁄ ρstp in this medium model.
- The model has no pressure drop. Hence, the pressure drop
- of an air diffuser or of an exhaust grill needs to be modelled
- in models that are connected to ports.
+ The enthalpy is computed using the convention that h=0
+ if T=0 °C and no water vapor is present.
-
- January 18, 2019, by Jianjun Hu:
- Limited the media choice to moist air only.
- See #1050.
+ September 28, 2020, by Michael Wetter:
+ Reformulated BaseProperties to avoid event-triggering assertions.
+ This is for
+ #1401.
-
- April 15, 2016, by Michael Wetter:
- First implementation.
+ January 11, 2019 by Michael Wetter:
+ Reforulated assignment of X_int in setState_psX.
+ This is for
+ #1079.
-
-
--------- Corrected Code --------
-
- Model that is used as a container for an HVAC system that is to be
- exported as an FMU and that serves a single zone.
-
-
- Typical use and important parameters
-
-
- To use this model as a container for an FMU, extend from this model,
- rather than instantiate it, and add your HVAC system. By extending
- from this model, the top-level signal connectors on the right stay at
- the top-level, and hence will be visible at the FMI interface. The
- example
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZone shows
- how a simple HVAC system can be implemented and exported as an FMU.
-
-
-
- The conversion between the fluid ports and signal ports is done in
- the HVAC adapter hvacAda. This adapter has a vector of
- fluid ports called ports. The supply and return air
- ducts, including any resistance model for the inlet diffusor or
- exhaust grill, need to be connected to these ports. Also, if a
- thermal zone has interzonal air exchange or air infiltration, these
- flows need to be connected to ports. This model outputs
- at the port fluPor the mass flow rate for each flow that
- is connected to ports, together with its temperature,
- water vapor mass fraction per total mass of the air (not per kg dry
- air), and trace substances. These quantities are always as if the
- flow enters the room, even if the flow is zero or negative. If a
- medium has no moisture, e.g., if Medium.nXi=0, or if it
- has no trace substances, e.g., if Medium.nC=0, then the
- output signal for these properties are removed. These quantities are
- always as if the flow enters the room, even if the flow is zero or
- negative. Thus, a thermal zone model that uses these signals to
- compute the heat added by the HVAC system needs to implement an
- equation such as
-
-
- Qsen = max(0, ṁsup) cp
- (Tsup - Tair,zon),
-
-
- where Qsen is the sensible heat flow rate added to
- the thermal zone, ṁsup is the supply air mass flow
- rate from the port fluPor (which is negative if it is an
- exhaust), cp is the specific heat capacity at
- constant pressure, Tsup is the supply air
- temperature and Tair,zon is the zone air
- temperature. Note that without the max(·, ·), the energy
- balance would be wrong.
-
-
- The input signals of this model are the zone radiative temperature.
- The the zone air temperature, the water vapor mass fraction per total
- mass of the air (unless Medium.nXi=0) and trace
- substances (unless Medium.nC=0) are obtained from the
- connector fluPor.backward. The outflowing fluid
- stream(s) at the port ports will be at the states
- obtained from fluPor.backward. All fluid streams at port
- ports are at the same pressure. For convenience, the
- instance hvacAda also outputs the properties obtained
- from fluPor.backward. These can be used to connect a
- controller. The properties are available for each flow path in
- fluPor.backward. For a thermal zone with mixed air,
- these are all equal, while for a stratified room model, they can be
- different.
-
-
- See
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZone for a
- model that uses this model.
-
-
- For models that multiple thermal zones connected to the HVAC system,
- use the model AixLib.Fluid.FMI.ExportContainers.HVACZones.
-
-
- Assumption and limitations
-
-
- The mass flow rates at ports sum to zero, hence this
- model conserves mass.
-
-
- This model does not impose any pressure, other than setting the
- pressure of all fluid connections to ports to be equal.
- The reason is that setting a pressure can lead to non-physical system
- models, for example if a mass flow rate is imposed and the HVAC
- system is connected to a model that sets a pressure boundary
- condition such as AixLib.Fluid.Sources.Outside.
- Also, setting a pressure would make it impossible to use multiple
- instances of this model (one for each thermal zone) and build in
- Modelica an airflow network model with pressure driven mass flow
- rates.
-
-
- The model has no pressure drop. Hence, the pressure drop of an air
- diffuser or of an exhaust grill needs to be modelled in models that
- are connected to ports.
-
-
- - January 18, 2019, by Jianjun Hu:
- Limited the media choice to moist air only. See #1050.
-
- - April 15, 2016, by Michael Wetter:
- First implementation.
-
-
-
--------- Errors --------
-line 47 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Controls/Continuous/NumberOfRequests.mo ----
--------- HTML Code --------
-
-
- Block that outputs the number of inputs that exceed a threshold.
- The parameter kind is used to determine the kind of the
- inequality. The table below shows the allowed settings.
-
-
-
- Value of parameter kind |
- Output signal incremented by 1 for each i ∈ {1, ..., nin} if |
-
-
- | 0 |
- u[i] > threShold |
-
-
- | 1 |
- u[i] ≥ threShold |
-
-
- | 2 |
- u[i] ≤ threShold |
-
-
- | 3 |
- u[i] < threShold |
-
-
-
- This model may be used to check how many rooms
- exceed a temperature threshold.
-
-
-
-
- November 21, 2011, by Michael Wetter:
- Improved documentation.
+ October 26, 2018, by Filip Jorissen and Michael Wetter:
+ Now printing different messages if temperature is above or below its limit,
+ and adding instance name as JModelica does not print the full instance name in the assertion.
+ This is for
+ #1045.
-
- November 25, 2008, by Michael Wetter:
- First implementation.
+ November 4, 2016, by Michael Wetter:
+ Set default value for dT.start in base properties.
+ This is for
+ #575.
-
-
--------- Corrected Code --------
-
- Block that outputs the number of inputs that exceed a threshold. The
- parameter kind is used to determine the kind of the
- inequality. The table below shows the allowed settings.
-
-
-
-
- Value of parameter kind
- |
-
- Output signal incremented by 1 for each i ∈ {1, ..., nin}
- if
- |
-
-
- |
- 0
- |
-
- u[i] > threShold
- |
-
-
- |
- 1
- |
-
- u[i] ≥ threShold
- |
-
-
- |
- 2
- |
-
- u[i] ≤ threShold
- |
-
-
- |
- 3
- |
-
- u[i] < threShold
- |
-
-
-
- This model may be used to check how many rooms exceed a temperature
- threshold.
-
-
- - November 21, 2011, by Michael Wetter:
- Improved documentation.
-
- - November 25, 2008, by Michael Wetter:
- First implementation.
-
-
-
--------- Errors --------
-line 7 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-
-
----- AixLib/Controls/SetPoints/Examples/OccupancySchedule.mo ----
--------- HTML Code --------
-
-
- Example that demonstrates the use of the occupancy schedule.
- The figure below shows how the time until the next occupancy starts or ends
- is decreased. The red line hits zero when the schedule indicates an occupied time,
- and the blue line hits zero when the schedule indicates a non-occupied time.
-
-
-
-
-
-
-
- November 21, 2011, by Michael Wetter:
- Added documentation.
+ June 6, 2015, by Michael Wetter:
+ Set AbsolutePressure(start=p_default) to avoid
+ a translation error if
+
+ AixLib.Fluid.Sources.Examples.TraceSubstancesFlowSource
+ is translated in pedantic mode in Dymola 2016.
+ The reason is that pressures use Medium.p_default as start values,
+ but
+
+ Modelica.Media.Interfaces.Types
+ sets a default value of 1E-5.
+ A similar change has been done for pressure.
+ This fixes
+ #266.
-
-
+ -
+ June 5, 2015, by Michael Wetter:
+ Added stateSelect attribute in BaseProperties.T
+ to allow correct use of preferredMediumState as
+ described in
+
+ Modelica.Media.Interfaces.PartialMedium.
+ Note that the default is preferredMediumState=false
+ and hence the same states are used as were used before.
+ This is for
+ #260.
+
+ -
+ May 11, 2015, by Michael Wetter:
+ Removed
+ p(stateSelect=if preferredMediumStates then StateSelect.prefer else StateSelect.default)
+ in declaration of BaseProperties.
+ Otherwise, when models that contain a fluid volume
+ are exported as an FMU, their pressure would be
+ differentiated with respect to time. This would require
+ the time derivative of the inlet pressure, which is not available,
+ causing the translation to stop with an error.
+
+ -
+ May 1, 2015, by Michael Wetter:
+ Added Inline=true for
+
+ issue 227.
+
+ -
+ March 20, 2015, by Michael Wetter:
+ Added missing term state.p/reference_p in function
+ specificEntropy.
+ #193.
+
+ -
+ February 3, 2015, by Michael Wetter:
+ Removed stateSelect.prefer for temperature.
+ This is for
+ #160.
+
+ -
+ July 24, 2014, by Michael Wetter:
+ Changed implementation to use
+
+ AixLib.Utilities.Psychrometrics.Constants.
+ This was done to use consistent values throughout the library.
+
+ -
+ November 16, 2013, by Michael Wetter:
+ Revised and simplified the implementation.
+
+ -
+ November 14, 2013, by Michael Wetter:
+ Removed function
+ HeatCapacityOfWater
+ which is neither needed nor implemented in the
+ Modelica Standard Library.
+
+ -
+ November 13, 2013, by Michael Wetter:
+ Removed non-used computations in specificEnthalpy_pTX and
+ in temperature_phX.
+
+ -
+ March 29, 2013, by Michael Wetter:
+ Added final standardOrderComponents=true in the
+ BaseProperties declaration. This avoids an error
+ when models are checked in Dymola 2014 in the pedenatic mode.
+
+ -
+ April 12, 2012, by Michael Wetter:
+ Added keyword each to Xi(stateSelect=...).
+
+ -
+ April 4, 2012, by Michael Wetter:
+ Added redeclaration of ThermodynamicState to avoid a warning
+ during model check and translation.
+
+ -
+ August 3, 2011, by Michael Wetter:
+ Fixed bug in u=h-R*T, which is only valid for ideal gases.
+ For this medium, the function is u=h-pStd/dStp.
+
+ -
+ January 27, 2010, by Michael Wetter:
+ Fixed bug in else branch of function setState_phX
+ that lead to a run-time error when the constructor of this function was called.
+
+ -
+ January 22, 2010, by Michael Wetter:
+ Added implementation of function
+
+ enthalpyOfNonCondensingGas and its derivative.
+
+ -
+ January 13, 2010, by Michael Wetter:
+ Fixed implementation of derivative functions.
+
+ -
+ August 28, 2008, by Michael Wetter:
+ First implementation.
+
+
+
-------- Corrected Code --------
- Example that demonstrates the use of the occupancy schedule. The
- figure below shows how the time until the next occupancy starts or
- ends is decreased. The red line hits zero when the schedule indicates
- an occupied time, and the blue line hits zero when the schedule
- indicates a non-occupied time.
+ Model with basic thermodynamic properties.
-
-
+
+ This model provides equation for the following thermodynamic
+ properties:
+
+
+ |
+ Variable
+ |
+
+ Unit
+ |
+
+ Description
+ |
+
+
+ |
+ T
+ |
+
+ K
+ |
+
+ temperature
+ |
+
+
+ |
+ p
+ |
+
+ Pa
+ |
+
+ absolute pressure
+ |
+
+
+ |
+ d
+ |
+
+ kg/m3
+ |
+
+ density
+ |
+
+
+ |
+ h
+ |
+
+ J/kg
+ |
+
+ specific enthalpy
+ |
+
+
+ |
+ u
+ |
+
+ J/kg
+ |
+
+ specific internal energy
+ |
+
+
+ |
+ Xi[nXi]
+ |
+
+ kg/kg
+ |
+
+ independent mass fractions m_i/m
+ |
+
+
+ |
+ R
+ |
+
+ J/kg.K
+ |
+
+ gas constant
+ |
+
+
+ |
+ M
+ |
+
+ kg/mol
+ |
+
+ molar mass
+ |
+
+
- - November 21, 2011, by Michael Wetter:
- Added documentation.
+ - September 22, 2020, by Michael Wetter:
+ First implementation based on Modelica Standard Library, but with
+ noEvent added to check of bounds.
-
--------- Errors --------
-line 8 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/Movers/UsersGuide.mo ----
--------- HTML Code --------
-
+Density is computed from pressure, temperature and composition in the
+thermodynamic state record applying the ideal gas law.
-This package contains models for fans and pumps. The same models
-are used for fans or pumps.
-
-
-Model description
-A detailed description of the fan and pump models can be
-found in
-Wetter (2013).
-The models are implemented as described in this paper, except
-that equation (20) is no longer used. The reason is that
-the transition (24) caused the derivative
-
-
- d Δp(r(t), V(t)) ⁄ d r(t)
+ This function returns the dynamic viscosity.
+
+ Implementation
+
-to have an inflection point in the regularization region
-r(t) ∈ (δ/2, δ).
-This caused some models to not converge.
-To correct this, for r(t) < δ,
-the term V(t) ⁄ r(t) in (16)
-has been modified so that (16) can be used for any
-value of r(t).
-
-
-Below, the models are briefly described.
+ The function is based on the 5th order polynomial of Modelica.Media.Air.MoistAir.dynamicViscosity.
+ However, for the typical range of temperatures encountered in
+ building applications, a linear function sufficies. This
+ implementation is therefore the above 5th order polynomial,
+ linearized around 20°C. The relative error of this
+ linearization is 0.4% at -20°C, and less then
+ 0.2% between -5°C and +50°C.
-Performance data
+
+ - December 19, 2013, by Michael Wetter:
+ First implementation.
+
+
+The ideal gas constant for moist air is computed from thermodynamic
+state assuming that all water is in the gas phase.
+Pressure is returned from the thermodynamic state record input as a
+simple assignment.
-The models use
-performance curves that compute pressure rise,
-electrical power draw and efficiency as a function
-of the volume flow rate and the speed.
-The following performance curves are implemented:
+ This function returns the isobaric expansion coefficient at constant
+ pressure, which is zero for this medium. The isobaric expansion
+ coefficient at constant pressure is
-
-*Note: This record should not be used
-(i.e. use_powerCharacteristic should be false)
-for the movers that take as a control signal
-the mass flow rate or the head,
-unless also values for the record pressure are provided.
-The reason is that for these movers the record pressure
-is required to be able to compute the mover speed,
-which is required to be able to compute the electrical power
-correctly using similarity laws.
-If a Pressure record is not provided,
-the model will internally override use_powerCharacteristic=false.
-In this case the efficiency records will be used.
-Note that in this case an error is still introduced,
-but it is smaller than when using the power records.
-Compare
-
-AixLib.Fluid.Movers.Validation.PowerSimplified
-with
-
-AixLib.Fluid.Movers.Validation.PowerExact
-for an illustration of this error.
+
+ βp = - 1 ⁄ v (∂ v ⁄ ∂ T)p = 0,
-These performance curves are implemented in
-
-AixLib.Fluid.Movers.BaseClasses.Characteristics,
-and are used in the performance records in the package
-
-AixLib.Fluid.Movers.Data.
-The package
-
-AixLib.Fluid.Movers.Data
-contains different data records.
+ where v is the specific volume, T is the temperature
+ and p is the pressure.
-Models that use performance curves for pressure rise
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
-The models
-
-AixLib.Fluid.Movers.SpeedControlled_y and
-
-AixLib.Fluid.Movers.SpeedControlled_Nrpm
-take as an input either a control signal between 0 and 1, or the
-rotational speed in units of [1/min]. From this input and the current flow rate,
-they compute the pressure rise.
-This pressure rise is computed using a user-provided list of operating points that
-defines the fan or pump curve at full speed.
-For other speeds, similarity laws are used to scale the performance curves, as
-described in
-
-AixLib.Fluid.Movers.BaseClasses.Characteristics.pressure.
+ This function returns the isothermal compressibility coefficient. The
+ isothermal compressibility is
+
+
+ κT = -1 ⁄ v (∂ v ⁄ ∂ p)T = -1 ⁄ p,
-
-For example, suppose a pump needs to be modeled whose pressure versus flow relation crosses, at
-full speed, the points shown in the table below.
+ where v is the specific volume, T is the temperature
+ and p is the pressure.
-
-
- | Volume flow rate [m3⁄s] |
- Head [Pa] |
-
-
- | 0.0003 |
- 45000 |
-
-
- | 0.0006 |
- 35000 |
-
-
- | 0.0008 |
- 15000 |
-
-
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
-Then, a declaration would be
+ This function computes the specific entropy.
-
- AixLib.Fluid.Movers.SpeedControlled_y pum(
- redeclare package Medium = Medium,
- per.pressure(V_flow={0.0003,0.0006,0.0008},
- dp ={45,35,15}*1000))
- \"Circulation pump\";
-
-
-This will model the following pump curve for the pump input signal y=1.
+ The specific entropy of the mixture is obtained from
-
-![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Movers/UsersGuide/pumpCurve.png\"/)
+
+ s = ss + sm,
-
-Models that directly control the head or the mass flow rate
-The models
-AixLib.Fluid.Movers.FlowControlled_dp and
-
-AixLib.Fluid.Movers.FlowControlled_m_flow
-take as an input the pressure difference or the mass flow rate.
-This pressure difference or mass flow rate will be provided by the fan or pump,
-i.e., the fan or pump has idealized perfect control and infinite capacity.
-Using these models that take as an input the head or the mass flow rate often leads
-to smaller system of equations compared to using the models that take
-as an input the speed.
+ where ss is the entropy change due to the state
+ change (relative to the reference temperature) and
+ sm is the entropy change due to mixing of the dry
+ air and water vapor.
-These models can be configured for three different control inputs.
-For
-
-AixLib.Fluid.Movers.FlowControlled_dp,
-the head is as follows:
+ The entropy change due to change in state is obtained from
-
--
-
-If the parameter inputType==AixLib.Fluid.Types.InputType.Continuous,
-the head is dp=dp_in, where dp_in is an input connector.
+
+ ss = cv ln(T/T0) + R
+ ln(v/v0)
+ = cv ln(T/T0) + R ln(ρ0/ρ)
-
--
-If the parameter inputType==AixLib.Fluid.Types.InputType.Constant,
-the head is dp=constantHead, where constantHead is a parameter.
+ If we assume ρ = p0/(R T), and because
+ cp = cv + R, we can write
+
+
+ ss = cv ln(T/T0) + R
+ ln(T/T0)
+ =cp ln(T/T0).
-
--
-If the parameter inputType==AixLib.Fluid.Types.InputType.Stages,
-the head is dp=heads, where heads is a
-vectorized parameter. For example, if a mover has
-two stages and the head of the first stage should be 60% of the nominal head
-and the second stage equal to dp_nominal, set
-heads={0.6, 1}*dp_nominal.
-Then, the mover will have the following heads:
+ Next, the entropy of mixing is obtained from a reversible isothermal
+ expansion process. Hence,
+
+
+ sm = -R ∑i( Xi ⁄ Mi
+ ln(Yi p/p0)),
-
-
- input signal stage |
- Head [Pa] |
-
-
- | 0 |
- 0 |
-
-
- | 1 |
- 0.6*dp_nominal |
-
-
- | 2 |
- dp_nominal |
-
-
-
-
-Similarly, for
-
-AixLib.Fluid.Movers.FlowControlled_m_flow,
-the mass flow rate is as follows:
+ where R is the gas constant, X is the mass fraction,
+ M is the molar mass, and Y is the mole fraction.
-
--
-If the parameter inputType==AixLib.Fluid.Types.InputType.Continuous,
-the mass flow rate is m_flow=m_flow_in, where m_flow_in is an input connector.
+ To obtain the state for a given pressure, entropy and mass fraction,
+ use AixLib.Media.Air.setState_psX.
-
--
+
+ Limitations
+
-If the parameter inputType==AixLib.Fluid.Types.InputType.Constant,
-the mass flow rate is m_flow=constantMassFlowRate, where constantMassFlowRate is a parameter.
+ This function is only valid for a relative humidity below 100%.
-
--
+
+ - November 27, 2013, by Michael Wetter:
+ First implementation.
+
+
-If the parameter inputType==AixLib.Fluid.Types.InputType.Stages,
-the mass flow rate is m_flow=massFlowRates, where massFlowRates is a
-vectorized parameter. For example, if a mover has
-two stages and the mass flow rate of the first stage should be 60% of the nominal mass flow rate
-and the second stage equal to m_flow_nominal, set
-massFlowRates={0.6, 1}*m_flow_nominal.
-Then, the mover will have the following mass flow rates:
+ This function returns the partial derivative of density with respect
+ to pressure at constant temperature.
-
-
- input signal stage |
- Mass flow rates [kg/s] |
-
-
- | 0 |
- 0 |
-
-
- | 1 |
- 0.6*m_flow_nominal |
-
-
- | 2 |
- m_flow_nominal |
-
-
-
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
+
-These two models do not need to use a performance curve for the flow
-characteristics.
-The reason is that
+ This function computes the derivative of density with respect to
+ temperature at constant pressure.
+
--
-for given pressure rise (or mass flow rate), the mass flow rate (or pressure rise)
-is computed from the flow resistance of the duct or piping network, and
-
--
-at zero pressure difference, solving for the flow rate and the revolution leads to a singularity.
-
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
+
-However, the computation of the electrical power consumption
-requires the mover speed to be known
-and the computation of the mover speed requires the performance
-curves for the flow and efficiency/power characteristics.
-Therefore these performance curves do need to be provided
-if the user desires a correct electrical power computation.
-If the curves are not provided, a simplified computation is used,
-where the efficiency curve is used and assumed to be correct for all speeds.
-This loss of accuracy has the advantage that it allows to use the
-mover models without requiring flow and efficiency/power characteristics.
+ This function returns the partial derivative of density with respect
+ to mass fraction. This value is zero because in this medium, density
+ is proportional to pressure, but independent of the species
+ concentration.
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
-The model
-AixLib.Fluid.Movers.FlowControlled_dp
-has an option to control the mover such
-that the pressure difference set point is obtained
-across two remote points in the system.
-To use this functionality
-parameter prescribeSystemPressure has
-to be enabled and a differential pressure measurement
-must be connected to
-the pump input dpMea.
-This functionality is demonstrated in
-
-AixLib.Fluid.Movers.Validation.FlowControlled_dpSystem.
+ The
+ thermodynamic state record is computed from density
+ d, temperature T and composition
+ X.
+The
+thermodynamic state record is computed from pressure p, specific
+enthalpy h and composition X.
+The
+thermodynamic state record is computed from pressure p, temperature
+T and composition X.
-The models
-AixLib.Fluid.Movers.FlowControlled_dp and
-
-AixLib.Fluid.Movers.FlowControlled_m_flow
-both have a parameter m_flow_nominal. For
-
-AixLib.Fluid.Movers.FlowControlled_m_flow, this parameter
-is used for convenience to set a default value for the parameters
-constantMassFlowRate and
-massFlowRates.
-For both models, the value is also used for the following:
+ This function returns the thermodynamic state based on pressure,
+ specific entropy and mass fraction.
+
+
+ The state is computed by symbolically solving AixLib.Media.Air.specificEntropy
+ for temperature.
-
--
-To compute the
-size of the fluid volume that can be used to approximate the
-inertia of the mover if the energy dynamics is selected to be dynamic.
-
--
-To compute a default pressure curve if no pressure curve has been specified
-in the record
per.pressure.
-The default pressure curve is the line that intersects
-(dp, V_flow) = (dp_nominal, 0) and
-(dp, V_flow) = (m_flow_nominal/rho_default, 0).
-
--
-To regularize the equations near zero flow rate to ensure a numerically
-robust model.
-
+ - November 27, 2013, by Michael Wetter:
+ First implementation.
+
+
+Specific enthalpy as a function of temperature and species
+concentration. The pressure is input for compatibility with the medium
+models, but the specific enthalpy is independent of the pressure.
+
+ - April 30, 2015, by Filip Jorissen and Michael Wetter:
+ Added Inline=true for issue 227.
+
-However, otherwise m_flow_nominal does not affect the mass flow rate of the mover as
-the mass flow rate is determined by the input signal or the above explained parameters.
+ This function computes the specific enthalpy for an isentropic state
+ change from the temperature that corresponds to the state
+ refState to reference_T.
-Start-up and shut-down transients
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
+Temperature is returned from the thermodynamic state record input as a
+simple assignment.
-All models have a parameter use_inputFilter. This
-parameter affects the fan output as follows:
+ This function returns the molar mass.
-
--
-If
use_inputFilter=false, then the input signal y (or
-Nrpm, m_flow_in, or dp_in)
-is equal to the fan speed (or the mass flow rate or pressure rise).
-Thus, a step change in the input signal causes a step change in the fan speed (or mass flow rate or pressure rise).
-
--
-If
use_inputFilter=true, which is the default,
-then the fan speed (or the mass flow rate or the pressure rise)
-is equal to the output of a filter. This filter is implemented
-as a 2nd order differential equation and can be thought of as
-approximating the inertia of the rotor and the fluid.
-Thus, a step change in the fan input signal will cause a gradual change
-in the fan speed.
-The filter has a parameter riseTime, which by default is set to
-30 seconds.
-The rise time is the time required to reach 99.6% of the full speed, or,
-if the fan is switched off, to reach a fan speed of 0.4%.
-
-
+
+ - December 18, 2013, by Michael Wetter:
+ First implementation.
+
+
+Temperature as a function of specific enthalpy and species
+concentration. The pressure is input for compatibility with the medium
+models, but the temperature is independent of the pressure.
+
+ - April 30, 2015, by Filip Jorissen and Michael Wetter:
+ Added Inline=true for issue 227.
+
+
-The figure below shows for a fan with use_inputFilter=true
-and riseTime=30 seconds the
-speed input signal and the actual speed.
-
-![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Movers/UsersGuide/fanSpeedFiltered.png\"/)
+ This data record contains the coefficients for perfect gases.
-
+
+ - September 12, 2014, by Michael Wetter:
+ Corrected the wrong location of the preferredView and
+ the revisions annotation.
+
+ - November 21, 2013, by Michael Wetter:
+ First implementation.
+
+
-Although many simulations do not require such a detailed model
-that approximates the transients of fans or pumps, it turns
-out that using this filter can reduce computing time and
-can lead to fewer convergence problems in large system models.
-With a filter, any sudden change in control signal, such as when
-a fan switches on, is damped before it affects the air flow rate.
-This continuous change in flow rate turns out to be easier, and in
-some cases faster, to simulate compared to a step change.
-For most simulations, we therefore recommend to use the default settings
-of use_inputFilter=true and riseTime=30 seconds.
-An exception are situations in which the fan or pump is operated at a fixed speed during
-the whole simulation. In this case, set use_inputFilter=false.
+ This medium package models moist air using a gas law in which
+ pressure and temperature are independent, which often leads to
+ significantly faster and more robust computations. The specific heat
+ capacities at constant pressure and at constant volume are constant.
+ The air is assumed to be not saturated.
-Note that if the fan is part of a closed loop control, then the filter affects
-the transient response of the control.
-When changing the value of use_inputFilter, the control gains
-may need to be retuned.
-We now present values control parameters that seem to work in most cases.
-Suppose there is a closed loop control with a PI-controller
-
-AixLib.Controls.Continuous.LimPID
-and a fan or pump, configured with use_inputFilter=true and riseTime=30 seconds.
-Assume that the transient response of the other dynamic elements in the control loop is fast
-compared to the rise time of the filter.
-Then, a proportional gain of k=0.5 and an integrator time constant of
-Ti=15 seconds often yields satisfactory closed loop control performance.
-These values may need to be changed for different applications as they are also a function
-of the loop gain.
-If the control loop shows oscillatory behavior, then reduce k and/or increase Ti.
-If the control loop reacts too slow, do the opposite.
-
-
-Efficiency and electrical power consumption
-
-All models compute the motor power draw Pele,
-the hydraulic power input Whyd, the flow work
-Wflo and the heat dissipated into the medium
-Q. Based on the first law, the flow work is
+ This medium uses the gas law
- Wflo = | V̇ Δp |,
+ ρ/ρstp = p/pstp,
-where V̇ is the volume flow rate and
-Δp is the pressure rise.
-The heat dissipated into the medium is as follows:
-If the motor is cooled by the fluid, as indicated by
-per.motorCooledByFluid=true, then the heat dissipated into the medium is
+ where pstd and ρstp are constant
+ reference temperature and density, rathern than the ideal gas law
- Q = Pele - Wflo.
+ ρ = p ⁄(R T),
-
-If per.motorCooledByFluid=false, then the motor is outside the fluid stream,
-and only the shaft, or hydraulic, work Whyd enters the thermodynamic
-control volume. Hence,
-
-
- Q = Whyd - Wflo.
-
-The efficiencies are computed as
-
- η = Wflo ⁄ Pele = ηhyd ηmot
- ηhyd = Wflo ⁄ Whyd
- ηmot = Whyd ⁄ Pele
+ where R is the gas constant and T is the temperature.
-where
-ηhyd is the hydraulic efficiency,
-ηmot is the motor efficiency and
-Q is the heat released by the motor.
+
+ This formulation often leads to smaller systems of nonlinear
+ equations because equations for pressure and temperature are
+ decoupled. Therefore, if air inside a control volume such as room air
+ is heated, it does not increase its specific volume. Consequently,
+ merely heating or cooling a control volume does not affect the air
+ flow calculations in a duct network that may be connected to that
+ volume. Note that multizone air exchange simulation in which buoyancy
+ drives the air flow is still possible as the models in AixLib.Airflow.Multizone
+ compute the mass density using the function AixLib.Utilities.Psychrometrics.Functions.density_pTX
+ in which density is a function of temperature.
-If per.use_powerCharacteristic=true,
-then a set of data points for the power Pele for different
-volume flow rates at full speed needs to be provided by the user.
-Using the flow work Wflo and the electrical power input
-Pele, the total efficiency is computed as
+ Note that models in this package implement the equation for the
+ internal energy as
- η = Wflo ⁄ Pele,
+ u = h - pstp ⁄ ρstp,
-and the two efficiencies
-ηhyd
-and ηmot are computed as
+ where u is the internal energy per unit mass, h is the
+ enthalpy per unit mass, pstp is the static pressure
+ and ρstp is the mass density at standard pressure
+ and temperature. The reason for this implementation is that in
+ general,
- ηhyd = 1,
- ηmot = η.
+ h = u + p v,
-However, if per.use_powerCharacteristic=false, then
-performance data for
-ηhyd and
- ηmot need to be provided by the user, and hence
-the model computes
+ from which follows that
- η = ηhyd ηmot
- Pele = Wflo ⁄ η.
+ u = h - p v = h - p ⁄ ρ = h - pstp ⁄ ρstd,
-
-The efficiency data for the motor are a list of points
-V̇ and ηmot.
+ because p ⁄ ρ = pstp ⁄ ρstp in this
+ medium model.
-
-Fluid volume of the component
-All models can be configured to have a fluid volume at the low-pressure side.
-Adding such a volume sometimes helps the solver to find a solution during
-initialization and time integration of large models.
+ The enthalpy is computed using the convention that h=0 if
+ T=0 °C and no water vapor is present.
+
+ - September 28, 2020, by Michael Wetter:
+ Reformulated BaseProperties to avoid event-triggering
+ assertions.
+ This is for #1401.
+
+ - January 11, 2019 by Michael Wetter:
+ Reforulated assignment of X_int in
+ setState_psX.
+ This is for #1079.
+
+ - October 26, 2018, by Filip Jorissen and Michael Wetter:
+ Now printing different messages if temperature is above or below
+ its limit, and adding instance name as JModelica does not print the
+ full instance name in the assertion. This is for #1045.
+
+ - November 4, 2016, by Michael Wetter:
+ Set default value for dT.start in base properties.
+ This is for #575.
+
+ - June 6, 2015, by Michael Wetter:
+ Set AbsolutePressure(start=p_default) to avoid a
+ translation error if
+ AixLib.Fluid.Sources.Examples.TraceSubstancesFlowSource is
+ translated in pedantic mode in Dymola 2016. The reason is that
+ pressures use Medium.p_default as start values, but
+ Modelica.Media.Interfaces.Types
+ sets a default value of 1E-5. A similar change has been done
+ for pressure. This fixes #266.
+
+ - June 5, 2015, by Michael Wetter:
+ Added stateSelect attribute in
+ BaseProperties.T to allow correct use of
+ preferredMediumState as described in Modelica.Media.Interfaces.PartialMedium.
+ Note that the default is preferredMediumState=false
+ and hence the same states are used as were used before. This is for
+ #260.
+
+ - May 11, 2015, by Michael Wetter:
+ Removed p(stateSelect=if preferredMediumStates then
+ StateSelect.prefer else StateSelect.default) in declaration
+ of BaseProperties. Otherwise, when models that contain
+ a fluid volume are exported as an FMU, their pressure would be
+ differentiated with respect to time. This would require the time
+ derivative of the inlet pressure, which is not available, causing
+ the translation to stop with an error.
+
+ - May 1, 2015, by Michael Wetter:
+ Added Inline=true for issue 227.
+
+ - March 20, 2015, by Michael Wetter:
+ Added missing term state.p/reference_p in function
+ specificEntropy. #193.
+
+ - February 3, 2015, by Michael Wetter:
+ Removed stateSelect.prefer for temperature. This is
+ for #160.
+
+ - July 24, 2014, by Michael Wetter:
+ Changed implementation to use AixLib.Utilities.Psychrometrics.Constants.
+ This was done to use consistent values throughout the library.
+
+ - November 16, 2013, by Michael Wetter:
+ Revised and simplified the implementation.
+
+ - November 14, 2013, by Michael Wetter:
+ Removed function HeatCapacityOfWater which is neither
+ needed nor implemented in the Modelica Standard Library.
+
+ - November 13, 2013, by Michael Wetter:
+ Removed non-used computations in specificEnthalpy_pTX
+ and in temperature_phX.
+
+ - March 29, 2013, by Michael Wetter:
+ Added final standardOrderComponents=true in the
+ BaseProperties declaration. This avoids an error when
+ models are checked in Dymola 2014 in the pedenatic mode.
+
+ - April 12, 2012, by Michael Wetter:
+ Added keyword each to
+ Xi(stateSelect=...).
+
+ - April 4, 2012, by Michael Wetter:
+ Added redeclaration of ThermodynamicState to avoid a
+ warning during model check and translation.
+
+ - August 3, 2011, by Michael Wetter:
+ Fixed bug in u=h-R*T, which is only valid for ideal
+ gases. For this medium, the function is u=h-pStd/dStp.
+
+ - January 27, 2010, by Michael Wetter:
+ Fixed bug in else branch of function
+ setState_phX that lead to a run-time error when the
+ constructor of this function was called.
+
+ - January 22, 2010, by Michael Wetter:
+ Added implementation of function
+ enthalpyOfNonCondensingGas and its derivative.
+
+ - January 13, 2010, by Michael Wetter:
+ Fixed implementation of derivative functions.
+
+ - August 28, 2008, by Michael Wetter:
+ First implementation.
+
+
-Enthalpy change of the component
-
-If per.motorCooledByFluid=true, then
-the enthalpy change between the inlet and outlet fluid port is equal
-to the electrical power Pele that is consumed by the component.
-Otherwise, it is equal to the hydraulic work Whyd.
-The parameter addPowerToMedium, which is by default set to
-true, can be used to simplify the equations.
-If addPowerToMedium = false, then no enthalpy change occurs between
-inlet and outlet.
-This can lead to simpler equations, but the temperature rise across the component
-will be zero. In particular for fans, this simplification may not be permissible.
-
+-------- Errors --------
+line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-Differences to models in Modelica.Fluid.Machines
-
-The models in this package differ from
-Modelica.Fluid.Machines
-primarily in the following points:
-
-
--
-They use a different base class, which allows to have zero mass flow rate.
-The models in
Modelica.Fluid restrict the number of revolutions, and hence the flow
-rate, to be non-zero.
-
--
-For the model with prescribed pressure, the input signal is the
-pressure difference between the two ports, and not the absolute
-pressure at
port_b.
-
--
-The pressure calculations are based on total pressure in Pascals instead of the pump head in meters.
-This change was done to avoid ambiguities in the parameterization if the models are used as a fan
-with air as the medium. The original formulation in
-Modelica.Fluid.Machines converts head
-to pressure using the density
medium.d. Therefore, for fans,
-head would be converted to pressure using the density of air. However, for pumps,
-manufacturers typically publish the head in millimeters water (mmH2O).
-Therefore, to avoid confusion when using these models with media other than water,
-we changed the models to use total pressure in Pascals instead of head in meters.
-
--
-The performance data are interpolated using cubic hermite splines instead of polynomials.
-These functions are implemented in
-
-AixLib.Fluid.Movers.BaseClasses.Characteristics.
-
-
-References
-
-Michael Wetter.
-
-Fan and pump model that has a unique solution for any pressure
-boundary condition and control signal.
-Proc. of the 13th Conference of the International Building Performance
-Simulation Association, p. 3505-3512. Chambery, France. August 2013.
-
+line 7 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+line 8 column 2 - Warning: attribute "align" not allowed for HTML5
+line 21 column 2 - Warning: attribute "align" not allowed for HTML5
+line 29 column 2 - Warning: attribute "align" not allowed for HTML5
+line 37 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+line 19 column 2 - Warning: attribute "align" not allowed for HTML5
+line 43 column 2 - Warning: attribute "align" not allowed for HTML5
+line 54 column 2 - Warning: attribute "align" not allowed for HTML5
+line 60 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/BoundaryConditions/Validation/BESTEST/WD400.mo ----
+-------- HTML Code --------
+
+
+ -
+ September 6, 2021, by Ettore Zanetti:
+ Removed parameter lat as it is now obtained from the weather data bus.
+ This is for
+ IBPSA, #1477.
+
+ -
+ March 11, 2020, by Ettore Zanetti:
+ First implementation.
+
+ -
+ April 14, 2020, by Ettore Zanetti:
+ Rework after comments from pull request
+ #1339.
+
+ -
+ May 2, 2021, by Ettore Zanetti:
+ Updated weather file as explained in #1478.
+
+
+
+ WD400: High Latitude Case
+ Weather data file : WD400.epw
+ Table 1: Site Data for Weather file WD400.epw
+
+ Latitude |
+ 71.286° north |
+
+
+ Longitude |
+ 156.767° west |
+
+
+ Altitude |
+ 10 m |
+
+
+ Time Zone |
+ -9 |
+
+
+
-------- Corrected Code --------
-
- This package contains models for fans and pumps. The same models are
- used for fans or pumps.
-
+
+ - September 6, 2021, by Ettore Zanetti:
+ Removed parameter lat as it is now obtained from the
+ weather data bus.
+ This is for IBPSA,
+ #1477.
+
+ - March 11, 2020, by Ettore Zanetti:
+ First implementation.
+
+ - April 14, 2020, by Ettore Zanetti:
+ Rework after comments from pull request #1339.
+
+ - May 2, 2021, by Ettore Zanetti:
+ Updated weather file as explained in #1478.
+
+
- Model description
+ WD400: High Latitude Case
- A detailed description of the fan and pump models can be found in
-
- Wetter (2013). The models are implemented as described in this
- paper, except that equation (20) is no longer used. The reason is
- that the transition (24) caused the derivative
-
-
- d Δp(r(t), V(t)) ⁄ d r(t)
-
-
- to have an inflection point in the regularization region r(t) ∈
- (δ/2, δ). This caused some models to not converge. To correct
- this, for r(t) < δ, the term V(t) ⁄ r(t) in (16) has
- been modified so that (16) can be used for any value of r(t).
-
-
- Below, the models are briefly described.
+ Weather data file : WD400.epw
-
- Performance data
-
- The models use performance curves that compute pressure rise,
- electrical power draw and efficiency as a function of the volume flow
- rate and the speed. The following performance curves are implemented:
+ Table 1: Site Data for Weather file WD400.epw
-
-
- |
- Independent variable
- |
-
- Dependent variable
- |
-
- Record for performance data
- |
-
- Function
- |
-
+
-
- *Note: This record should not be used (i.e.
- use_powerCharacteristic should be false)
- for the movers that take as a control signal the mass flow rate or
- the head, unless also values for the record pressure are
- provided. The reason is that for these movers the record
- pressure is required to be able to compute the mover
- speed, which is required to be able to compute the electrical power
- correctly using similarity laws. If a Pressure record is
- not provided, the model will internally override
- use_powerCharacteristic=false. In this case the
- efficiency records will be used. Note that in this case an error is
- still introduced, but it is smaller than when using the power
- records. Compare AixLib.Fluid.Movers.Validation.PowerSimplified
- with AixLib.Fluid.Movers.Validation.PowerExact
- for an illustration of this error.
-
-
- These performance curves are implemented in AixLib.Fluid.Movers.BaseClasses.Characteristics,
- and are used in the performance records in the package AixLib.Fluid.Movers.Data.
- The package AixLib.Fluid.Movers.Data
- contains different data records.
-
-
- Models that use performance curves for pressure rise
-
-
- The models AixLib.Fluid.Movers.SpeedControlled_y
- and AixLib.Fluid.Movers.SpeedControlled_Nrpm
- take as an input either a control signal between 0 and
- 1, or the rotational speed in units of [1/min]. From
- this input and the current flow rate, they compute the pressure rise.
- This pressure rise is computed using a user-provided list of
- operating points that defines the fan or pump curve at full speed.
- For other speeds, similarity laws are used to scale the performance
- curves, as described in
- AixLib.Fluid.Movers.BaseClasses.Characteristics.pressure.
+
+-------- Errors --------
+line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+
+
+---- AixLib/Fluid/Actuators/Valves/TwoWayTable.mo ----
+-------- HTML Code --------
+
+
+ Two way valve with opening characteristic that is configured through
+ a table.
+
+
+ The mass flow rate for the fully open valve is determined based
+ on the value of the parameter CvData.
+ For the different valve positions y ∈ [0, 1], this nominal flow rate is
+ scaled by the values of the parameter
+ flowCharacteristics.
+ The parameter flowCharacteristics declares a table of the form
+
+
+
+ | y | 0 | ... | 1 |
+
+
+ | φ | l | ... | 1 |
+
+
+
+ where l = Kv(y=0)/Kv(y=1) > 0 is the valve leakage.
+ The first row is the valve opening, and the second row is the
+ mass flow rate, relative to the mass flow rate of the fully open
+ valve, under the assumption of a constant pressure difference across the
+ valve.
+ A suggested value for the valve leakage is l=0.0001.
+ If l = 0, then this model will replace it with
+ l = 10-8 for numerical reasons.
+ For example, if a valve has Kv=0.5 [m3/h/bar1/2] and
+ a linear opening characteristics and
+ a valve leakage of l=0.0001, then one would set
+
+
+ CvData=AixLib.Fluid.Types.CvTypes.Kv
+ Kv = 0.5
+ flowCharacteristics(y={0,1}, phi={0.0001,1})
+
+
+ Note, however, that
+
+ AixLib.Fluid.Actuators.Valves.TwoWayLinear provides a more
+ efficient implementation for this simple case.
+
+
+ The parameter flowCharacteristics must meet the following
+ requirements, otherwise the model stops with an error:
+
+
+ -
+ Their arrays
+
y and phi
+ must be strictly monotonic increasing.
+
+ -
+ The first value must satisfy
+
y[1]=0, and
+ phi[1] must be equal to the
+ leakage flow rate, which must be bigger than zero.
+ Otherwise, a default value of 1E-8 is used.
+
+ -
+ The last values must satisfy
+
y[end]=1 and
+ phi[end]=1.
+
+
+
+ This model is based on the partial valve model
+
+ AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve.
+ Check this model for more information, such
+ as the regularization near the origin.
+
+
+ For an example that specifies an opening characteristics, see
+
+ AixLib.Fluid.Actuators.Valves.Examples.TwoWayValveTable.
+
+
+
+ -
+ June 10, 2021, by Michael Wetter:
+ Changed implementation of the filter and changed the parameter order to a constant
+ as most users need not change this value.
+ This is for
+ #1498.
+
+ -
+ August 7, 2020, by Ettore Zanetti:
+ changed the computation of phi using
+ max(0.1*l, . ) to avoid
+ phi=0.
+ See
+ issue 1376.
+
+ -
+ November 9, 2019, by Filip Jorissen:
+ Guarded the computation of phi using
+ max(0, . ) to avoid
+ negative phi.
+ See
+ issue 1223.
+
+ -
+ January 26, 2016, by Michael Wetter:
+ Removed equality comparison for Real in the
+ assert statements as this is not allowed in Modelica.
+
+ -
+ August 12, 2014, by Michael Wetter:
+ Removed the end keyword when accessing array elements,
+ as this language construct caused an error in OpenModelica.
+
+ -
+ April 4, 2014, by Michael Wetter:
+ Moved the assignment of the flow function phi
+ to the model instantiation because in its base class,
+ the keyword input
+ has been added to the variable phi.
+
+ -
+ March 26, 2014 by Michael Wetter:
+ First implementation.
+
+
+
+-------- Corrected Code --------
+
+ Two way valve with opening characteristic that is configured through
+ a table.
- For example, suppose a pump needs to be modeled whose pressure versus
- flow relation crosses, at full speed, the points shown in the table
- below.
+ The mass flow rate for the fully open valve is determined based on
+ the value of the parameter CvData. For the different
+ valve positions y ∈ [0, 1], this nominal flow rate is scaled
+ by the values of the parameter flowCharacteristics. The
+ parameter flowCharacteristics declares a table of the
+ form
-
- |
- Volume flow rate [m3⁄s]
- |
-
- Head [Pa]
- |
-
|
- 0.0003
+ y
|
- 45000
+ 0
|
-
-
|
- 0.0006
+ ...
|
- 35000
+ 1
|
|
- 0.0008
+ φ
|
- 15000
+ l
+ |
+
+ ...
+ |
+
+ 1
|
- Then, a declaration would be
+ where l = Kv(y=0)/Kv(y=1) > 0 is the
+ valve leakage. The first row is the valve opening, and the second row
+ is the mass flow rate, relative to the mass flow rate of the fully
+ open valve, under the assumption of a constant pressure difference
+ across the valve. A suggested value for the valve leakage is
+ l=0.0001. If l = 0, then this model will replace it
+ with l = 10-8 for numerical reasons. For example,
+ if a valve has Kv=0.5
+ [m3/h/bar1/2] and a linear opening
+ characteristics and a valve leakage of l=0.0001, then one
+ would set
- AixLib.Fluid.Movers.SpeedControlled_y pum(
- redeclare package Medium = Medium,
- per.pressure(V_flow={0.0003,0.0006,0.0008},
- dp ={45,35,15}*1000))
- \"Circulation pump\";
-
+ CvData=AixLib.Fluid.Types.CvTypes.Kv
+ Kv = 0.5
+ flowCharacteristics(y={0,1}, phi={0.0001,1})
+
- This will model the following pump curve for the pump input signal
- y=1.
+ Note, however, that AixLib.Fluid.Actuators.Valves.TwoWayLinear
+ provides a more efficient implementation for this simple case.
-
-
+
+ The parameter flowCharacteristics must meet the
+ following requirements, otherwise the model stops with an error:
-
- Models that directly control the head or the mass flow rate
-
+
+ - Their arrays
y and phi must be strictly
+ monotonic increasing.
+
+ - The first value must satisfy
y[1]=0, and
+ phi[1] must be equal to the leakage flow rate, which
+ must be bigger than zero. Otherwise, a default value of
+ 1E-8 is used.
+
+ - The last values must satisfy
y[end]=1 and
+ phi[end]=1.
+
+
- The models AixLib.Fluid.Movers.FlowControlled_dp
- and AixLib.Fluid.Movers.FlowControlled_m_flow
- take as an input the pressure difference or the mass flow rate. This
- pressure difference or mass flow rate will be provided by the fan or
- pump, i.e., the fan or pump has idealized perfect control and
- infinite capacity. Using these models that take as an input the head
- or the mass flow rate often leads to smaller system of equations
- compared to using the models that take as an input the speed.
+ This model is based on the partial valve model AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve.
+ Check this model for more information, such as the regularization
+ near the origin.
- These models can be configured for three different control inputs.
- For AixLib.Fluid.Movers.FlowControlled_dp,
- the head is as follows:
+ For an example that specifies an opening characteristics, see
+
+ AixLib.Fluid.Actuators.Valves.Examples.TwoWayValveTable.
- -
-
- If the parameter
- inputType==AixLib.Fluid.Types.InputType.Continuous,
- the head is dp=dp_in, where dp_in is an
- input connector.
-
-
- -
-
- If the parameter
- inputType==AixLib.Fluid.Types.InputType.Constant,
- the head is dp=constantHead, where
- constantHead is a parameter.
-
+ - June 10, 2021, by Michael Wetter:
+ Changed implementation of the filter and changed the parameter
+ order to a constant as most users need not change this
+ value.
+ This is for #1498.
- -
-
- If the parameter
- inputType==AixLib.Fluid.Types.InputType.Stages, the
- head is dp=heads, where heads is a
- vectorized parameter. For example, if a mover has two stages and
- the head of the first stage should be 60% of the nominal
- head and the second stage equal to dp_nominal, set
- heads={0.6, 1}*dp_nominal. Then, the mover will have
- the following heads:
-
-
-
-
- input signal stage
- |
-
- Head [Pa]
- |
-
-
- |
- 0
- |
-
- 0
- |
-
-
- |
- 1
- |
-
- 0.6*dp_nominal
- |
-
-
- |
- 2
- |
-
- dp_nominal
- |
-
-
+ - August 7, 2020, by Ettore Zanetti:
+ changed the computation of phi using max(0.1*l,
+ . ) to avoid phi=0. See issue
+ 1376.
-
-
- Similarly, for AixLib.Fluid.Movers.FlowControlled_m_flow,
- the mass flow rate is as follows:
-
-
- -
-
- If the parameter
- inputType==AixLib.Fluid.Types.InputType.Continuous,
- the mass flow rate is m_flow=m_flow_in, where
- m_flow_in is an input connector.
-
+ - November 9, 2019, by Filip Jorissen:
+ Guarded the computation of phi using max(0, .
+ ) to avoid negative phi. See issue
+ 1223.
- -
-
- If the parameter
- inputType==AixLib.Fluid.Types.InputType.Constant,
- the mass flow rate is m_flow=constantMassFlowRate,
- where constantMassFlowRate is a parameter.
-
+ - January 26, 2016, by Michael Wetter:
+ Removed equality comparison for Real in the
+ assert statements as this is not allowed in Modelica.
- -
-
- If the parameter
- inputType==AixLib.Fluid.Types.InputType.Stages, the
- mass flow rate is m_flow=massFlowRates, where
- massFlowRates is a vectorized parameter. For
- example, if a mover has two stages and the mass flow rate of the
- first stage should be 60% of the nominal mass flow rate
- and the second stage equal to m_flow_nominal, set
- massFlowRates={0.6, 1}*m_flow_nominal. Then, the
- mover will have the following mass flow rates:
-
-
-
-
- input signal stage
- |
-
- Mass flow rates [kg/s]
- |
-
-
- |
- 0
- |
-
- 0
- |
-
-
- |
- 1
- |
-
- 0.6*m_flow_nominal
- |
-
-
- |
- 2
- |
-
- m_flow_nominal
- |
-
-
+ - August 12, 2014, by Michael Wetter:
+ Removed the end keyword when accessing array elements,
+ as this language construct caused an error in OpenModelica.
-
-
- These two models do not need to use a performance curve for the flow
- characteristics. The reason is that
-
-
- - for given pressure rise (or mass flow rate), the mass flow rate
- (or pressure rise) is computed from the flow resistance of the duct
- or piping network, and
+
- April 4, 2014, by Michael Wetter:
+ Moved the assignment of the flow function phi to the
+ model instantiation because in its base class, the keyword
+ input has been added to the variable phi.
- - at zero pressure difference, solving for the flow rate and the
- revolution leads to a singularity.
+
- March 26, 2014 by Michael Wetter:
+ First implementation.
+
+-------- Errors --------
+line 14 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+
+
+---- AixLib/Fluid/HeatExchangers/BaseClasses/HANaturalCylinder.mo ----
+-------- HTML Code --------
+
+
+ This model calculates the convection coefficient h for natural convection
+ from a cylinder submerged in fluid. h is calcualted using Eq 9.34 from
+ Incropera and DeWitt (1996).
+ Output of the block is the hA value.
+
+
+ The Nusselt number is computed as
+
+
+ NuD = (0.6 + (0.387 RaD(1/6))/(1+(0.559 Pr)
+ (9/16))(8/27))2);
+
+
+ where NuD is the Nusselt number, RaD is the
+ Rayleigh number and
+ Pr is the Prandtl number.
+ This correclation is accurate for RaD less than 1012.
+
+
+ h is then calculated from the Nusselt number. The equation is
+
+
+ h = NuD k/D
+
+
+ where k is the thermal conductivity of the fluid and D is the diameter
+ of the submerged cylinder.
+
+ References
+
+ Fundamentals of Heat and Mass Transfer (Fourth Edition), Frank Incropera and David
+ DeWitt, John Wiley and Sons, 1996
+
+
+
+ -
+ August 29, 2014 by Michael Wetter:
+ Refactored function calls for medium properties.
+
+ -
+ May 10, 2013 by Michael Wetter:
+ Revised implementation to use hA_nominal as a parameter, and compute the
+ associated surface area A. This revision was required to have a consistent
+ computation of the hA values inside and outside of the coil in the
+ heat exchanger model of the water tank.
+
+ -
+ February 26, 2013 by Peter Grant:
+ First implementation.
+
+
+
+-------- Corrected Code --------
- However, the computation of the electrical power consumption requires
- the mover speed to be known and the computation of the mover speed
- requires the performance curves for the flow and efficiency/power
- characteristics. Therefore these performance curves do need to be
- provided if the user desires a correct electrical power computation.
- If the curves are not provided, a simplified computation is used,
- where the efficiency curve is used and assumed to be correct for all
- speeds. This loss of accuracy has the advantage that it allows to use
- the mover models without requiring flow and efficiency/power
- characteristics.
+ This model calculates the convection coefficient h for natural
+ convection from a cylinder submerged in fluid. h is calcualted
+ using Eq 9.34 from Incropera and DeWitt (1996). Output of the block
+ is the hA value.
- The model AixLib.Fluid.Movers.FlowControlled_dp
- has an option to control the mover such that the pressure difference
- set point is obtained across two remote points in the system. To use
- this functionality parameter prescribeSystemPressure has
- to be enabled and a differential pressure measurement must be
- connected to the pump input dpMea. This functionality is
- demonstrated in AixLib.Fluid.Movers.Validation.FlowControlled_dpSystem.
+ The Nusselt number is computed as
+
+
+ NuD = (0.6 + (0.387
+ RaD(1/6))/(1+(0.559 Pr)
+ (9/16))(8/27))2);
- The models AixLib.Fluid.Movers.FlowControlled_dp
- and AixLib.Fluid.Movers.FlowControlled_m_flow
- both have a parameter m_flow_nominal. For AixLib.Fluid.Movers.FlowControlled_m_flow,
- this parameter is used for convenience to set a default value for the
- parameters constantMassFlowRate and
- massFlowRates. For both models, the value is also used
- for the following:
-
-
- - To compute the size of the fluid volume that can be used to
- approximate the inertia of the mover if the energy dynamics is
- selected to be dynamic.
-
- - To compute a default pressure curve if no pressure curve has been
- specified in the record
per.pressure. The default
- pressure curve is the line that intersects (dp, V_flow) =
- (dp_nominal, 0) and (dp, V_flow) =
- (m_flow_nominal/rho_default, 0).
-
- - To regularize the equations near zero flow rate to ensure a
- numerically robust model.
-
-
-
- However, otherwise m_flow_nominal does not affect the
- mass flow rate of the mover as the mass flow rate is determined by
- the input signal or the above explained parameters.
-
-
- Start-up and shut-down transients
-
-
- All models have a parameter use_inputFilter. This
- parameter affects the fan output as follows:
-
-
- - If
use_inputFilter=false, then the input signal
- y (or Nrpm, m_flow_in, or
- dp_in) is equal to the fan speed (or the mass flow rate
- or pressure rise). Thus, a step change in the input signal causes a
- step change in the fan speed (or mass flow rate or pressure rise).
-
- - If
use_inputFilter=true, which is the default, then
- the fan speed (or the mass flow rate or the pressure rise) is equal
- to the output of a filter. This filter is implemented as a 2nd order
- differential equation and can be thought of as approximating the
- inertia of the rotor and the fluid. Thus, a step change in the fan
- input signal will cause a gradual change in the fan speed. The filter
- has a parameter riseTime, which by default is set to
- 30 seconds. The rise time is the time required to reach
- 99.6% of the full speed, or, if the fan is switched off, to
- reach a fan speed of 0.4%.
-
-
-
- The figure below shows for a fan with
- use_inputFilter=true and riseTime=30
- seconds the speed input signal and the actual speed.
-
-
-
-
-
- Although many simulations do not require such a detailed model that
- approximates the transients of fans or pumps, it turns out that using
- this filter can reduce computing time and can lead to fewer
- convergence problems in large system models. With a filter, any
- sudden change in control signal, such as when a fan switches on, is
- damped before it affects the air flow rate. This continuous change in
- flow rate turns out to be easier, and in some cases faster, to
- simulate compared to a step change. For most simulations, we
- therefore recommend to use the default settings of
- use_inputFilter=true and riseTime=30
- seconds. An exception are situations in which the fan or pump is
- operated at a fixed speed during the whole simulation. In this case,
- set use_inputFilter=false.
-
-
- Note that if the fan is part of a closed loop control, then the
- filter affects the transient response of the control. When changing
- the value of use_inputFilter, the control gains may need
- to be retuned. We now present values control parameters that seem to
- work in most cases. Suppose there is a closed loop control with a
- PI-controller AixLib.Controls.Continuous.LimPID
- and a fan or pump, configured with use_inputFilter=true
- and riseTime=30 seconds. Assume that the transient
- response of the other dynamic elements in the control loop is fast
- compared to the rise time of the filter. Then, a proportional gain of
- k=0.5 and an integrator time constant of
- Ti=15 seconds often yields satisfactory closed loop
- control performance. These values may need to be changed for
- different applications as they are also a function of the loop gain.
- If the control loop shows oscillatory behavior, then reduce
- k and/or increase Ti. If the control loop
- reacts too slow, do the opposite.
-
-
- Efficiency and electrical power consumption
-
-
- All models compute the motor power draw Pele, the
- hydraulic power input Whyd, the flow work
- Wflo and the heat dissipated into the medium
- Q. Based on the first law, the flow work is
-
-
- Wflo = | V̇ Δp |,
-
-
- where V̇ is the volume flow rate and Δp is the pressure
- rise. The heat dissipated into the medium is as follows: If the motor
- is cooled by the fluid, as indicated by
- per.motorCooledByFluid=true, then the heat dissipated
- into the medium is
-
-
- Q = Pele - Wflo.
-
-
- If per.motorCooledByFluid=false, then the motor is
- outside the fluid stream, and only the shaft, or hydraulic, work
- Whyd enters the thermodynamic control volume.
- Hence,
-
-
- Q = Whyd - Wflo.
-
-
- The efficiencies are computed as
-
-
- η = Wflo ⁄ Pele = ηhyd
- ηmot
- ηhyd = Wflo ⁄ Whyd
- ηmot = Whyd ⁄ Pele
-
-
- where ηhyd is the hydraulic efficiency,
- ηmot is the motor efficiency and Q is the
- heat released by the motor.
-
-
- If per.use_powerCharacteristic=true, then a set of data
- points for the power Pele for different volume flow
- rates at full speed needs to be provided by the user. Using the flow
- work Wflo and the electrical power input
- Pele, the total efficiency is computed as
-
-
- η = Wflo ⁄ Pele,
-
-
- and the two efficiencies ηhyd and
- ηmot are computed as
-
-
- ηhyd = 1,
- ηmot = η.
+ where NuD is the Nusselt number,
+ RaD is the Rayleigh number and Pr is the
+ Prandtl number.
+ This correclation is accurate for RaD less than
+ 1012.
- However, if per.use_powerCharacteristic=false, then
- performance data for ηhyd and
- ηmot need to be provided by the user, and hence the
- model computes
+ h is then calculated from the Nusselt number. The equation is
- η = ηhyd ηmot
- Pele = Wflo ⁄ η.
-
-
- The efficiency data for the motor are a list of points V̇ and
- ηmot.
-
-
- Fluid volume of the component
-
-
- All models can be configured to have a fluid volume at the
- low-pressure side. Adding such a volume sometimes helps the solver to
- find a solution during initialization and time integration of large
- models.
+ h = NuD k/D
-
- Enthalpy change of the component
-
- If per.motorCooledByFluid=true, then the enthalpy change
- between the inlet and outlet fluid port is equal to the electrical
- power Pele that is consumed by the component.
- Otherwise, it is equal to the hydraulic work Whyd.
- The parameter addPowerToMedium, which is by default set
- to true, can be used to simplify the equations. If
- addPowerToMedium = false, then no enthalpy change occurs
- between inlet and outlet. This can lead to simpler equations, but the
- temperature rise across the component will be zero. In particular for
- fans, this simplification may not be permissible.
+ where k is the thermal conductivity of the fluid and D
+ is the diameter of the submerged cylinder.
- Differences to models in Modelica.Fluid.Machines
+ References
- The models in this package differ from Modelica.Fluid.Machines primarily in
- the following points:
+ Fundamentals of Heat and Mass Transfer (Fourth Edition), Frank
+ Incropera and David DeWitt, John Wiley and Sons, 1996
- - They use a different base class, which allows to have zero mass
- flow rate. The models in
Modelica.Fluid restrict the
- number of revolutions, and hence the flow rate, to be non-zero.
-
- - For the model with prescribed pressure, the input signal is the
- pressure difference between the two ports, and not the absolute
- pressure at
port_b.
+ - August 29, 2014 by Michael Wetter:
+ Refactored function calls for medium properties.
- - The pressure calculations are based on total pressure in Pascals
- instead of the pump head in meters. This change was done to avoid
- ambiguities in the parameterization if the models are used as a fan
- with air as the medium. The original formulation in Modelica.Fluid.Machines converts head
- to pressure using the density
medium.d. Therefore, for
- fans, head would be converted to pressure using the density of air.
- However, for pumps, manufacturers typically publish the head in
- millimeters water (mmH2O). Therefore, to avoid confusion
- when using these models with media other than water, we changed the
- models to use total pressure in Pascals instead of head in meters.
+ - May 10, 2013 by Michael Wetter:
+ Revised implementation to use hA_nominal as a
+ parameter, and compute the associated surface area A.
+ This revision was required to have a consistent computation of the
+ hA values inside and outside of the coil in the heat
+ exchanger model of the water tank.
- - The performance data are interpolated using cubic hermite splines
- instead of polynomials. These functions are implemented in AixLib.Fluid.Movers.BaseClasses.Characteristics.
+
- February 26, 2013 by Peter Grant:
+ First implementation.
-
- References
-
-
- Michael Wetter.
- Fan and pump model that has a unique solution for any pressure
- boundary condition and control signal. Proc. of the 13th
- Conference of the International Building Performance Simulation
- Association, p. 3505-3512. Chambery, France. August 2013.
-
-------- Errors --------
-line 38 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
-line 126 column 3 - Warning: The summary attribute on the element is obsolete in HTML5
-line 205 column 3 - Warning: The summary attribute on the element is obsolete in HTML5
-line 254 column 3 - Warning: The summary attribute on the element is obsolete in HTML5
-line 15 column 1 - Warning: attribute "align" not allowed for HTML5
-line 158 column 1 - Warning: attribute "align" not allowed for HTML5
-line 380 column 1 - Warning: attribute "align" not allowed for HTML5
-line 425 column 1 - Warning: attribute "align" not allowed for HTML5
-line 435 column 1 - Warning: attribute "align" not allowed for HTML5
-line 444 column 1 - Warning: attribute "align" not allowed for HTML5
-line 448 column 1 - Warning: attribute "align" not allowed for HTML5
-line 465 column 1 - Warning: attribute "align" not allowed for HTML5
-line 473 column 1 - Warning: attribute "align" not allowed for HTML5
-line 484 column 1 - Warning: attribute "align" not allowed for HTML5
+line 11 column 14 - Warning: attribute "align" not allowed for HTML5
+line 24 column 14 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/MSLAIT.mo ----
+---- AixLib/Fluid/Sensors/SensibleEnthalpyFlowRate.mo ----
-------- HTML Code --------
- The example contains
-
- experimental data from a real district heating network.
- This data is used to validate this library's
-
- AixLib.Fluid.FixedResistances.PlugFlowPipe in
-
- AixLib.Fluid.FixedResistances.Validation.PlugFlowPipes.PlugFlowAIT.
- This model compares its performance with the original Modelica Standard Library
- pipes, using one discretization element per unit length of pipe.
- For a coarser discretization, please refer to
-
- MSLAIT2Nodes.
+ This model outputs the sensible enthalphy flow rate of the medium in the flow
+ between its fluid ports. In particular, if the total enthalpy flow rate is
-
- Note that these three models are identical, except for the pipe model that is used:
+
+ Ḣtot = Ḣsen + Ḣlat,
-
- This comparison between different discretization levels and pipe models is made
- to check the influence of the discretization and pipe model on computation time
- and simulation accuracy.
+ where
+ Ḣsen = ṁ (1-Xw) cp,air,
+ then this sensor outputs Ḣ = Ḣsen.
- The pipes' temperatures are not initialized, thus results of outflow
- temperature before approximately the first 10000 seconds should not be considered.
+
+
+ If the parameter tau is non-zero, then the measured
+ specific sensible enthalpy hout that is used to
+ compute the sensible enthalpy flow rate
+ Ḣsen = ṁ hout
+ is computed using a first order differential equation.
+ See
+ AixLib.Fluid.Sensors.UsersGuide for an explanation.
- Test bench schematic
-
- Calibration
- To calculate the length specific thermal resistance R of the
- pipe, the thermal resistance of the surrounding ground is added.
-
- R=1/(0.208)+1/(2 lambda_g Modelica.Constants.pi) log(1/0.18)
+
- Where the thermal conductivity of the ground lambda_g = 2.4 W/(m K).
+ For a sensor that measures
+ Ḣtot, use
+
+ AixLib.Fluid.Sensors.EnthalpyFlowRate.
+ For a sensor that measures
+ Ḣlat, use
+
+ AixLib.Fluid.Sensors.LatentEnthalpyFlowRate.
+
+ The sensor is ideal, i.e., it does not influence the fluid.
+ The sensor can only be used with medium models that implement the function
+ enthalpyOfNonCondensingGas(T).
+
+
-
- March 7, 2020, by Michael Wetter:
- Replaced measured data from specification in Modelica file to external table,
- as this reduces the computing time.
+ October 19, 2020, by Antoine Gautier:
+ Changed default value for tau from 1 to 0.
This is for
- #1289.
+ #1406.
-
- May 15, 2019, by Jianjun Hu:
- Replaced fluid source. This is for
- #1072.
+ February 25, 2020, by Michael Wetter:
+ Changed icon to display its operating state.
+ This is for
+ #1294.
- - November 28, 2016 by Bram van der Heijde:
Remove pipVol.
+ -
+ January 18, 2016 by Filip Jorissen:
+ Using parameter tauInv
+ since this now exists in
+ AixLib.Fluid.Sensors.BaseClasses.PartialDynamicFlowSensor.
+ This is for
+ #372.
- - August 24, 2016 by Bram van der Heijde:
- Implement validation with MSL pipes for comparison, based on AIT validation.
+ -
+ September 10, 2013, by Michael Wetter:
+ Changed medium declaration in the extends statement
+ to replaceable to avoid a translation error in
+ OpenModelica.
-
- July 4, 2016 by Bram van der Heijde:
Added parameters to test the
- influence of allowFlowReversal and the presence of explicit volumes in the pipe.
+ August 31, 2013, by Michael Wetter:
+ Removed default value tau=0 as the base class
+ already sets tau=1.
+ This change was made so that all sensors use the same default value.
+
+ -
+ December 18, 2012, by Michael Wetter:
+ Moved computation of i_w to new base class
+
+ AixLib.Fluid.BaseClasses.IndexWater.
+ The value of this parameter is now assigned dynamically and does not require to be specified
+ by the user.
+
+ -
+ November 3, 2011, by Michael Wetter:
+ Moved der(h_out) := 0; from the initial algorithm section to
+ the initial equation section
+ as this assignment does not conform to the Modelica specification.
+
+ -
+ August 10, 2011 by Michael Wetter:
+ Added parameter i_w and an assert statement to
+ make sure it is set correctly. Without this change, Dymola
+ cannot differentiate the model when reducing the index of the DAE.
+
+ -
+ June 3, 2011 by Michael Wetter:
+ Revised implementation to add dynamics in such a way that
+ the time constant increases as the mass flow rate tends to zero.
+ This can improve the numerics.
+
+ -
+ February 22, by Michael Wetter:
+ Improved code that searches for index of 'water' in the medium model.
+
+ -
+ September 9, 2009 by Michael Wetter:
+ First implementation.
+ Implementation is based on enthalpy sensor of Modelica.Fluid.
- - January 26, 2016 by Carles Ribas:
First implementation.
-------- Corrected Code --------
- The example contains
- experimental data from a real district heating network. This data
- is used to validate this library's AixLib.Fluid.FixedResistances.PlugFlowPipe
- in
- AixLib.Fluid.FixedResistances.Validation.PlugFlowPipes.PlugFlowAIT.
- This model compares its performance with the original Modelica
- Standard Library pipes, using one discretization element per unit
- length of pipe. For a coarser discretization, please refer to
-
- MSLAIT2Nodes.
-
-
- Note that these three models are identical, except for the pipe model
- that is used:
+ This model outputs the sensible enthalphy flow rate of the
+ medium in the flow between its fluid ports. In particular, if the
+ total enthalpy flow rate is
-
-
- This comparison between different discretization levels and pipe
- models is made to check the influence of the discretization and pipe
- model on computation time and simulation accuracy.
+
+ Ḣtot = Ḣsen + Ḣlat,
- The pipes' temperatures are not initialized, thus results of outflow
- temperature before approximately the first 10000 seconds should not
- be considered.
+ where Ḣsen = ṁ (1-Xw)
+ cp,air, then this sensor outputs Ḣ =
+ Ḣsen.
-
- Test bench schematic
-
-
+ If the parameter tau is non-zero, then the measured
+ specific sensible enthalpy hout that is used to
+ compute the sensible enthalpy flow rate Ḣsen = ṁ
+ hout is computed using a first order differential
+ equation. See AixLib.Fluid.Sensors.UsersGuide
+ for an explanation.
-
- Calibration
-
- To calculate the length specific thermal resistance R of
- the pipe, the thermal resistance of the surrounding ground is added.
-
-
- R=1/(0.208)+1/(2 lambda_g Modelica.Constants.pi)
- log(1/0.18)
+ For a sensor that measures Ḣtot, use AixLib.Fluid.Sensors.EnthalpyFlowRate.
+
+ For a sensor that measures Ḣlat, use AixLib.Fluid.Sensors.LatentEnthalpyFlowRate.
- Where the thermal conductivity of the ground lambda_g =
- 2.4 W/(m K).
+ The sensor is ideal, i.e., it does not influence the fluid. The
+ sensor can only be used with medium models that implement the
+ function enthalpyOfNonCondensingGas(T).
- - March 7, 2020, by Michael Wetter:
- Replaced measured data from specification in Modelica file to
- external table, as this reduces the computing time.
+ - October 19, 2020, by Antoine Gautier:
+ Changed default value for tau from 1 to
+ 0.
This is for #1289.
-
- - May 15, 2019, by Jianjun Hu:
- Replaced fluid source. This is for #1072.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/1406\">#1406.
- - November 28, 2016 by Bram van der Heijde:
- Remove pipVol.
+ - February 25, 2020, by Michael Wetter:
+ Changed icon to display its operating state.
+ This is for #1294.
- - August 24, 2016 by Bram van der Heijde:
- Implement validation with MSL pipes for comparison, based on AIT
- validation.
+ - January 18, 2016 by Filip Jorissen:
+ Using parameter tauInv since this now exists in
+
+ AixLib.Fluid.Sensors.BaseClasses.PartialDynamicFlowSensor. This
+ is for #372.
- - July 4, 2016 by Bram van der Heijde:
- Added parameters to test the influence of allowFlowReversal and the
- presence of explicit volumes in the pipe.
+ - September 10, 2013, by Michael Wetter:
+ Changed medium declaration in the extends statement to
+ replaceable to avoid a translation error in
+ OpenModelica.
- - January 26, 2016 by Carles Ribas:
- First implementation.
+ - August 31, 2013, by Michael Wetter:
+ Removed default value tau=0 as the base class already
+ sets tau=1. This change was made so that all sensors
+ use the same default value.
+
+ - December 18, 2012, by Michael Wetter:
+ Moved computation of i_w to new base class AixLib.Fluid.BaseClasses.IndexWater.
+ The value of this parameter is now assigned dynamically and does
+ not require to be specified by the user.
+
+ - November 3, 2011, by Michael Wetter:
+ Moved der(h_out) := 0; from the initial algorithm
+ section to the initial equation section as this assignment does not
+ conform to the Modelica specification.
+
+ - August 10, 2011 by Michael Wetter:
+ Added parameter i_w and an assert statement to make
+ sure it is set correctly. Without this change, Dymola cannot
+ differentiate the model when reducing the index of the DAE.
+
+ - June 3, 2011 by Michael Wetter:
+ Revised implementation to add dynamics in such a way that the time
+ constant increases as the mass flow rate tends to zero. This can
+ improve the numerics.
+
+ - February 22, by Michael Wetter:
+ Improved code that searches for index of 'water' in the medium
+ model.
+
+ - September 9, 2009 by Michael Wetter:
+ First implementation. Implementation is based on enthalpy sensor of
+ Modelica.Fluid.
-------- Errors --------
-line 56 column 2 - Warning: attribute "align" not allowed for HTML5
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Sources/Outside_CpLowRise.mo ----
+---- AixLib/Fluid/Geothermal/Borefields/UsersGuide.mo ----
-------- HTML Code --------
-
- This model describes boundary conditions for
- pressure, enthalpy, and species concentration that can be obtained
- from weather data. The model is identical to
-
- AixLib.Fluid.Sources.Outside,
- except that it adds the wind pressure to the
- pressure at the fluid port ports.
- The correlation that is used to compute the wind pressure is based
- on Swami and Chandra (1987) and valid for low-rise buildings
- with rectangular shape.
- The same correlation is also implemented in CONTAM (Persily and Ivy, 2001).
-
-
-
- The wind pressure coefficient is computed based on the
- side ratio of the walls, which is defined as
-
-
- s = x ⁄ y
-
-
- where x is the length of the wall that will be connected to
- this model, and y is the length of the adjacent wall.
- The wind direction is computed relative to the azimuth of this surface,
- which is equal to the parameter azi.
- The surface azimuth is defined in
-
- AixLib.Types.Azimuth.
- For example, if an exterior wall is South oriented, i.e., its outside-facing
- surface is towards South, use
- AixLib.Types.Azimuth.S.
-
-
- Based on the surface azimuth, the wind direction and the side ratio
- of the walls, the model computes how much the wind pressure
- is attenuated compared to the reference wind pressure Cp0.
- The reference wind pressure Cp0 is a user-defined parameter,
- and must be equal to the wind pressure at zero wind incidence angle.
- Swami and Chandra (1987) recommend Cp0 = 0.6 for
- all low-rise buildings as this represents the average of
- various values reported in the literature.
- The computation of the actual wind pressure coefficient Cp
- is explained in the function
-
- Buildings.Airflow.Multizone.BaseClasses.windPressureLowRise
- that is called by this model.
-
-
- The pressure p at the port ports is computed as
-
-
- p = pw + Cp 1 ⁄ 2 v2 ρ,
-
-
- where
- pw is the atmospheric pressure from the weather bus,
- v is the wind speed from the weather bus, and
- ρ is the fluid density.
-
-
-
- This model differs from
- AixLib.Fluid.Sources.Outside_CpData by the calculation of the wind pressure coefficient Cp,act.
- The wind pressure coefficient is defined by an equation in stead of a user-defined table.
- This model is only suited for low-rise rectangular buildings.
-
-
- References
-
-
-
- -
- February 2, 2022, by Michael Wetter:
- Revised implementation.
- This is for
- IBPSA, #1436.
-
- -
- Jun 28, 2021, by Klaas De Jonge:
- Documentation changes to explain the difference with
- AixLib.Fluid.Sources.Outside_CpData.
-
- -
- January 26, 2016, by Michael Wetter:
- Added unit and quantity attributes.
-
- -
- October 26, 2011 by Michael Wetter:
- First implementation.
-
-
-
--------- Corrected Code --------
- This model describes boundary conditions for pressure, enthalpy, and
- species concentration that can be obtained from weather data. The
- model is identical to AixLib.Fluid.Sources.Outside,
- except that it adds the wind pressure to the pressure at the fluid
- port ports. The correlation that is used to compute the
- wind pressure is based on Swami and Chandra (1987) and valid for
- low-rise buildings with rectangular shape. The same correlation is
- also implemented in CONTAM (Persily and Ivy, 2001).
-
+This package contains borefield models. These models can simulate any arbitrary
+configuration of vertical boreholes with equal lengths with both short and
+long-term accuracy with an aggregation method to speed up the calculations of the ground heat transfer. Examples
+of how to use the borefield models and validation cases can be found in
+
+AixLib.Fluid.Geothermal.Borefields.Examples
+and
+
+AixLib.Fluid.Geothermal.Borefields.Validation,
+respectively.
- The wind pressure coefficient is computed based on the side ratio of
- the walls, which is defined as
-
-
- s = x ⁄ y
-
+The major features and configurations currently supported are:
+
+- User-defined borefield characteristics and geometry (borehole radius, pipe radius, shank spacing, etc.),
+including single U-tube, double U-tube in parallel and double U-tube in series configurations.
+
+- The resistances Rb and Ra are
+either automatically calculated using the multipole method,
+or the resistance Rb can be directly provided by the user.
+In this case, the resistances Rb and Ra are
+still evaluated internally, but their values are weighted so that the borehole
+resistance matches the specified value.
+
+-
+User-defined vertical discretization of boreholes are supported.
+However, the borehole wall temperature
+is identical for each borehole, as the ground temperature response model only computes the average borehole wall temperature
+for all boreholes combined.
+
+-
+Borefields can consist of one or many boreholes. Each borehole can be positioned
+at an arbitrary position in the field using cartesian coordinates.
+
+-
+The resolution and precision of the load aggregation method for the ground heat transfer can be adapted.
+
+-
+The thermal response of the ground heat transfer is stored locally to avoid
+having to recalculate it for future simulations with the same borefield configuration.
+
+-
+Pressure losses are calculated if the
dp_nominal parameter is set to a non-zero value.
+
+
+
- where x is the length of the wall that will be connected to
- this model, and y is the length of the adjacent wall. The wind
- direction is computed relative to the azimuth of this surface, which
- is equal to the parameter azi. The surface azimuth is
- defined in AixLib.Types.Azimuth. For
- example, if an exterior wall is South oriented, i.e., its
- outside-facing surface is towards South, use
- AixLib.Types.Azimuth.S.
+The model is limited to the simulation of borefields with boreholes connected in
+parallel, as shown on the figure below for a single U-tube configuration. All
+boreholes have the same length hBor, the same radius
+rBor, and are buried at the same depth dBor below the
+ground surface (also known as the inactive borehole length).
+
+
+
+
+How to use the borefield models
+Borefield data record
- Based on the surface azimuth, the wind direction and the side ratio
- of the walls, the model computes how much the wind pressure is
- attenuated compared to the reference wind pressure Cp0.
- The reference wind pressure Cp0 is a user-defined
- parameter, and must be equal to the wind pressure at zero wind
- incidence angle. Swami and Chandra (1987) recommend Cp0
- = 0.6 for all low-rise buildings as this represents the average
- of various values reported in the literature. The computation of the
- actual wind pressure coefficient Cp is explained in
- the function
- Buildings.Airflow.Multizone.BaseClasses.windPressureLowRise that
- is called by this model.
+Most of the parameter values of the model are contained in the record called borFieDat.
+This record is composed of three subrecords:
+filDat (containing the thermal characteristics of the borehole filling material),
+soiDat (containing the thermal characteristics of the surrounding soil),
+and conDat (containing all others parameters, namely parameters
+defining the configuration of the borefield).
+The structure and default values of the record are in the package:
+AixLib.Fluid.Geothermal.Borefields.Data.
+The borFieDat record
+can be found in the
+AixLib.Fluid.Geothermal.Borefields.Data.Borefield subpackage therein.
+Examples of the subrecords conDat, filDat and soiDat
+can be found in
+
+AixLib.Fluid.Geothermal.Borefields.Data.Configuration,
+
+AixLib.Fluid.Geothermal.Borefields.Data.Filling and
+
+AixLib.Fluid.Geothermal.Borefields.Data.Soil, respectively.
- The pressure p at the port ports is computed as
+It is important to make sure that the borCon parameter within
+the conDat subrecord is compatible with the chosen borefield model.
+For example, if a double U-tube
+borefield model is chosen, the borCon parameter could be set
+to both a parallel double U-tube configuration and a double U-tube configuration in series,
+but could not be set to a single U-tube configuration. An incompatible borehole
+configuration will stop the simulation.
-
- p = pw + Cp 1 ⁄ 2 v2 ρ,
+ Ground heat transfer parameters
+
+Other than the parameters contained in the borFieDat record,
+the borefield models have other parameters which can be modified by the user.
+The tLoaAgg parameter is the time resolution of the load aggregation
+for the calculation of the ground heat transfer. It represents the
+frequency at which the load aggregation procedure is performed in the simulation.
+Therefore, smaller values of tLoaAgg will improve
+the accuracy of the model, at the cost of increased simulation times
+due to a higher number of events occuring in the simulation. While a default value
+is provided for this parameter, it is advisable to ensure that it is lower
+than a fraction (e.g. half) of the time required for the fluid to completely circulate
+through the borefield,
+as increasing the value of tLoaAgg beyond this
+will result in non-physical borehole wall temperatures.
- where pw is the atmospheric pressure from the
- weather bus, v is the wind speed from the weather bus, and
- ρ is the fluid density.
+The nCel parameter also affects the accuracy and simulation time
+of the ground heat transfer calculations. As this parameter sets the number
+of consecutive equal-size aggregation cells before increasing the size of cells,
+increasing its value will result in less load aggregation, which will increase
+accuracy at the cost of computation time. On the other hand,
+decreasing the value of nCel (down to a minimum of 1)
+will decrease accuracy but improve
+computation time. The default value is chosen as a compromise between the two.
- This model differs from AixLib.Fluid.Sources.Outside_CpData
- by the calculation of the wind pressure coefficient
- Cp,act. The wind pressure coefficient is defined by an
- equation in stead of a user-defined table. This model is only suited
- for low-rise rectangular buildings.
+Further information on the tLoaAgg and nCel parameters can
+be found in the documentation of
+
+AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.GroundTemperatureResponse.
-
- References
-
+Other parameters
+
+Other parameters which can be modified include the dynamics, initial conditions,
+and further information regarding the fluid flow, for example whether the flow is reversible.
+It is worth noting that regardless of the energyDynamics chosen,
+the dynFil parameter can be set to false
+to remove the effect of the thermal capacitance
+of the filling material in the borehole(s).
+The nSeg parameter specifies the number of segments for the vertical discretization of the borehole(s).
+Further information on this discretization can be found in the "Model description" section below.
+
+Running simulations
+
+When running simulations using the borefield models,
+the tmp/temperatureResponseMatrix directory within the current directory
+will be checked to see if any of the
+borefield configurations used in the simulation have already
+had their ground temperature response calculated previously
+If the data doesn't exist in the tmp/temperatureResponseMatrix folder,
+it will be calculated during the initialization of the model
+and will be saved there for future use.
+
+Model description
+
+The borefield models rely on the following key assumptions:
- - Muthusamy V. Swami and Subrato Chandra. Procedures
- for Calculating Natural Ventilation Airflow Rates in
- Buildings. Florida Solar Energy Center, FSEC-CR-163-86.
- March, 1987. Cape Canaveral, Florida.
-
- - Andrew K. Persily and Elizabeth M. Ivy. Input
- Data for Multizone Airflow and IAQ Analysis. NIST, NISTIR
- 6585. January, 2001. Gaithersburg, MD.
-
+- The thermal properties of the soil (conductivity and diffusivity) are constant,
+homogenous and isotropic.
+
+-
+The conductivity, capacitance and density of the grout and pipe material are constant, homogenous and isotropic.
+
+-
+There is no heat extraction or injection prior to the simulation start.
+
+-
+All of the boreholes in the borefield have uniform dimensions (including the pipe dimensions).
+
+-
+Inside the boreholes, the non-advective heat transfer is only in the radial direction.
+
+
+The borefield models are constructed in two main parts: the borehole(s) and the ground heat transfer.
+The former is modeled as a vertical discretization of borehole segments, where a uniform temperature increase or decrease
+(due to heat injection or extraction) is superimposed to the far-field ground temperature to obtain the borehole wall
+temperature. The thermal effects of the circulating fluid (including the convection resistance),
+of the pipes and of the filling material are all taken into consideration, which allows modeling
+short-term thermal effects in the borehole. The borehole segments do not take into account axial effects,
+thus only radial (horizontal) effects are considered within the borehole(s). The thermal
+behavior between the pipes and borehole wall are modeled as a resistance-capacitance network, with
+the grout capacitance being split in the number of pipes present in a borehole section.
+The capacitance is only present if the dynFil parameter is set to true.
+The figure below shows an example for a borehole section within a single U-tube configuration.
+
+
+
+
+
+The second main part of the borefield models is the ground heat transfer, which shares a thermal boundary
+condition at the uniform borehole wall with all of the borehole segments. The heat transfer in the ground
+is modeled analytically as a convolution integral between the heat flux at the borehole wall
+and the borefield's thermal response factor.
+
+
+
+
+
+The model uses a load aggregation technique to reduce the time required to calculate
+the borehole wall temperature changes resulting from heat injection or extraction.
+
+
+The ground heat transfer takes into account both the borehole axial effects and
+the borehole radial effects which are a result of its cylindrical geometry. The borefield's
+thermal response to a constant load, also known as its g-function, is used
+to calculate the thermal response in the simulation. This g-function
+is stored in the tmp/temperatureResponseMatrix subdirectory,
+as discussed previously in the
+"How to use the borefield models" section. Further information on the
+ground heat transfer model and the thermal temperature response calculations can
+be found in
+
+AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.GroundTemperatureResponse
+and
+
+AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.gFunction.
+
+References
+
+D. Picard, L. Helsen.
+Advanced Hybrid Model for Borefield Heat
+Exchanger Performance Evaluation; an Implementation in Modelica
+Proc. of the 10th Intertional ModelicaConference, p. 857-866. Lund, Sweden. March 2014.
+https://lirias.kuleuven.be/retrieve/270880.
+
+
+-------- Corrected Code --------
+
+ This package contains borefield models. These models can simulate any
+ arbitrary configuration of vertical boreholes with equal lengths with
+ both short and long-term accuracy with an aggregation method to speed
+ up the calculations of the ground heat transfer. Examples of how to
+ use the borefield models and validation cases can be found in
+ AixLib.Fluid.Geothermal.Borefields.Examples
+ and AixLib.Fluid.Geothermal.Borefields.Validation,
+ respectively.
+
+
+ The major features and configurations currently supported are:
+
- - February 2, 2022, by Michael Wetter:
- Revised implementation.
- This is for IBPSA,
- #1436.
+ - User-defined borefield characteristics and geometry (borehole
+ radius, pipe radius, shank spacing, etc.), including single U-tube,
+ double U-tube in parallel and double U-tube in series configurations.
- - Jun 28, 2021, by Klaas De Jonge:
- Documentation changes to explain the difference with AixLib.Fluid.Sources.Outside_CpData.
+ - The resistances Rb and Ra are
+ either automatically calculated using the multipole method, or the
+ resistance Rb can be directly provided by the user.
+ In this case, the resistances Rb and
+ Ra are still evaluated internally, but their values
+ are weighted so that the borehole resistance matches the specified
+ value.
- - January 26, 2016, by Michael Wetter:
- Added unit and quantity attributes.
+ - User-defined vertical discretization of boreholes are supported.
+ However, the borehole wall temperature is identical for each
+ borehole, as the ground temperature response model only computes the
+ average borehole wall temperature for all boreholes combined.
- - October 26, 2011 by Michael Wetter:
- First implementation.
+ - Borefields can consist of one or many boreholes. Each borehole
+ can be positioned at an arbitrary position in the field using
+ cartesian coordinates.
-
-
--------- Errors --------
-line 28 column 2 - Warning: attribute "align" not allowed for HTML5
-line 61 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/FMI/Adaptors/HVAC.mo ----
--------- HTML Code --------
-
-
- The (time varying) vector Real output signal of this block can be defined in its
- parameter menu via variable y. The purpose is to support the
- easy definition of vector-valued Real expressions in a block diagram.
-
-
-
- Adaptor that can be used to connect an HVAC system (with acausal ports)
- to input/output signals, which then can be exposed in an FMI interface.
-
-
- The adaptor has a vector of fluid ports called ports.
- The supply and return air ducts need to be connected to these ports.
- Also, if a thermal zone has interzonal air exchange or air infiltration,
- these flow paths also need be connected to ports.
-
-
- This model outputs at the port fluPor the mass flow rate for
- each flow that is connected to ports, together with its
- temperature, water vapor mass fraction per total mass of the air (not per kg dry
- air), and trace substances. These quantities are always as if the flow
- enters the room, even if the flow is zero or negative.
- If a medium has no moisture, e.g., if Medium.nXi=0, or
- if it has no trace substances, e.g., if Medium.nC=0, then
- the output signal for these properties are removed.
- These quantities are always as if the flow
- enters the room, even if the flow is zero or negative.
- Thus, a thermal zone model that uses these signals to compute the
- heat added by the HVAC system need to implement an equation such as
-
-
- Qsen = max(0, ṁsup) cp (Tsup - Tair,zon),
-
-
- where
- Qsen is the sensible heat flow rate added to the thermal zone,
- ṁsup is the supply air mass flow rate from
- the port fluPor (which is negative if it is an exhaust),
- cp is the specific heat capacity at constant pressure,
- Tsup is the supply air temperature and
- Tair,zon is the zone air temperature.
- Note that without the max(·, ·) function, the energy
- balance would be wrong.
-
-
- The output signals of this model are the zone air temperature,
- the water vapor mass fraction per total mass of the air (unless Medium.nXi=0)
- and trace substances (unless Medium.nC=0).
- These output connectors can be used to connect to a controller.
- These values are obtained from the fluid stream(s) that flow into this component
- at the port fluPor, e.g., from the connector
- fluPor.backward.
- Note that there are nPorts of these signals.
- For a completely mixed room, they will all have the same value, but
- for a room with non-uniform temperatures, they can have different values.
-
- Assumption and limitations
-
- The mass flow rates at ports sum to zero, hence this
- model conserves mass.
-
-
- This model does not impose any pressure, other than setting the pressure
- of all fluid connections to ports to be equal.
- The reason is that setting a pressure can lead to non-physical system models,
- for example if a mass flow rate is imposed and the HVAC system is connected
- to a model that sets a pressure boundary condition such as
-
- AixLib.Fluid.Sources.Outside.
- Also, setting a pressure would make it impossible to use multiple instances
- of this model (one for each thermal zone) and build in Modelica an airflow network
- model with pressure driven mass flow rates.
-
-
- The model has no pressure drop. Hence, the pressure drop
- of an air diffuser or of an exhaust grill need to be modelled
- in models that are connected to ports.
-
- Typical use and important parameters
-
- See
-
- AixLib.Fluid.FMI.ExportContainers.HVACZone
- for a model that uses this model.
-
-
-
- -
- January 18, 2019, by Jianjun Hu:
- Limited the media choice to moist air only.
- See #1050.
-
- -
- September 13, 2017, by Michael Wetter:
- Removed erroneous each.
-
- -
- October 4, 2016, by Michael Wetter:
- Corrected assignment of quantity in CZon.
-
- -
- June 29, 2016, by Michael Wetter:
- Revised implementation.
-
- -
- April 14, 2016, by Michael Wetter:
- First implementation.
-
-
-
--------- Corrected Code --------
+ - The resolution and precision of the load aggregation method for
+ the ground heat transfer can be adapted.
+
+ - The thermal response of the ground heat transfer is stored
+ locally to avoid having to recalculate it for future simulations with
+ the same borefield configuration.
+
+ - Pressure losses are calculated if the
dp_nominal
+ parameter is set to a non-zero value.
+
+
- The (time varying) vector Real output signal of this
- block can be defined in its parameter menu via variable
- y. The purpose is to support the easy definition of
- vector-valued Real expressions in a block diagram.
+ The model is limited to the simulation of borefields with boreholes
+ connected in parallel, as shown on the figure below for a single
+ U-tube configuration. All boreholes have the same length
+ hBor, the same radius rBor, and are buried
+ at the same depth dBor below the ground surface (also
+ known as the inactive borehole length).
-
- Adaptor that can be used to connect an HVAC system (with acausal
- ports) to input/output signals, which then can be exposed in an FMI
- interface.
+
+
+
+ How to use the borefield models
+
+
+ Borefield data record
+
- The adaptor has a vector of fluid ports called ports.
- The supply and return air ducts need to be connected to these ports.
- Also, if a thermal zone has interzonal air exchange or air
- infiltration, these flow paths also need be connected to
- ports.
+ Most of the parameter values of the model are contained in the record
+ called borFieDat. This record is composed of three
+ subrecords: filDat (containing the thermal
+ characteristics of the borehole filling material),
+ soiDat (containing the thermal characteristics of the
+ surrounding soil), and conDat (containing all others
+ parameters, namely parameters defining the configuration of the
+ borefield). The structure and default values of the record are in the
+ package: AixLib.Fluid.Geothermal.Borefields.Data.
+ The borFieDat record can be found in the AixLib.Fluid.Geothermal.Borefields.Data.Borefield
+ subpackage therein. Examples of the subrecords conDat,
+ filDat and soiDat can be found in AixLib.Fluid.Geothermal.Borefields.Data.Configuration,
+ AixLib.Fluid.Geothermal.Borefields.Data.Filling
+ and AixLib.Fluid.Geothermal.Borefields.Data.Soil,
+ respectively.
- This model outputs at the port fluPor the mass flow rate
- for each flow that is connected to ports, together with
- its temperature, water vapor mass fraction per total mass of the air
- (not per kg dry air), and trace substances. These quantities are
- always as if the flow enters the room, even if the flow is zero or
- negative. If a medium has no moisture, e.g., if
- Medium.nXi=0, or if it has no trace substances, e.g., if
- Medium.nC=0, then the output signal for these properties
- are removed. These quantities are always as if the flow enters the
- room, even if the flow is zero or negative. Thus, a thermal zone
- model that uses these signals to compute the heat added by the HVAC
- system need to implement an equation such as
-
-
- Qsen = max(0, ṁsup) cp
- (Tsup - Tair,zon),
+ It is important to make sure that the borCon parameter
+ within the conDat subrecord is compatible with the
+ chosen borefield model. For example, if a double U-tube borefield
+ model is chosen, the borCon parameter could be set to
+ both a parallel double U-tube configuration and a double U-tube
+ configuration in series, but could not be set to a single U-tube
+ configuration. An incompatible borehole configuration will stop the
+ simulation.
+
+ Ground heat transfer parameters
+
- where Qsen is the sensible heat flow rate added to
- the thermal zone, ṁsup is the supply air mass flow
- rate from the port fluPor (which is negative if it is an
- exhaust), cp is the specific heat capacity at
- constant pressure, Tsup is the supply air
- temperature and Tair,zon is the zone air
- temperature. Note that without the max(·, ·) function, the
- energy balance would be wrong.
+ Other than the parameters contained in the borFieDat
+ record, the borefield models have other parameters which can be
+ modified by the user. The tLoaAgg parameter is the time
+ resolution of the load aggregation for the calculation of the ground
+ heat transfer. It represents the frequency at which the load
+ aggregation procedure is performed in the simulation. Therefore,
+ smaller values of tLoaAgg will improve the accuracy of
+ the model, at the cost of increased simulation times due to a higher
+ number of events occuring in the simulation. While a default value is
+ provided for this parameter, it is advisable to ensure that it is
+ lower than a fraction (e.g. half) of the time required for the fluid
+ to completely circulate through the borefield, as increasing the
+ value of tLoaAgg beyond this will result in non-physical
+ borehole wall temperatures.
- The output signals of this model are the zone air temperature, the
- water vapor mass fraction per total mass of the air (unless
- Medium.nXi=0) and trace substances (unless
- Medium.nC=0). These output connectors can be used to
- connect to a controller. These values are obtained from the fluid
- stream(s) that flow into this component at the port
- fluPor, e.g., from the connector
- fluPor.backward. Note that there are nPorts
- of these signals. For a completely mixed room, they will all have the
- same value, but for a room with non-uniform temperatures, they can
- have different values.
+ The nCel parameter also affects the accuracy and
+ simulation time of the ground heat transfer calculations. As this
+ parameter sets the number of consecutive equal-size aggregation cells
+ before increasing the size of cells, increasing its value will result
+ in less load aggregation, which will increase accuracy at the cost of
+ computation time. On the other hand, decreasing the value of
+ nCel (down to a minimum of 1) will decrease accuracy but
+ improve computation time. The default value is chosen as a compromise
+ between the two.
-
- Assumption and limitations
-
- The mass flow rates at ports sum to zero, hence this
- model conserves mass.
+ Further information on the tLoaAgg and nCel
+ parameters can be found in the documentation of
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.GroundTemperatureResponse.
+
+ Other parameters
+
- This model does not impose any pressure, other than setting the
- pressure of all fluid connections to ports to be equal.
- The reason is that setting a pressure can lead to non-physical system
- models, for example if a mass flow rate is imposed and the HVAC
- system is connected to a model that sets a pressure boundary
- condition such as AixLib.Fluid.Sources.Outside.
- Also, setting a pressure would make it impossible to use multiple
- instances of this model (one for each thermal zone) and build in
- Modelica an airflow network model with pressure driven mass flow
- rates.
+ Other parameters which can be modified include the dynamics, initial
+ conditions, and further information regarding the fluid flow, for
+ example whether the flow is reversible. It is worth noting that
+ regardless of the energyDynamics chosen, the
+ dynFil parameter can be set to false to
+ remove the effect of the thermal capacitance of the filling material
+ in the borehole(s). The nSeg parameter specifies the
+ number of segments for the vertical discretization of the
+ borehole(s). Further information on this discretization can be found
+ in the \"Model description\" section below.
+
+ Running simulations
+
- The model has no pressure drop. Hence, the pressure drop of an air
- diffuser or of an exhaust grill need to be modelled in models that
- are connected to ports.
+ When running simulations using the borefield models, the
+ tmp/temperatureResponseMatrix directory within the
+ current directory will be checked to see if any of the borefield
+ configurations used in the simulation have already had their ground
+ temperature response calculated previously If the data doesn't exist
+ in the tmp/temperatureResponseMatrix folder, it will be
+ calculated during the initialization of the model and will be saved
+ there for future use.
- Typical use and important parameters
+ Model description
- See AixLib.Fluid.FMI.ExportContainers.HVACZone
- for a model that uses this model.
+ The borefield models rely on the following key assumptions:
- - January 18, 2019, by Jianjun Hu:
- Limited the media choice to moist air only. See #1050.
+ - The thermal properties of the soil (conductivity and diffusivity)
+ are constant, homogenous and isotropic.
- - September 13, 2017, by Michael Wetter:
- Removed erroneous each.
+ - The conductivity, capacitance and density of the grout and pipe
+ material are constant, homogenous and isotropic.
- - October 4, 2016, by Michael Wetter:
- Corrected assignment of quantity in CZon.
+ - There is no heat extraction or injection prior to the simulation
+ start.
- - June 29, 2016, by Michael Wetter:
- Revised implementation.
+ - All of the boreholes in the borefield have uniform dimensions
+ (including the pipe dimensions).
- - April 14, 2016, by Michael Wetter:
- First implementation.
+ - Inside the boreholes, the non-advective heat transfer is only in
+ the radial direction.
-
--------- Errors --------
-line 26 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/HeatExchangers/ActiveBeams/BaseClasses/Convector.mo ----
--------- HTML Code --------
-
-
- In cooling mode, this model adds heat to the water stream. The heat added is equal to:
-
-
- QBeam = Qrated fΔT fSA fW
-
-
- In heating mode, the heat is removed from the water stream.
-
-
-
- -
- March 3, 2022, by Michael Wetter:
- Removed massDynamics.
- This is for
- issue 1542.
-
- -
- April 14, 2020, by Michael Wetter:
- Changed homotopyInitialization to a constant.
- This is for
- IBPSA, #1341.
-
- -
- November 2, 2016, by Michael Wetter:
- Made assignment of senTem.y final.
-
- -
- June 13, 2016, by Michael Wetter:
- Revised implementation.
-
- -
- May 20, 2016, by Alessandro Maccarini:
- First implementation.
-
-
-
--------- Corrected Code --------
- In cooling mode, this model adds heat to the water stream. The heat
- added is equal to:
+ The borefield models are constructed in two main parts: the
+ borehole(s) and the ground heat transfer. The former is modeled as a
+ vertical discretization of borehole segments, where a uniform
+ temperature increase or decrease (due to heat injection or
+ extraction) is superimposed to the far-field ground temperature to
+ obtain the borehole wall temperature. The thermal effects of the
+ circulating fluid (including the convection resistance), of the pipes
+ and of the filling material are all taken into consideration, which
+ allows modeling short-term thermal effects in the borehole. The
+ borehole segments do not take into account axial effects, thus only
+ radial (horizontal) effects are considered within the borehole(s).
+ The thermal behavior between the pipes and borehole wall are modeled
+ as a resistance-capacitance network, with the grout capacitance being
+ split in the number of pipes present in a borehole section. The
+ capacitance is only present if the dynFil parameter is
+ set to true. The figure below shows an example for a
+ borehole section within a single U-tube configuration.
-
- QBeam = Qrated fΔT
- fSA fW
+
+
- In heating mode, the heat is removed from the water stream.
+ The second main part of the borefield models is the ground heat
+ transfer, which shares a thermal boundary condition at the uniform
+ borehole wall with all of the borehole segments. The heat transfer in
+ the ground is modeled analytically as a convolution integral between
+ the heat flux at the borehole wall and the borefield's thermal
+ response factor.
+
+
+
+
+
+ The model uses a load aggregation technique to reduce the time
+ required to calculate the borehole wall temperature changes resulting
+ from heat injection or extraction.
+
+
+ The ground heat transfer takes into account both the borehole axial
+ effects and the borehole radial effects which are a result of its
+ cylindrical geometry. The borefield's thermal response to a constant
+ load, also known as its g-function, is used to calculate the
+ thermal response in the simulation. This g-function is stored in the
+ tmp/temperatureResponseMatrix subdirectory, as discussed
+ previously in the \"How to use the borefield models\" section. Further
+ information on the ground heat transfer model and the thermal
+ temperature response calculations can be found in
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.GroundTemperatureResponse
+ and
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.gFunction.
+
+
+ References
+
+
+ D. Picard, L. Helsen. Advanced Hybrid Model for Borefield Heat
+ Exchanger Performance Evaluation; an Implementation in Modelica
+ Proc. of the 10th Intertional ModelicaConference, p. 857-866. Lund,
+ Sweden. March 2014. https://lirias.kuleuven.be/retrieve/270880.
-
- - March 3, 2022, by Michael Wetter:
- Removed massDynamics.
- This is for issue
- 1542.
-
- - April 14, 2020, by Michael Wetter:
- Changed homotopyInitialization to a constant.
- This is for IBPSA,
- #1341.
-
- - November 2, 2016, by Michael Wetter:
- Made assignment of senTem.y final.
-
- - June 13, 2016, by Michael Wetter:
- Revised implementation.
-
- - May 20, 2016, by Alessandro Maccarini:
- First implementation.
-
-
-------- Errors --------
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+line 56 column 1 - Warning: attribute "align" not allowed for HTML5
+line 179 column 1 - Warning: attribute "align" not allowed for HTML5
+line 188 column 1 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Utilities/Math/Functions/bicubic.mo ----
+---- AixLib/Fluid/HeatExchangers/BaseClasses/WetCoilWetRegime.mo ----
-------- HTML Code --------
- This function computes
-
- y = a1
- + a2 x1 + a3 x12
- + a4 x2 + a5 x22
- + a6 x1 x2
- + a7 x1^3
- + a8 x2^3
- + a9 x12 x2
- + a10 x1 x22
-
-
-
- Sep 17, 2010 by Michael Wetter:
- First implementation.
+ Jan 21, 2021, by Donghun Kim:
First implementation.
--------- Corrected Code --------
-This function computes
-
- y = a1 + a2 x1 + a3
- x12 + a4 x2 +
- a5 x22 + a6 x1
- x2 + a7 x1^3 + a8
- x2^3 + a9 x12
- x2 + a10 x1
- x22
-
-
- - Sep 17, 2010 by Michael Wetter:
- First implementation.
-
-
-
--------- Errors --------
-line 3 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/Actuators/Valves/TwoWayTable.mo ----
--------- HTML Code --------
-
- Two way valve with opening characteristic that is configured through
- a table.
+ This model implements the calculation for a 100% wet coil.
- The mass flow rate for the fully open valve is determined based
- on the value of the parameter CvData.
- For the different valve positions y ∈ [0, 1], this nominal flow rate is
- scaled by the values of the parameter
- flowCharacteristics.
- The parameter flowCharacteristics declares a table of the form
+ The equations from Braun (1988) and Mitchell and Braun (2012a and b),
+ which are essentially the extension of the ε-NTU approach to
+ simultaneous sensible and latent heat transfer, are utilized.
-
-
- | y | 0 | ... | 1 |
-
-
- | φ | l | ... | 1 |
-
-
- where l = Kv(y=0)/Kv(y=1) > 0 is the valve leakage.
- The first row is the valve opening, and the second row is the
- mass flow rate, relative to the mass flow rate of the fully open
- valve, under the assumption of a constant pressure difference across the
- valve.
- A suggested value for the valve leakage is l=0.0001.
- If l = 0, then this model will replace it with
- l = 10-8 for numerical reasons.
- For example, if a valve has Kv=0.5 [m3/h/bar1/2] and
- a linear opening characteristics and
- a valve leakage of l=0.0001, then one would set
+ The mathematical equations are analogous to that of the sensible heat exchanger.
+ However, the key distinction is that the heat transfer is driven by an enthalpy difference
+ not by an temperature difference. This change in the driving potential results in re-defining
+ capacitances and heat transfer coefficients accordingly.
-
- CvData=AixLib.Fluid.Types.CvTypes.Kv
- Kv = 0.5
- flowCharacteristics(y={0,1}, phi={0.0001,1})
-
+
- Note, however, that
-
- AixLib.Fluid.Actuators.Valves.TwoWayLinear provides a more
- efficient implementation for this simple case.
+ The total heat transfer rate is expressed as
+
+
+ Qtot=ε* C*min
+ (hair,in-hsat(Twat,in)),
- The parameter flowCharacteristics must meet the following
- requirements, otherwise the model stops with an error:
+ where ε*=f(Cr*,NTU*) and f is the same ε-NTU relationships
+ (depending on the heat exchanger configuration) for the sensible heat exchanger.
-
- -
- Their arrays
-
y and phi
- must be strictly monotonic increasing.
-
- -
- The first value must satisfy
-
y[1]=0, and
- phi[1] must be equal to the
- leakage flow rate, which must be bigger than zero.
- Otherwise, a default value of 1E-8 is used.
-
- -
- The last values must satisfy
-
y[end]=1 and
- phi[end]=1.
-
-
- This model is based on the partial valve model
-
- AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve.
- Check this model for more information, such
- as the regularization near the origin.
+ hair,in and hsat(Twat,in) are
+ the specific enthalpies of the incoming moist air and saturated moist air
+ at the water inlet temperature.
- For an example that specifies an opening characteristics, see
-
- AixLib.Fluid.Actuators.Valves.Examples.TwoWayValveTable.
+ The capacitances of water and air streams are defined as
+
+ C*air=mair and
+ C*wat=mwatcp,wat/csat,
+
+
+ where csat is an specific heat capacity, which indicates the sensitivity
+ of the enthalpy of the staturated moist air w.r.t. the temperature, and is defined
+ here as csat=(hsat(Twat,out)-hsat(Twat,in))
+ /(Twat,out-Twat,in).
+
+
+ The capacitance ratio and minimum capacitance are naturally defined as
+
+ Cr*=min(C*air,C*wat)/max(C*air,C*wat)
+ and C*min=min(C*air,C*wat).
+
+
+ The number of transfer unit for the wet-coil is defined as NTU*=UA*/C*min, where
+
+
+ UA*=1/(1/(UAair/cp,air)+1/(UAwat/csat).
-
- -
- June 10, 2021, by Michael Wetter:
- Changed implementation of the filter and changed the parameter order to a constant
- as most users need not change this value.
- This is for
- #1498.
-
- -
- August 7, 2020, by Ettore Zanetti:
- changed the computation of phi using
- max(0.1*l, . ) to avoid
- phi=0.
- See
- issue 1376.
-
- -
- November 9, 2019, by Filip Jorissen:
- Guarded the computation of phi using
- max(0, . ) to avoid
- negative phi.
- See
- issue 1223.
-
- -
- January 26, 2016, by Michael Wetter:
- Removed equality comparison for Real in the
- assert statements as this is not allowed in Modelica.
-
- -
- August 12, 2014, by Michael Wetter:
- Removed the end keyword when accessing array elements,
- as this language construct caused an error in OpenModelica.
-
- -
- April 4, 2014, by Michael Wetter:
- Moved the assignment of the flow function phi
- to the model instantiation because in its base class,
- the keyword input
- has been added to the variable phi.
-
- -
- March 26, 2014 by Michael Wetter:
- First implementation.
-
-
+ References
+
+ Braun, James E. 1988.
+ "Methodologies for the Design and Control of Central Cooling Plants".
+ PhD Thesis. University of Wisconsin - Madison.
+ Available
+
+ online.
+
+
+ Mitchell, John W., and James E. Braun. 2012a.
+ Principles of heating, ventilation, and air conditioning in buildings.
+ Hoboken, N.J.: Wiley.
+
+
+ Mitchell, John W., and James E. Braun. 2012b.
+ "Supplementary Material Chapter 2: Heat Exchangers for Cooling Applications".
+ Excerpt from Principles of heating, ventilation, and air conditioning in buildings.
+ Hoboken, N.J.: Wiley.
+ Available
+
+ online.
+
-------- Corrected Code --------
+
+ - Jan 21, 2021, by Donghun Kim:
+ First implementation.
+
+
- Two way valve with opening characteristic that is configured through
- a table.
+ This model implements the calculation for a 100% wet coil.
- The mass flow rate for the fully open valve is determined based on
- the value of the parameter CvData. For the different
- valve positions y ∈ [0, 1], this nominal flow rate is scaled
- by the values of the parameter flowCharacteristics. The
- parameter flowCharacteristics declares a table of the
- form
+ The equations from Braun (1988) and Mitchell and Braun (2012a and b),
+ which are essentially the extension of the ε-NTU approach to
+ simultaneous sensible and latent heat transfer, are utilized.
-
-
- |
- y
- |
-
- 0
- |
-
- ...
- |
-
- 1
- |
-
-
- |
- φ
- |
-
- l
- |
-
- ...
- |
-
- 1
- |
-
-
- where l = Kv(y=0)/Kv(y=1) > 0 is the
- valve leakage. The first row is the valve opening, and the second row
- is the mass flow rate, relative to the mass flow rate of the fully
- open valve, under the assumption of a constant pressure difference
- across the valve. A suggested value for the valve leakage is
- l=0.0001. If l = 0, then this model will replace it
- with l = 10-8 for numerical reasons. For example,
- if a valve has Kv=0.5
- [m3/h/bar1/2] and a linear opening
- characteristics and a valve leakage of l=0.0001, then one
- would set
+ The mathematical equations are analogous to that of the sensible heat
+ exchanger. However, the key distinction is that the heat transfer is
+ driven by an enthalpy difference not by an temperature difference.
+ This change in the driving potential results in re-defining
+ capacitances and heat transfer coefficients accordingly.
-
- CvData=AixLib.Fluid.Types.CvTypes.Kv
- Kv = 0.5
- flowCharacteristics(y={0,1}, phi={0.0001,1})
-
- Note, however, that AixLib.Fluid.Actuators.Valves.TwoWayLinear
- provides a more efficient implementation for this simple case.
+ The total heat transfer rate is expressed as
+
+
+ Qtot=ε* C*min
+ (hair,in-hsat(Twat,in)),
- The parameter flowCharacteristics must meet the
- following requirements, otherwise the model stops with an error:
+ where ε*=f(Cr*,NTU*) and f is the same ε-NTU
+ relationships (depending on the heat exchanger configuration) for the
+ sensible heat exchanger.
-
- - Their arrays
y and phi must be strictly
- monotonic increasing.
-
- - The first value must satisfy
y[1]=0, and
- phi[1] must be equal to the leakage flow rate, which
- must be bigger than zero. Otherwise, a default value of
- 1E-8 is used.
-
- - The last values must satisfy
y[end]=1 and
- phi[end]=1.
-
-
- This model is based on the partial valve model AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve.
- Check this model for more information, such as the regularization
- near the origin.
+ hair,in and
+ hsat(Twat,in) are the specific
+ enthalpies of the incoming moist air and saturated moist air at the
+ water inlet temperature.
- For an example that specifies an opening characteristics, see
-
- AixLib.Fluid.Actuators.Valves.Examples.TwoWayValveTable.
+ The capacitances of water and air streams are defined as
+
+
+ C*air=mair and
+ C*wat=mwatcp,wat/csat,
+
+
+ where csat is an specific heat capacity, which indicates the
+ sensitivity of the enthalpy of the staturated moist air w.r.t. the
+ temperature, and is defined here as
+ csat=(hsat(Twat,out)-hsat(Twat,in))
+ /(Twat,out-Twat,in).
+
+
+ The capacitance ratio and minimum capacitance are naturally defined
+ as
+
+
+ Cr*=min(C*air,C*wat)/max(C*air,C*wat)
+ and C*min=min(C*air,C*wat).
+
+
+
+ The number of transfer unit for the wet-coil is defined as
+ NTU*=UA*/C*min, where
+
+
+ UA*=1/(1/(UAair/cp,air)+1/(UAwat/csat).
+
+
+ References
+
+
+ Braun, James E. 1988. \"Methodologies for the Design and Control of
+ Central Cooling Plants\". PhD Thesis. University of Wisconsin -
+ Madison. Available online.
+
+
+ Mitchell, John W., and James E. Braun. 2012a. Principles of heating,
+ ventilation, and air conditioning in buildings. Hoboken, N.J.: Wiley.
+
+
+ Mitchell, John W., and James E. Braun. 2012b. \"Supplementary Material
+ Chapter 2: Heat Exchangers for Cooling Applications\". Excerpt from
+ Principles of heating, ventilation, and air conditioning in
+ buildings. Hoboken, N.J.: Wiley. Available
+ online.
-
- - June 10, 2021, by Michael Wetter:
- Changed implementation of the filter and changed the parameter
- order to a constant as most users need not change this
- value.
- This is for #1498.
-
- - August 7, 2020, by Ettore Zanetti:
- changed the computation of phi using max(0.1*l,
- . ) to avoid phi=0. See issue
- 1376.
-
- - November 9, 2019, by Filip Jorissen:
- Guarded the computation of phi using max(0, .
- ) to avoid negative phi. See issue
- 1223.
-
- - January 26, 2016, by Michael Wetter:
- Removed equality comparison for Real in the
- assert statements as this is not allowed in Modelica.
-
- - August 12, 2014, by Michael Wetter:
- Removed the end keyword when accessing array elements,
- as this language construct caused an error in OpenModelica.
-
- - April 4, 2014, by Michael Wetter:
- Moved the assignment of the flow function phi to the
- model instantiation because in its base class, the keyword
- input has been added to the variable phi.
-
- - March 26, 2014 by Michael Wetter:
- First implementation.
-
-
-------- Errors --------
-line 14 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 20 column 2 - Warning: attribute "align" not allowed for HTML5
+line 36 column 2 - Warning: attribute "align" not allowed for HTML5
+line 48 column 2 - Warning: attribute "align" not allowed for HTML5
+line 54 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/BoundaryConditions/WeatherData/ReaderTMY3.mo ----
+---- AixLib/Controls/Discrete/BooleanDelay.mo ----
-------- HTML Code --------
- Block to output the latitude of the location.
- This block is added so that the latitude is displayed
- with a comment in the GUI of the weather bus connector.
+ Block that delays the boolean input signal by
+ one sampling interval.
+ For example,
+ if u denotes the input,
+ y denotes the output, and
+ ti and ti+1
+ denote subsequent sampling
+ instants, then the model outputs
- Implementation
-
- If
-
- Modelica.Blocks.Sources.Constant where used, then
- the comment for the latitude would be \"Connector of Real output signal\".
- As this documentation string cannot be overwritten, a new block
- was implemented.
+
+ y(ti+1) = u(ti).
-
- January 4, 2016, by Michael Wetter:
+ June 6, 2015, by Michael Wetter:
+ Set start value and fixed attribute
+ for firstTrigger
+ to avoid a translation warning in pedantic mode
+ in Dymola 2016.
+ This is for
+ #266.
+
+ -
+ November 21, 2011, by Michael Wetter:
+ Improved documentation.
+
+ -
+ November 26, 2008, by Michael Wetter:
First implementation.
+-------- Corrected Code --------
+
+ Block that delays the boolean input signal by one sampling interval.
+ For example, if u denotes the input, y denotes the
+ output, and ti and ti+1 denote
+ subsequent sampling instants, then the model outputs
+
+
+ y(ti+1) = u(ti).
+
+
+ - June 6, 2015, by Michael Wetter:
+ Set start value and fixed attribute for
+ firstTrigger to avoid a translation warning in
+ pedantic mode in Dymola 2016. This is for #266.
+
+ - November 21, 2011, by Michael Wetter:
+ Improved documentation.
+
+ - November 26, 2008, by Michael Wetter:
+ First implementation.
+
+
+
+-------- Errors --------
+line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Humidifiers/SteamHumidifier_X.mo ----
+-------- HTML Code --------
+
- Block to output the longitude of the location.
- This block is added so that the longitude is displayed
- with a comment in the GUI of the weather bus connector.
+ Model for a steam humidifier with a prescribed outlet water vapor mass fraction
+ in kg/kg total air.
- Implementation
- If
-
- Modelica.Blocks.Sources.Constant where used, then
- the comment for the longitude would be \"Connector of Real output signal\".
- As this documentation string cannot be overwritten, a new block
- was implemented.
+ This model forces the outlet water mass fraction at port_b to be
+ no lower than the
+ input signal X_wSet, subject to optional limits on the
+ maximum water vapor mass flow rate that is added, as
+ described by the parameter mWatMax_flow.
+ By default, the model has unlimited capacity.
-
-
- -
- January 4, 2016, by Michael Wetter:
- First implementation.
-
-
-
- Block to output the altitude of the location.
- This block is added so that the altitude is displayed
- with a comment in the GUI of the weather bus connector.
+ The output signal mWat_flow ≥ 0 is the moisture added
+ to the medium if the flow rate is from port_a to port_b.
+ If the flow is reversed, then mWat_flow = 0.
+ The outlet specific enthalpy at port_b is increased by
+ the enthalpy of steam at 100°C times the mass of steam that was added.
+ Therefore, the temperature of the leaving fluid is slightly above the inlet temperature.
- Implementation
- If
-
- Modelica.Blocks.Sources.Constant where used, then
- the comment for the Altitude would be \"Connector of Real output signal\".
- As this documentation string cannot be overwritten, a new block
- was implemented.
+ The outlet conditions at port_a are not affected by this model,
+ other than for a possible pressure difference due to flow friction.
-
-
- -
- May 2, 2021, by Ettore Zanetti:
- First implementation.
-
-
-
- This component reads TMY3 weather data (Wilcox and Marion, 2008) or user specified weather data.
- The Modelica built-in variable time determines what row
- of the weather file is read.
- The value of time is the number of seconds
- that have passed since January 1st at midnight (00:00) in the local time zone.
- The local time zone value, longitude and latitute are also read from the weather data,
- such that the solar position computations are consistent with the weather data.
+ If the parameter energyDynamics is different from
+ Modelica.Fluid.Types.Dynamics.SteadyState,
+ the component models the dynamic response using a first order differential equation.
+ The time constant of the component is equal to the parameter tau.
+ This time constant is adjusted based on the mass flow rate using
+
+
+ τeff = τ |ṁ| ⁄ ṁnom
- The weather data format is the Typical Meteorological Year (TMY3)
- as obtained from the EnergyPlus web site at
-
- http://energyplus.net/weather. These
- data, which are in the EnergyPlus format, need to be converted as described
- below.
+ where
+ τeff is the effective time constant for the given mass flow rate
+ ṁ and
+ τ is the time constant at the nominal mass flow rate
+ ṁnom.
+ This type of dynamics is equal to the dynamics that a completely mixed
+ control volume would have.
-
- Output to weaBus
- The following variables serve as output and are accessible via weaBus:
+ Optionally, this model can have a flow resistance.
+ Set dp_nominal = 0 to disable the flow friction calculation.
-
-
-
- | Name
- |
- Unit
- |
- Description
- |
-
-
-
-
- HDifHor
- |
-
- W/m2
- |
-
- Horizontal diffuse solar radiation.
- |
-
-
-
-
- HDifNor
- |
-
- W/m2
- |
-
- Direct normal radiation.
- |
-
-
-
-
- HGloHor
- |
-
- W/m2
- |
-
- Horizontal global radiation.
- |
-
-
-
-
- HHorIR
- |
-
- W/m2
- |
-
- Horizontal infrared irradiation.
- |
-
-
-
-
- TBlaSky
- |
-
- K
- |
-
- Output temperature.
- |
-
-
-
-
- TDewPoi
- |
-
- K
- |
-
- Dew point temperature.
- |
-
-
-
-
- TDryBul
- |
-
- K
- |
-
- Dry bulb temperature at ground level.
- |
-
-
-
-
- TWetBul
- |
-
- K
- |
-
- Wet bulb temperature.
- |
-
-
-
-
- celHei
- |
-
- m
- |
-
- Ceiling height.
- |
-
-
-
-
- cloTim
- |
-
- s
- |
-
- One-based day number in seconds.
- |
-
-
-
-
- lat
- |
-
- rad
- |
-
- Latitude of the location.
- |
-
-
-
-
- lon
- |
-
- rad
- |
-
- Longitude of the location.
- |
-
-
-
-
- nOpa
- |
-
- 1
- |
-
- Opaque sky cover [0, 1].
- |
-
-
-
-
- nTot
- |
-
- 1
- |
-
- Total sky Cover [0, 1].
- |
-
-
-
-
- pAtm
- |
-
- Pa
- |
-
- Atmospheric pressure.
- |
-
-
-
-
- relHum
- |
-
- 1
- |
-
- Relative humidity.
- |
-
-
-
-
- solAlt
- |
-
- rad
- |
-
- Altitude angle.
- |
-
-
-
-
- solDec
- |
-
- rad
- |
-
- Declination angle.
- |
-
-
-
-
- solHouAng
- |
-
- rad
- |
-
- Solar hour angle.
- |
-
-
-
-
- solTim
- |
-
- s
- |
-
- Solar time.
- |
-
-
-
-
- solZen
- |
-
- rad
- |
-
- Zenith angle.
- |
-
-
-
-
- winDir
- |
-
- rad
- |
-
- Wind direction.
- |
-
-
-
-
- winSpe
- |
-
- m/s
- |
-
- Wind speed.
- |
-
-
-
- Adding new weather data
-
- To add new weather data, proceed as follows:
-
-
- -
- Download the weather data file with the
epw extension from
-
- http://energyplus.net/weather.
-
- -
- Add the file to
AixLib/Resources/weatherdata (or to any directory
- for which you have write permission).
-
- -
- On a console window, type
- cd AixLib/Resources/weatherdata
- java -jar ../bin/ConvertWeatherData.jar inputFile.epw
-
- if inputFile contains space in the name:
-
- java -jar ../bin/ConvertWeatherData.jar \"inputFile .epw\"
-
- This will generate the weather data file inputFile.mos, which can be read
- by the model
-
- AixLib.BoundaryConditions.WeatherData.ReaderTMY3.
-
-
-
- Location data that are read automatically from the weather data file
-
- The following location data are automatically read from the weather file:
-
-
- -
- The latitude of the weather station,
lat,
-
- -
- the longitude of the weather station,
lon, and
-
- -
- the time zone relative to Greenwich Mean Time,
timZone.
-
-
-
- Wet bulb temperature
-
- By default, the data bus contains the wet bulb temperature.
- This introduces a nonlinear equation.
- However, we have not observed an increase in computing time because
- of this equation.
- To disable the computation of the wet bulb temperature, set
- computeWetBulbTemperature=false.
-
-
- Using constant or user-defined input signals for weather data
-
- This model has the option of using a constant value, using the data from the weather file,
- or using data from an input connector for the following variables:
-
-
- -
- The atmospheric pressure,
-
- -
- the ceiling height,
-
- -
- the total sky cover,
-
- -
- the opaque sky cover,
-
- -
- the dry bulb temperature,
-
- -
- the dew point temperature,
-
- -
- the sky black body temperature,
-
- -
- the relative humidity,
-
- -
- the wind direction,
-
- -
- the wind speed,
-
- -
- the global horizontal radiation, direct normal and diffuse horizontal radiation,
- and
-
- -
- the infrared horizontal radiation.
-
-
-
- By default, all data are obtained from the weather data file,
- except for the atmospheric pressure, which is set to the
- parameter pAtm=101325 Pascals.
-
-
- The parameter *Sou configures the source of the data.
- For the atmospheric pressure, temperatures, relative humidity, wind speed and wind direction,
- the enumeration
-
- AixLib.BoundaryConditions.Types.DataSource
- is used as follows:
-
-
-
-
- Parameter *Sou
- |
- Data used to compute weather data.
- |
-
-
-
- |
- File
- |
-
- Use data from file.
- |
-
-
-
- |
- Parameter
- |
-
- Use value specified by the parameter.
- |
-
-
-
- |
- Input
- |
-
- Use value from the input connector.
- |
-
-
-
- Because global, diffuse and direct radiation are related to each other, the parameter
- HSou is treated differently.
- It is set to a value of the enumeration
-
- AixLib.BoundaryConditions.Types.RadiationDataSource,
- and allows the following configurations:
-
-
-
-
- Parameter HSou
- |
- Data used to compute weather data.
- |
-
-
-
- |
- File
- |
-
- Use data from file.
- |
-
-
-
- |
- Input_HGloHor_HDifHor
- |
-
- Use global horizontal and diffuse horizontal radiation from input connector.
- |
-
-
- |
- Input_HDirNor_HDifHor
- |
-
- Use direct normal and diffuse horizontal radiation from input connector.
- |
-
-
- |
- Input_HDirNor_HGloHor
- |
-
- Use direct normal and global horizontal radiation from input connector.
- |
-
-
-
- Length of weather data and simulation period
-
- If weather data span a year, which is the default for TMY3 data, or multiple years,
- then this model can be used for simulations that span multiple years. The simulation
- start time needs to be set to the clock time of the respective start time. For example,
- to start at January 2 at 10am, set start time to t=(24+10)*3600 seconds.
- For this computation, the used date and time (here January 2, 10 am) must be expressed in the same time zone
- as the one that is used to define the TMY3 file. This is usually the local (winter) time zone.
- The parameter `timZon` represents the TMY3 file time zone, expressed in seconds compared to UTC.
-
-
- Moreover, weather data need not span a whole year, or it can span across New Year.
- In this case, the simulation cannot exceed the time of the weather data file. Otherwise,
- the simulation stops with an error.
-
-
- As weather data have one entry at the start of the time interval, the end time of the weather
- data file is computed as the last time entry plus the average time increment of the file.
- For example, an hourly weather data file has 8760 entries, starting on January 1 at 0:00.
- The last entry in the file will be for December 31 at 23:00. As the time increment is 1 hour,
- the model assumes the weather file to end at December 31 at 23:00 plus 1 hour, e.g., at January 1 at 0:00.
-
-
- Notes
-
- -
-
- In HVAC systems, when the fan is off, changes in atmospheric pressure can cause small air flow rates
- in the duct system due to change in pressure and hence in the mass of air that is stored
- in air volumes (such as in fluid junctions or in the room model).
- This may increase computing time. Therefore, the default value for the atmospheric pressure is set to a constant.
- Furthermore, if the initial pressure of air volumes are different
- from the atmospheric pressure, then fast pressure transients can happen in the first few seconds of the simulation.
- This can cause numerical problems for the solver. To avoid this problem, set the atmospheric pressure to the
- same value as the medium default pressure, which is typically set to the parameter Medium.p_default.
- For medium models for moist air and dry air, the default is
- Medium.p_default=101325 Pascals.
-
-
- -
-
- Different units apply depending on whether data are obtained from a file, or
- from a parameter or an input connector:
-
-
- -
- When using TMY3 data from a file (e.g.
USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.mos), the units must be the same as the original TMY3 file used by EnergyPlus (e.g.
- USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.epw).
- The TMY3 data used by EnergyPlus are in both SI units and non-SI units.
- If Resources/bin/ConvertWeatherData.jar is used to convert the .epw file to an .mos file, the units of the TMY3 data are preserved and the file can be directly
- used by this data reader.
- The data reader will automatically convert units to the SI units used by Modelica.
- For example, the dry bulb temperature TDryBul in TMY3 is in degree Celsius.
- The data reader will automatically convert the data to Kelvin.
- The wind direction winDir in TMY3 is degrees and will be automatically converted to radians.
-
- -
- When using data from a parameter or from an input connector,
- the data must be in the SI units used by Modelica.
- For instance, the unit must be
-
Pa for pressure,
- K for temperature,
- W/m2 for solar radiations and
- rad for wind direction.
-
-
-
- -
-
- Hourly and subhourly timestamp are handled in a different way in .epw files.
- From the EnergyPlus Auxiliary Programs Document (v9.3.0, p. 63):
- In hourly data the minute field can be 00 or 60. In this case as mentioned in the previous section, the weather data
- is reported at the hourly value and the minute field has to be ignored, writing 1, 60 or 1, 00 is equivalent.
- If the minute field is between 00 and 60, the file becomes subhourly, in this case the timestamp corresponds to the
- minute field in the considered hour. For example: 1, 30 is equivalent to 00:30 and 3, 45 is equivalent to 02:45.
- (Note the offset in the hour digit.)
-
-
- -
- The ReaderTMY3 should only be used with TMY3 data. It contains a time shift for solar radiation data
- that is explained below. This time shift needs to be removed if the user may want to
- use the ReaderTMY3 for other weather data types.
-
-
- Implementation
- Start and end data for annual weather data files
-
- The TMY3 weather data, as well as the EnergyPlus weather data, start at 1:00 AM
- on January 1, and provide hourly data until midnight on December 31.
- Thus, the first entry for temperatures, humidity, wind speed etc. are values
- at 1:00 AM and not at midnight. Furthermore, the TMY3 weather data files can have
- values at midnight of December 31 that may be significantly different from the values
- at 1:00 AM on January 1.
- Since annual simulations require weather data that start at 0:00 on January 1,
- data need to be provided for this hour. Due to the possibly large change in
- weatherdata between 1:00 AM on January 1 and midnight at December 31,
- the weather data files in the AixLib library do not use the data entry from
- midnight at December 31 as the value for t=0. Rather, the
- value from 1:00 AM on January 1 is duplicated and used for 0:00 on January 1.
- To maintain a data record with 8760 hours, the weather data record from
- midnight at December 31 is deleted.
- These changes in the weather data file are done in the Java program
- AixLib/Resources/bin/ConvertWeatherData.jar that converts
- EnergyPlus weather data file to Modelica weather data files, and which is described
- above.
- The length of the weather data is calculated as the
- end time stamp minus start time stamp plus average increment, where the
- average increment is equal to the end time stamp minus start time stamp divided
- by the number of rows minus 1.
- This only works correctly for weather files with equidistant time stamps.
-
- Time shift for solar radiation data
-
- To read weather data from the TMY3 weather data file, there are
- two data readers in this model. One data reader obtains all data
- except solar radiation, and the other data reader reads only the
- solar radiation data, shifted by 30 minutes.
- The reason for this time shift is as follows:
- The TMY3 weather data file contains for solar radiation the
- \"...radiation received
- on a horizontal surface during
- the 60-minute period ending at
- the timestamp.\"
-
- Thus, as the figure below shows, a more accurate interpolation is obtained if
- time is shifted by 30 minutes prior to reading the weather data.
-
-
- ![\"image\"](\"modelica://AixLib/Resources/Images/BoundaryConditions/WeatherData/RadiationTimeShift.png\")
-
- References
-
- -
- Wilcox S. and W. Marion. Users Manual for TMY3 Data Sets.
- Technical Report, NREL/TP-581-43156, revised May 2008.
-
-
-
-
- -
- September 6, 2021, by Ettore Zanetti:
- Changed alt and lat to real inputs.
- This is for
- IBPSA, #1477.
-
- -
- May 2, 2021, by Ettore Zanetti:
- Added altitude to parameters.
- This is for
- IBPSA, #1477.
-
- -
- October 4, 2020, by Ettore Zanetti:
- Updated documentation for Java weather file generator.
- This is for
- #1396.
-
- -
- August 20, 2019, by Filip Jorissen:
- Better clarified the meaning of time in the documentation.
- This is for
- #1192.
-
- -
- March 5, 2019, by Michael Wetter:
- Updated documentation.
- This is for
- #842.
-
- -
- September 20, 2018, by Michael Wetter:
- Corrected documentation.
- This is for
- #1022.
-
- -
- December 4, 2017, by Michael Wetter:
- Removed function call to getAbsolutePath, as this causes in Dymola 2018FD01
- the error
- \"A call of loadResource with a non-literal string remains in the generated code; it will not work for an URI.\"
- when exporting
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZone
- as an FMU. Instead, if the weather file is specified as a Modelica, URI, syntax such as
- Modelica.Utilities.Files.loadResource(\"modelica://AixLib/Resources/weatherdata/USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.mos\")
- should be used.
- This is for
- #867.
-
- -
- February 18, 2017, by Filip Jorissen:
- Infrared radiation on horizontal surface is now delayed by 30 minutes
- such that the results in
- TBlaSky
- are consistent.
- This is for
- #648.
-
- -
- December 06, 2016, by Thierry S. Nouidui:
- Constrained the direct normal radiation to not be bigger than the solar constant when using
- global and diffuse solar radiation data provided via the inputs connectors.
- This is for
- #608.
-
- -
- April 21, 2016, by Michael Wetter:
- Introduced absFilNam to avoid multiple calls to
-
- AixLib.BoundaryConditions.WeatherData.BaseClasses.getAbsolutePath.
- This is for
- Buildings, #506.
-
- -
- January 6, 2016, by Moritz Lauster:
- Changed output radHorIR to HHorIR.
- This is for
- #376.
-
- -
- January 4, 2016, by Moritz Lauster:
- Added a table in documentation with output variables accessible via weaBus.
- This is for
- #376.
-
- -
- December 15, 2015, by Michael Wetter:
- Added the block cheTemBlaSky. This also allows to graphically
- connect the black body sky temperature to the weather bus, which is required
- in Dymola 2016 for the variable weaBus.TBlaSky to appear
- in the graphical editor.
- This is for
- #377.
-
- -
- September 24, 2015, by Marcus Fuchs:
- Replace Dymola specific annotation by loadSelector
- for MSL compliancy as reported by @tbeu at
- RWTH-EBC/AixLib#107
-
- -
- June 6, 2015, by Michael Wetter:
- Removed redundant but consistent
- connect(TBlaSkyCom.TBlaSky, weaBus.TBlaSky)
- statement.
- This avoids a warning if
-
- AixLib.BoundaryConditions.SolarIrradiation.BaseClasses.Examples.SkyClearness
- is translated in pedantic mode in Dymola 2016.
- This is for
- #266.
-
- -
- March 26, 2015, by Michael Wetter:
- Added option to obtain the black body sky temperature
- from a parameter or an input signal.
-
- -
- October 17, 2014, by Michael Wetter:
- Corrected error that led the total and opaque sky cover to be ten times
- too low if its value was obtained from the parameter or the input connector.
- For the standard configuration in which the sky cover is obtained from
- the weather data file, the model was correct. This error only affected
- the other two possible configurations.
-
- -
- September 12, 2014, by Michael Wetter:
- Removed redundant connection connect(conHorRad.HOut, cheHorRad.HIn);.
-
- -
- May 30, 2014, by Michael Wetter:
- Removed undesirable annotation Evaluate=true.
-
- -
- May 5, 2013, by Thierry S. Nouidui:
- Added the option to use a constant, an input signal or the weather file as the source
- for the ceiling height, the total sky cover, the opaque sky cover, the dew point temperature,
- and the infrared horizontal radiation HInfHor.
-
- -
- October 8, 2013, by Michael Wetter:
- Improved the algorithm that determines the absolute path of the file.
- Now weather files are searched in the path specified, and if not found, the urls
- file://, modelica:// and modelica://AixLib
- are added in this order to search for the weather file.
- This allows using the data reader without having to specify an absolute path,
- as long as the AixLib library
- is on the MODELICAPATH.
- This change was implemented in
-
- AixLib.BoundaryConditions.WeatherData.BaseClasses.getAbsolutePath
- and improves this weather data reader.
-
- -
- May 2, 2013, by Michael Wetter:
- Added function call to getAbsolutePath.
-
+
+ For a model that uses a control signal u ∈ [0, 1] and multiplies
+ this with the nominal water mass flow rate, use
+
+ AixLib.Fluid.Humidifiers.Humidifier_u
+
+
+ Limitations
+
+ This model only adds water vapor for the flow from
+ port_a to port_b.
+ The water vapor of the reverse flow is not affected by this model.
+
+
+
-
- October 16, 2012, by Michael Wetter:
- Added computation of the wet bulb temperature.
- Computing the wet bulb temperature introduces a nonlinear
- equation. As we have not observed an increase in computing time
- because of computing the wet bulb temperature, it is computed
- by default. By setting the parameter
- computeWetBulbTemperature=false, the computation of the
- wet bulb temperature can be removed.
- Revised documentation.
+ March 8, 2022, by Michael Wetter:
+ Renamed parameter massDynamics to energyDynamics for consistency with other models.
-
- August 11, 2012, by Wangda Zuo:
- Renamed radHor to radHorIR and
- improved the optional inputs for radiation data.
+ May 10, 2017, by Michael Wetter:
+ First implementation.
+
+
+-------- Corrected Code --------
+
+ Model for a steam humidifier with a prescribed outlet water vapor
+ mass fraction in kg/kg total air.
+
+
+ This model forces the outlet water mass fraction at
+ port_b to be no lower than the input signal
+ X_wSet, subject to optional limits on the maximum water
+ vapor mass flow rate that is added, as described by the parameter
+ mWatMax_flow. By default, the model has unlimited
+ capacity.
+
+
+ The output signal mWat_flow ≥ 0 is the moisture added to
+ the medium if the flow rate is from port_a to
+ port_b. If the flow is reversed, then mWat_flow =
+ 0. The outlet specific enthalpy at port_b is
+ increased by the enthalpy of steam at 100°C times the mass of
+ steam that was added. Therefore, the temperature of the leaving fluid
+ is slightly above the inlet temperature.
+
+
+ The outlet conditions at port_a are not affected by this
+ model, other than for a possible pressure difference due to flow
+ friction.
+
+
+ If the parameter energyDynamics is different from
+ Modelica.Fluid.Types.Dynamics.SteadyState, the component
+ models the dynamic response using a first order differential
+ equation. The time constant of the component is equal to the
+ parameter tau. This time constant is adjusted based on
+ the mass flow rate using
+
+
+ τeff = τ |ṁ| ⁄ ṁnom
+
+
+ where τeff is the effective time constant for the
+ given mass flow rate ṁ and τ is the time constant at
+ the nominal mass flow rate ṁnom. This type of
+ dynamics is equal to the dynamics that a completely mixed control
+ volume would have.
+
+
+ Optionally, this model can have a flow resistance. Set
+ dp_nominal = 0 to disable the flow friction calculation.
+
+
+ For a model that uses a control signal u ∈ [0, 1] and
+ multiplies this with the nominal water mass flow rate, use AixLib.Fluid.Humidifiers.Humidifier_u
+
+
+ Limitations
+
+
+ This model only adds water vapor for the flow from
+ port_a to port_b. The water vapor of the
+ reverse flow is not affected by this model.
+
+
+ - March 8, 2022, by Michael Wetter:
+ Renamed parameter massDynamics to
+ energyDynamics for consistency with other models.
+
+ - May 10, 2017, by Michael Wetter:
+ First implementation.
+
+
+
+-------- Errors --------
+line 33 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/HeatExchangers/EvaporatorCondenser.mo ----
+-------- HTML Code --------
+
+
+ Model for a constant temperature evaporator or condenser based on a ε-NTU
+ heat exchanger model.
+
+
+ The heat exchanger effectiveness is calculated from the number of transfer units
+ (NTU):
+
+
+ ε = 1 - exp(UA ⁄ (ṁ cp))
+
+
+ Optionally, this model can have a flow resistance.
+ If no flow resistance is requested, set dp_nominal=0.
+
+ Limitations
+
+ This model does not consider any superheating or supercooling on the refrigerant
+ side. The refrigerant is considered to exchange heat at a constant temperature
+ throughout the heat exchanger.
+
+
+
-
- July 24, 2012, by Wangda Zuo:
- Corrected the notes of SI unit requirements for input files.
+ March 7, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for
+ #1542.
-
- July 13, 2012, by Michael Wetter:
- Removed assignment of HGloHor_in in its declaration,
- because this gives an overdetermined system if the input connector
- is used.
- Removed non-required assignments of attribute displayUnit.
+ May 27, 2017, by Filip Jorissen:
+ Regularised heat transfer around zero flow.
+ This is for
+ #769.
-
- February 25, 2012, by Michael Wetter:
- Added subbus for solar position, which is needed by irradition and
- shading model.
+ April 12, 2017, by Michael Wetter:
+ Corrected invalid syntax for computing the specific heat capacity.
+ This is for
+ #707.
-
- November 29, 2011, by Michael Wetter:
- Fixed wrong display unit for pAtm_in_internal and
- made propagation of parameter final.
+ October 11, 2016, by Massimo Cimmino:
+ First implementation.
+
+
+-------- Corrected Code --------
+
+ Model for a constant temperature evaporator or condenser based on a
+ ε-NTU heat exchanger model.
+
+
+ The heat exchanger effectiveness is calculated from the number of
+ transfer units (NTU):
+
+
+ ε = 1 - exp(UA ⁄ (ṁ cp))
+
+
+ Optionally, this model can have a flow resistance. If no flow
+ resistance is requested, set dp_nominal=0.
+
+
+ Limitations
+
+
+ This model does not consider any superheating or supercooling on the
+ refrigerant side. The refrigerant is considered to exchange heat at a
+ constant temperature throughout the heat exchanger.
+
+
+ - March 7, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for #1542.
+
+ - May 27, 2017, by Filip Jorissen:
+ Regularised heat transfer around zero flow.
+ This is for #769.
+
+ - April 12, 2017, by Michael Wetter:
+ Corrected invalid syntax for computing the specific heat
+ capacity.
+ This is for #707.
+
+ - October 11, 2016, by Massimo Cimmino:
+ First implementation.
+
+
+
+-------- Errors --------
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Media/Antifreeze/PropyleneGlycolWater.mo ----
+-------- HTML Code --------
+
+
+ This base properties model is identical to
+
+ Modelica.Media.Water.ConstantPropertyLiquidWater,
+ except that the equation
+ u = cv_const*(T - reference_T)
+ has been replaced by u=h because
+ cp_const=cv_const.
+ Also, the model checks if the mass fraction of the mixture is within the
+ allowed limits.
+
+
+
+ Density of propylene antifreeze-water mixture at specified mass fraction
+ and temperature, based on Melinder (2010).
+
+ References
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
+ Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
+ IIR/IIF.
+
+
+
+
+
+ Dynamic viscosity of antifreeze-water mixture at specified mass fraction and
+ temperature, based on Melinder (2010).
+
+ References
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
+ Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
+ IIR/IIF.
+
+
+
-
- October 27, 2011, by Wangda Zuo:
-
- -
- Added optional connectors for dry bulb temperature, relative humidity, wind speed, wind direction, global horizontal radiation, diffuse horizontal radiation.
+ May 2, 2018 by Massimo Cimmino:
+ First implementation.
+ This function is used by
+
+ AixLib.Media.Antifreeze.PropyleneGlycolWater.
+
+
+
+ Fusion temperature of antifreeze-water mixture at specified mass fraction and
+ temperature, based on Melinder (2010).
+
+ References
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
+ Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
+ IIR/IIF.
+
+
+
+
+
+ Evaluates a thermophysical property of a mixture, based on correlations proposed
+ by Melinder (2010).
+
+
+ The polynomial has the form
+
+
+ f = a1 (x-xm)0(y-ym)0
+ + a2 (x-xm)0(y-ym)1
+ + ... +
+ any[1] (x-xm)0(y-ym)ny[1]-1
+ + ... +
+ any[1])+1 (x-xm)1(y-ym)0
+ + ... +
+ any[1]+ny[2] (x-xm)1(y-ym)ny[2]-1
+ + ...
+
+ References
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
+ Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
+ IIR/IIF.
+
+
+
-
- October 3, 2011, by Michael Wetter:
- Propagated value for sky temperature calculation to make it accessible as a parameter.
+ March 16, 2018 by Massimo Cimmino:
+ First implementation.
+ This function is used models in
+
+ AixLib.Media.Antifreeze.
+
+
+
+ Specific heat capacity of antifreeze-water mixture at specified mass fraction
+ and temperature, based on Melinder (2010).
+
+ References
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
+ Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
+ IIR/IIF.
+
+
+
-
- July 20, 2011, by Michael Wetter:
- Added the option to use a constant, an input signal or the weather file as the source
- for the atmospheric pressure.
- -
- March 15, 2011, by Wangda Zuo:
- Delete the wet bulb temperature since it may cause numerical problem.
+ March 16, 2018 by Massimo Cimmino:
+ First implementation.
+ This function is used by
+
+ AixLib.Media.Antifreeze.PropyleneGlycolWater.
+
+
+
+ Thermal conductivity of antifreeze-water mixture at specified mass fraction and
+ temperature, based on Melinder (2010).
+
+ References
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
+ Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
+ IIR/IIF.
+
+
+
-
- March 7, 2011, by Wangda Zuo:
- Added wet bulb temperature. Changed reader to read only needed columns.
- Added explanation for 30 minutes shift for radiation data.
+ March 16, 2018 by Massimo Cimmino:
+ First implementation.
+ This function is used by
+
+ AixLib.Media.Antifreeze.PropyleneGlycolWater.
+
+
+
+ This medium package models propylene glycol - water mixtures.
+
+
+ The mass density, specific heat capacity, thermal conductivity and viscosity
+ are assumed constant and evaluated at a set temperature and mass fraction of
+ propylene glycol within the mixture. The dependence of the four properties
+ are shown on the figure below.
+
+
+
+
+
+ The accuracy of the thermophysical properties is dependent on the temperature
+ variations encountered during simulations.
+ The figure below shows the relative error of the the four properties over a
+ 10 °C range around the temperature used to evaluate the constant
+ properties. The maximum errors are 0.8 % for mass density, 1.5 %
+ for specific heat capacity, 3.2 % for thermal conductivity and 250
+ % for dynamic viscosity.
+
+
+
+
+
+ The figure below shows the relative error of the the four properties over a
+ 20 °C range around the temperature used to evaluate the constant
+ proepties. The maximum errors are 1.6 % for mass density, 3.0 %
+ for specific heat capacity, 6.2 % for thermal conductivity and 950
+ % for dynamic viscosity.
+
+
+
+
+
+ The enthalpy is computed using the convention that h=0
+ if T=0 °C.
+
+ Limitations
+
+ Density, specific heat capacity, thermal conductivity and viscosity are constant.
+ The propylene glycol/water mixture is modeled as an incompressible liquid.
+ There are no phase changes. The medium is limited to temperatures below
+ 100 °C and mass fractions below 0.60.
+ As is the case for AixLib.Media.Water,
+ this medium package should not be used if
+ the simulation relies on the dynamic viscosity.
+
+ Typical use and important parameters
+
+ The temperature and mass fraction must be specified for the evaluation of the
+ constant thermophysical properties. A typical use of the package is (e.g. for
+ a temperature of 20 °C and a mass fraction of 0.40):
+
+
+ Medium = AixLib.Media.Antifreeze.PropyleneGlycolWater(property_T=293.15, X_a=0.40)
+
+
+
-
- March 5, 2011, by Michael Wetter:
- Changed implementation to obtain longitude and time zone directly
- from weather file.
+ October 26, 2018, by Filip Jorissen and Michael Wetter:
+ Now printing different messages if temperature or mass fraction is above or below its limit,
+ and adding instance name as JModelica does not print the full instance name in the assertion.
+ This is for
+ #1045.
-
- June 25, 2010, by Wangda Zuo:
+ March 16, 2018, by Massimo Cimmino:
First implementation.
-------- Corrected Code --------
- Block to output the latitude of the location. This block is added so
- that the latitude is displayed with a comment in the GUI of the
- weather bus connector.
+ This base properties model is identical to Modelica.Media.Water.ConstantPropertyLiquidWater,
+ except that the equation u = cv_const*(T - reference_T)
+ has been replaced by u=h because
+ cp_const=cv_const. Also, the model checks if the mass
+ fraction of the mixture is within the allowed limits.
+
+
+ Density of propylene antifreeze-water mixture at specified mass
+ fraction and temperature, based on Melinder (2010).
+
+
+ References
+
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids
+ (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
+ Indirect Systems. Paris: IIR/IIF.
+
+
+
+ Dynamic viscosity of antifreeze-water mixture at specified mass
+ fraction and temperature, based on Melinder (2010).
+
+
+ References
+
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids
+ (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
+ Indirect Systems. Paris: IIR/IIF.
+
+
+
+ Fusion temperature of antifreeze-water mixture at specified mass
+ fraction and temperature, based on Melinder (2010).
+
+
+ References
+
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids
+ (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
+ Indirect Systems. Paris: IIR/IIF.
+
+
+
+ Evaluates a thermophysical property of a mixture, based on
+ correlations proposed by Melinder (2010).
+
+
+ The polynomial has the form
+
+
+ f = a1 (x-xm)0(y-ym)0 +
+ a2 (x-xm)0(y-ym)1 + ... +
+ any[1] (x-xm)0(y-ym)ny[1]-1 + ... +
+ any[1])+1 (x-xm)1(y-ym)0 + ... +
+ any[1]+ny[2] (x-xm)1(y-ym)ny[2]-1 +
+ ...
- Implementation
+ References
- If Modelica.Blocks.Sources.Constant
- where used, then the comment for the latitude would be \"Connector of
- Real output signal\". As this documentation string cannot be
- overwritten, a new block was implemented.
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids
+ (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
+ Indirect Systems. Paris: IIR/IIF.
- - January 4, 2016, by Michael Wetter:
- First implementation.
+ - March 16, 2018 by Massimo Cimmino:
+ First implementation. This function is used models in AixLib.Media.Antifreeze.
- Block to output the longitude of the location. This block is added so
- that the longitude is displayed with a comment in the GUI of the
- weather bus connector.
+ Specific heat capacity of antifreeze-water mixture at specified mass
+ fraction and temperature, based on Melinder (2010).
- Implementation
+ References
- If Modelica.Blocks.Sources.Constant
- where used, then the comment for the longitude would be \"Connector of
- Real output signal\". As this documentation string cannot be
- overwritten, a new block was implemented.
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids
+ (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
+ Indirect Systems. Paris: IIR/IIF.
+
+ Thermal conductivity of antifreeze-water mixture at specified mass
+ fraction and temperature, based on Melinder (2010).
+
+
+ References
+
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids
+ (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
+ Indirect Systems. Paris: IIR/IIF.
+
+
+
+ This medium package models propylene glycol - water mixtures.
+
+
+ The mass density, specific heat capacity, thermal conductivity and
+ viscosity are assumed constant and evaluated at a set temperature and
+ mass fraction of propylene glycol within the mixture. The dependence
+ of the four properties are shown on the figure below.
+
+
+
+
+
+ The accuracy of the thermophysical properties is dependent on the
+ temperature variations encountered during simulations. The figure
+ below shows the relative error of the the four properties over a
+ 10 °C range around the temperature used to evaluate the
+ constant properties. The maximum errors are 0.8 % for mass
+ density, 1.5 % for specific heat capacity, 3.2 % for
+ thermal conductivity and 250 % for dynamic viscosity.
+
+
+
+
+
+ The figure below shows the relative error of the the four properties
+ over a 20 °C range around the temperature used to evaluate the
+ constant proepties. The maximum errors are 1.6 % for mass
+ density, 3.0 % for specific heat capacity, 6.2 % for
+ thermal conductivity and 950 % for dynamic viscosity.
+
+
+
+
+
+ The enthalpy is computed using the convention that h=0 if
+ T=0 °C.
+
+
+ Limitations
+
+
+ Density, specific heat capacity, thermal conductivity and viscosity
+ are constant. The propylene glycol/water mixture is modeled as an
+ incompressible liquid. There are no phase changes. The medium is
+ limited to temperatures below 100 °C and mass fractions below
+ 0.60. As is the case for AixLib.Media.Water, this medium
+ package should not be used if the simulation relies on the dynamic
+ viscosity.
+
+
+ Typical use and important parameters
+
+
+ The temperature and mass fraction must be specified for the
+ evaluation of the constant thermophysical properties. A typical use
+ of the package is (e.g. for a temperature of 20 °C and a mass
+ fraction of 0.40):
+
+
+ Medium =
+ AixLib.Media.Antifreeze.PropyleneGlycolWater(property_T=293.15,
+ X_a=0.40)
+
+
+ - October 26, 2018, by Filip Jorissen and Michael Wetter:
+ Now printing different messages if temperature or mass fraction is
+ above or below its limit, and adding instance name as JModelica
+ does not print the full instance name in the assertion. This is for
+ #1045.
+
+ - March 16, 2018, by Massimo Cimmino:
+ First implementation.
+
+
+
+-------- Errors --------
+line 9 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+line 24 column 2 - Warning: attribute "align" not allowed for HTML5
+line 35 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/timeGeometric.mo ----
+-------- HTML Code --------
+
+
+ This function attemps to build a vector of length nTim with a geometric
+ expansion of the time variable between dt and t_max.
+
+
+ If t_max > nTim*dt, then a geometrically expanding vector is built as
+
+
+ t = [dt, dt*(1-r2)/(1-r), ... , dt*(1-rn)/(1-r), ... , tmax],
+
+
+ where r is the geometric expansion factor.
+
+
+ If t_max < nTim*dt, then a linearly expanding vector is built as
+
+
+ t = [dt, 2*dt, ... , n*dt, ... , nTim*dt]
+
+
+
+ -
+ June 28, 2018 by Massimo Cimmino:
+ First implementation.
+
+
+
+-------- Corrected Code --------
+
+ This function attemps to build a vector of length nTim
+ with a geometric expansion of the time variable between
+ dt and t_max.
+
+
+ If t_max > nTim*dt, then a geometrically expanding
+ vector is built as
+
+
+ t = [dt, dt*(1-r2)/(1-r), ... ,
+ dt*(1-rn)/(1-r), ... , tmax],
+
+
+ where r is the geometric expansion factor.
+
+
+ If t_max < nTim*dt, then a linearly expanding vector
+ is built as
+
+
+ t = [dt, 2*dt, ... , n*dt, ... , nTim*dt]
+
+
+ - June 28, 2018 by Massimo Cimmino:
First implementation.
+
+-------- Errors --------
+line 9 column 2 - Warning: attribute "align" not allowed for HTML5
+line 18 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Controls/SetPoints/Examples/SupplyReturnTemperatureReset.mo ----
+-------- HTML Code --------
+
+
+ Example that demonstrates the use of the hot water temperature reset
+ for a heating system.
+ The parameters of the block heaCur
+ are for a heating system with
+ 60°C supply water temperature and
+ 40°C return water temperature at
+ an outside temperature of
+ -10°C and a room temperature of
+ 20°C. The offset for the temperature reset is
+ 8 Kelvin, i.e., above
+ 12°C outside temperature, there is no heating load.
+ The figure below shows the computed supply and return water temperatures.
+
+
+
+
+
+
+ -
+ November 21, 2011, by Michael Wetter:
+ Added documentation.
+
+
+
+-------- Corrected Code --------
- Block to output the altitude of the location. This block is added so
- that the altitude is displayed with a comment in the GUI of the
- weather bus connector.
+ Example that demonstrates the use of the hot water temperature reset
+ for a heating system. The parameters of the block heaCur
+ are for a heating system with 60°C supply water temperature
+ and 40°C return water temperature at an outside temperature of
+ -10°C and a room temperature of 20°C. The offset for
+ the temperature reset is 8 Kelvin, i.e., above 12°C
+ outside temperature, there is no heating load. The figure below shows
+ the computed supply and return water temperatures.
-
- Implementation
-
-
- If Modelica.Blocks.Sources.Constant
- where used, then the comment for the Altitude would be \"Connector of
- Real output signal\". As this documentation string cannot be
- overwritten, a new block was implemented.
+
+
- - May 2, 2021, by Ettore Zanetti:
- First implementation.
+ - November 21, 2011, by Michael Wetter:
+ Added documentation.
-
- This component reads TMY3 weather data (Wilcox and Marion, 2008) or
- user specified weather data. The Modelica built-in variable
- time determines what row of the weather file is read.
- The value of time is the number of seconds that have
- passed since January 1st at midnight (00:00) in the local time zone.
- The local time zone value, longitude and latitute are also read from
- the weather data, such that the solar position computations are
- consistent with the weather data.
-
-
- The weather data format is the Typical Meteorological Year (TMY3) as
- obtained from the EnergyPlus web site at http://energyplus.net/weather.
- These data, which are in the EnergyPlus format, need to be converted
- as described below.
-
-
- Output to weaBus
-
-
- The following variables serve as output and are accessible via
- weaBus:
-
-
-
-
- |
- Name
- |
-
- Unit
- |
-
- Description
- |
-
-
-
- HDifHor
- |
-
- W/m2
- |
-
- Horizontal diffuse solar radiation.
- |
-
-
-
- HDifNor
- |
-
- W/m2
- |
-
- Direct normal radiation.
- |
-
-
-
- HGloHor
- |
-
- W/m2
- |
-
- Horizontal global radiation.
- |
-
-
-
- HHorIR
- |
-
- W/m2
- |
-
- Horizontal infrared irradiation.
- |
-
-
-
- TBlaSky
- |
-
- K
- |
-
- Output temperature.
- |
-
-
-
- TDewPoi
- |
-
- K
- |
-
- Dew point temperature.
- |
-
-
-
- TDryBul
- |
-
- K
- |
-
- Dry bulb temperature at ground level.
- |
-
-
-
- TWetBul
- |
-
- K
- |
-
- Wet bulb temperature.
- |
-
-
-
- celHei
- |
-
- m
- |
-
- Ceiling height.
- |
-
-
-
- cloTim
- |
-
- s
- |
-
- One-based day number in seconds.
- |
-
-
-
- lat
- |
-
- rad
- |
-
- Latitude of the location.
- |
-
-
-
- lon
- |
-
- rad
- |
-
- Longitude of the location.
- |
-
-
-
- nOpa
- |
-
- 1
- |
-
- Opaque sky cover [0, 1].
- |
-
+
+-------- Errors --------
+line 16 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Controls/Continuous/NumberOfRequests.mo ----
+-------- HTML Code --------
+
+
+ Block that outputs the number of inputs that exceed a threshold.
+ The parameter kind is used to determine the kind of the
+ inequality. The table below shows the allowed settings.
+
+
+
+ Value of parameter kind |
+ Output signal incremented by 1 for each i ∈ {1, ..., nin} if |
+
+
+ | 0 |
+ u[i] > threShold |
+
+
+ | 1 |
+ u[i] ≥ threShold |
+
+
+ | 2 |
+ u[i] ≤ threShold |
+
+
+ | 3 |
+ u[i] < threShold |
+
+
+
+ This model may be used to check how many rooms
+ exceed a temperature threshold.
+
+
+
+ -
+ November 21, 2011, by Michael Wetter:
+ Improved documentation.
+
+ -
+ November 25, 2008, by Michael Wetter:
+ First implementation.
+
+
+
+-------- Corrected Code --------
+
+ Block that outputs the number of inputs that exceed a threshold. The
+ parameter kind is used to determine the kind of the
+ inequality. The table below shows the allowed settings.
+
+
-
- nTot
- |
-
- 1
- |
-
- Total sky Cover [0, 1].
- |
-
+
+ Value of parameter kind
+ |
+
+ Output signal incremented by 1 for each i ∈ {1, ..., nin}
+ if
+ |
+
- pAtm
- |
-
- Pa
+ 0
|
- Atmospheric pressure.
+ u[i] > threShold
|
-
+
-
- relHum
- |
1
|
- Relative humidity.
- |
-
-
-
- solAlt
- |
-
- rad
- |
-
- Altitude angle.
- |
-
-
-
- solDec
- |
-
- rad
- |
-
- Declination angle.
- |
-
-
-
- solHouAng
- |
-
- rad
- |
-
- Solar hour angle.
- |
-
-
-
- solTim
- |
-
- s
- |
-
- Solar time.
- |
-
-
-
- solZen
- |
-
- rad
- |
-
- Zenith angle.
+ u[i] ≥ threShold
|
-
+
- winDir
- |
-
- rad
+ 2
|
- Wind direction.
+ u[i] ≤ threShold
|
-
+
- winSpe
- |
-
- m/s
+ 3
|
- Wind speed.
+ u[i] < threShold
|
-
-
- Adding new weather data
-
+
+
+ This model may be used to check how many rooms exceed a temperature
+ threshold.
+
+
+ - November 21, 2011, by Michael Wetter:
+ Improved documentation.
+
+ - November 25, 2008, by Michael Wetter:
+ First implementation.
+
+
+
+-------- Errors --------
+line 7 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+
+
+---- AixLib/Utilities/Math/Biquadratic.mo ----
+-------- HTML Code --------
+
+
+ This block computes
+
+
+ y = a1 + a2 x1
+ + a3 x12
+ + a4 x2 + a5 x22
+ + a6 x1 x2
+
+
+
+ -
+ Sep. 8, 2010, by Michael Wetter:
+ First implementation.
+
+
+
+-------- Corrected Code --------
+
+ This block computes
+
+
+ y = a1 + a2 x1 + a3
+ x12 + a4 x2 +
+ a5 x22 + a6 x1
+ x2
+
+
+ - Sep. 8, 2010, by Michael Wetter:
+ First implementation.
+
+
+
+-------- Errors --------
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/FMI/UsersGuide.mo ----
+-------- HTML Code --------
+
+
+This user's guide describes the FMI package (Wetter et al., 2015).
+The FMI package has been implemented to facilitate the export
+of thermofluid flow models such as HVAC components, HVAC systems
+and thermal zones as Functional Mockup Units (FMUs).
+This allows to export thermofluid flow models as FMUs so that they can be
+imported in other simulators.
+To export thermofluid flow components, a Modelica block is needed
+in order for the model to only have input and output signals
+rather than fluid connectors, as fluid connectors do not impose any causality
+on the signal flow.
+This package implements such blocks and its connectors.
+
+
+The main packages are as follows:
+
+
+
+ | Package | Description |
+
+
+ |
+
+ AixLib.Fluid.FMI.ExportContainers
+ |
+
+
+ Package with blocks to export thermofluid flow components and systems.
+
+
+ To export an HVAC component or system with a single inlet and outlet port, instantiate
+
+ AixLib.Fluid.FMI.ExportContainers.ReplaceableTwoPort
+ with a replaceable model,
+ or extend from
+
+ AixLib.Fluid.FMI.ExportContainers.PartialTwoPort
+ and add components.
+ See
+
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.Fan
+ and
+
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ResistanceVolume.
+
+
+ To export an HVAC system that serves a single thermal zone, extend from
+
+ AixLib.Fluid.FMI.ExportContainers.HVACZone
+ and add the HVAC system.
+ See
+
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZone.
+
+
+ To export an HVAC system that serves multiple thermal zones, extend from
+
+ AixLib.Fluid.FMI.ExportContainers.HVACZones
+ and add the HVAC system.
+ See
+
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZones.
+
+
+ To export a single thermal zone, extend from
+
+ AixLib.Fluid.FMI.ExportContainers.ThermalZone
+ and add the thermal zone.
+ See
+
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZone.
+
+
+ To export multiple thermal zones, extend from
+
+ AixLib.Fluid.FMI.ExportContainers.ThermalZones
+ and add the thermal zone models.
+ See
+
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZones.
+
+ |
+
+
+ |
+
+ AixLib.Fluid.FMI.Adaptors
+ |
+
+
+ Package with adaptors to connect models with fluid ports to blocks that
+ have input and output signals.
+
+ |
+
+
+|
+
+
+ AixLib.Fluid.FMI.Conversion
+
+ |
+
+
+ Package with blocks that convert between the signal connectors of
+
+ AixLib.Fluid.FMI.Interfaces
+ and the real input and output signal connectors of the Modelica Standard Library.
+
+ |
+
+
+|
+
+ AixLib.Fluid.FMI.Interfaces
+ |
+
+
+ Package with composite connectors that have different input and output
+ signals. These connectors are used to export FMUs, and they contain
+ quantities such as mass flow rate, temperature, optional pressure, etc.
+
+ |
+
+
- To add new weather data, proceed as follows:
+The package
+
+AixLib.Fluid.FMI.ExportContainers.Examples.FMUs
+contains various examples in which HVAC components, HVAC systems
+and thermal zones are exported as an FMU.
+
+Typical use
+
+Users who want to export a single thermofluid flow component, or a
+subsystem of thermofluid flow components, can use the block
+
+AixLib.Fluid.FMI.ExportContainers.ReplaceableTwoPort.
+This block has a fluid inlet, a fluid outlet, and a replaceable
+component that can be replaced with an HVAC component or system that
+has an inlet and outlet fluid port.
+
+
+Users who want to export a whole HVAC system that serves a single thermal zone
+can do so by extending the partial block
+
+AixLib.Fluid.FMI.ExportContainers.HVACZone.
+The example
+
+AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZone
+illustrates how this can be accomplished.
+Similar export containers and examples are implemented for HVAC systems that serve multiple thermal zones.
+
+
+Conversely, to export a thermal zone, users can extend the partial block
+
+AixLib.Fluid.FMI.ExportContainers.ThermalZone.
+The example
+
+AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZone
+illustrates how this can be accomplished.
+Similar export containers and examples are implemented for models of multiple thermal zones.
+
+
+Each example and validation model has a Dymola script that
+either simulates the model, or exports the model as an FMU.
+The script can be invoked from the pull
+down menu Commands -> Export FMU.
+
+Options
+
+In the
+AixLib.Fluid package,
+most models have a boolean parameter called allowFlowReversal.
+If set to true, then the flow can be in either direction,
+otherwise it needs to be from the inlet to the outlet port.
+This parameter is also used in the
+AixLib.Fluid.FMI package.
+The package was designed in such a way that an FMU,
+if exported with allowFlowReversal=false
+has as input the mass flow rate,
+pressure and fluid properties of the inflowing fluid. The outputs
+are the outlet mass flow rate, outlet pressure and the fluid
+properties of the outflowing medium. This allows simulators
+such as Ptolemy II
+to evaluate the FMUs in the direction of the mass flow by first
+setting all inputs, then evaluating the model equations,
+and finally retrieving the
+outputs before proceeding the simulation with the next downstream
+component.
+If allowFlowReversal=true, then the connectors have additional
+signals for the properties of the fluid if it flows backwards.
+
+
+Most components have a boolean parameter use_p_in.
+If use_p_in=true, then the pressure is used from the
+connector, and based on the mass flow rate, the outlet pressure
+is computed and assigned to the outlet connectors.
+If use_p_in=false, then the pressure as declared
+by the constant p_default of the medium model is
+used, and the component computes no pressure drop.
+Setting use_p_in=false therefore leads to fewer
+equations, but it requires a component that specifies the mass
+flow rate, such as
+
+AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.IdealSource_m_flow.
+
+Notes
+
+Note the following when exporting HVAC component models as an FMU:
- - Download the weather data file with the
epw
- extension from http://energyplus.net/weather.
-
- - Add the file to
AixLib/Resources/weatherdata (or to
- any directory for which you have write permission).
-
- - On a console window, type
-
- cd AixLib/Resources/weatherdata
- java -jar ../bin/ConvertWeatherData.jar inputFile.epw
- if inputFile contains space in the name:
-
- java -jar ../bin/ConvertWeatherData.jar \"inputFile .epw\"
- This will generate the weather data file
-inputFile.mos, which can be read by the model AixLib.BoundaryConditions.WeatherData.ReaderTMY3.
-
-
-
- Location data that are read automatically from the weather data file
-
+-
- The following location data are automatically read from the weather
- file:
+For models with control volumes,
+the mass balance must be configured using
+massDynamics=Modelica.Fluid.Types.Dynamics.SteadyState
+when used with the media
+
+AixLib.Media.Air.
+Otherwise, the translation stops with the error
-
- - The latitude of the weather station,
lat,
-
- - the longitude of the weather station,
lon, and
-
- - the time zone relative to Greenwich Mean Time,
-
timZone.
-
-
-
- Wet bulb temperature
-
+
+The model requires derivatives of some inputs as listed below:
+1 inlet.p
+
- By default, the data bus contains the wet bulb temperature. This
- introduces a nonlinear equation. However, we have not observed an
- increase in computing time because of this equation. To disable the
- computation of the wet bulb temperature, set
- computeWetBulbTemperature=false.
-
-
- Using constant or user-defined input signals for weather data
-
+The reason is that for
+
+AixLib.Media.Air,
+mass is proportional to pressure and pressure is proportional
+to density. Hence, dm/dt requires dp/dt,
+but the time derivative of the pressure is not an input to the model.
+
- This model has the option of using a constant value, using the data
- from the weather file, or using data from an input connector for the
- following variables:
+For
+AixLib.Media.Water, this setting is not needed
+as the mass is independent of pressure.
-
- - The atmospheric pressure,
-
- - the ceiling height,
-
- - the total sky cover,
-
- - the opaque sky cover,
-
- - the dry bulb temperature,
-
- - the dew point temperature,
-
- - the sky black body temperature,
-
- - the relative humidity,
-
- - the wind direction,
-
- - the wind speed,
-
- - the global horizontal radiation, direct normal and diffuse
- horizontal radiation, and
-
- - the infrared horizontal radiation.
-
-
+
+-
+
+The model
+
+AixLib.Fluid.Movers.FlowControlled_m_flow
+cannot be exported as an FMU.
+This is because it assignes the mass flow rate.
+However, the input connector
+
+AixLib.Fluid.FMI.Interfaces.Inlet
+already declares the mass flow rate as an input.
+Therefore, the mass flow rate is overdetermined.
+As a fall back, if a user needs to set the mass flow rate, he/she can
+do so by using
+
+AixLib.Fluid.FMI.Source_T,
+which takes as an input signal the mass flow rate.
+
+
+
- By default, all data are obtained from the weather data file, except
- for the atmospheric pressure, which is set to the parameter
- pAtm=101325 Pascals.
+When connecting fluid flow components in a loop,
+be careful to avoid circular assignments for example for the temperature,
+as these can of course not be simulated.
+An example of such an ill-posed problem is to connect the outlet of
+
+AixLib.Fluid.FixedResistances.PressureDrop
+to its inlet. In this situation, neither pressure, nor mass flow rate or temperature
+can be computed. To model such loops, a control volume with a dynamic energy
+balance must be presented, and the medium needs to be compressible.
+References
- The parameter *Sou configures the source of the data.
- For the atmospheric pressure, temperatures, relative humidity, wind
- speed and wind direction, the enumeration AixLib.BoundaryConditions.Types.DataSource
- is used as follows:
+Michael Wetter, Marcus Fuchs and Thierry Stephane Nouidui.
+
+Design choices for thermofluid flow components and systems that are exported as Functional Mockup Units.
+Proc. of the 11th International Modelica Conference,
+ p. 31-41,
+ Versailles, France, September 2015.
-
-
-
-
- Parameter *Sou
- |
-
- Data used to compute weather data.
- |
-
-
- |
- File
- |
-
- Use data from file.
- |
-
-
- |
- Parameter
- |
-
- Use value specified by the parameter.
- |
-
-
- |
- Input
- |
-
- Use value from the input connector.
- |
-
-
+
+-------- Corrected Code --------
- Because global, diffuse and direct radiation are related to each
- other, the parameter HSou is treated differently. It is
- set to a value of the enumeration AixLib.BoundaryConditions.Types.RadiationDataSource,
- and allows the following configurations:
+ This user's guide describes the FMI package (Wetter et al., 2015).
+ The FMI package has been implemented to facilitate the export of
+ thermofluid flow models such as HVAC components, HVAC systems and
+ thermal zones as Functional Mockup Units (FMUs). This allows to
+ export thermofluid flow models as FMUs so that they can be imported
+ in other simulators. To export thermofluid flow components, a
+ Modelica block is needed in order for the model to only have input
+ and output signals rather than fluid connectors, as fluid connectors
+ do not impose any causality on the signal flow. This package
+ implements such blocks and its connectors.
+
+
+ The main packages are as follows:
-
- Parameter HSou
+ Package
|
- Data used to compute weather data.
+ Description
|
-
+
|
- File
+ AixLib.Fluid.FMI.ExportContainers
|
- Use data from file.
+
+ Package with blocks to export thermofluid flow components and
+ systems.
+
+
+ To export an HVAC component or system with a single inlet and
+ outlet port, instantiate
+ AixLib.Fluid.FMI.ExportContainers.ReplaceableTwoPort with a
+ replaceable model, or extend from AixLib.Fluid.FMI.ExportContainers.PartialTwoPort
+ and add components.
+ See
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.Fan and
+
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ResistanceVolume.
+
+
+ To export an HVAC system that serves a single thermal zone,
+ extend from AixLib.Fluid.FMI.ExportContainers.HVACZone
+ and add the HVAC system.
+ See
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZone.
+
+
+ To export an HVAC system that serves multiple thermal zones,
+ extend from AixLib.Fluid.FMI.ExportContainers.HVACZones
+ and add the HVAC system.
+ See
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZones.
+
+
+ To export a single thermal zone, extend from AixLib.Fluid.FMI.ExportContainers.ThermalZone
+ and add the thermal zone.
+ See
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZone.
+
+
+ To export multiple thermal zones, extend from AixLib.Fluid.FMI.ExportContainers.ThermalZones
+ and add the thermal zone models.
+ See
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZones.
+
|
-
+
|
- Input_HGloHor_HDifHor
+ AixLib.Fluid.FMI.Adaptors
|
- Use global horizontal and diffuse horizontal radiation from input
- connector.
+
+ Package with adaptors to connect models with fluid ports to
+ blocks that have input and output signals.
+
|
|
- Input_HDirNor_HDifHor
+
+ AixLib.Fluid.FMI.Conversion
+
|
- Use direct normal and diffuse horizontal radiation from input
- connector.
+
+ Package with blocks that convert between the signal connectors
+ of AixLib.Fluid.FMI.Interfaces
+ and the real input and output signal connectors of the Modelica
+ Standard Library.
+
|
|
- Input_HDirNor_HGloHor
+ AixLib.Fluid.FMI.Interfaces
|
- Use direct normal and global horizontal radiation from input
- connector.
+
+ Package with composite connectors that have different input and
+ output signals. These connectors are used to export FMUs, and
+ they contain quantities such as mass flow rate, temperature,
+ optional pressure, etc.
+
|
-
+
+
+ The package AixLib.Fluid.FMI.ExportContainers.Examples.FMUs
+ contains various examples in which HVAC components, HVAC systems and
+ thermal zones are exported as an FMU.
+
- Length of weather data and simulation period
+ Typical use
- If weather data span a year, which is the default for TMY3 data, or
- multiple years, then this model can be used for simulations that span
- multiple years. The simulation start time needs to be set to the
- clock time of the respective start time. For example, to start at
- January 2 at 10am, set start time to t=(24+10)*3600
- seconds. For this computation, the used date and time (here January
- 2, 10 am) must be expressed in the same time zone as the one that is
- used to define the TMY3 file. This is usually the local (winter) time
- zone. The parameter `timZon` represents the TMY3 file time zone,
- expressed in seconds compared to UTC.
+ Users who want to export a single thermofluid flow component, or a
+ subsystem of thermofluid flow components, can use the block AixLib.Fluid.FMI.ExportContainers.ReplaceableTwoPort.
+ This block has a fluid inlet, a fluid outlet, and a replaceable
+ component that can be replaced with an HVAC component or system that
+ has an inlet and outlet fluid port.
+
+
+ Users who want to export a whole HVAC system that serves a single
+ thermal zone can do so by extending the partial block AixLib.Fluid.FMI.ExportContainers.HVACZone.
+ The example
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZone
+ illustrates how this can be accomplished.
+ Similar export containers and examples are implemented for HVAC
+ systems that serve multiple thermal zones.
+
+
+ Conversely, to export a thermal zone, users can extend the partial
+ block AixLib.Fluid.FMI.ExportContainers.ThermalZone.
+ The example
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZone
+ illustrates how this can be accomplished.
+ Similar export containers and examples are implemented for models of
+ multiple thermal zones.
+
+
+ Each example and validation model has a Dymola script that either
+ simulates the model, or exports the model as an FMU. The script can
+ be invoked from the pull down menu Commands -> Export
+ FMU.
+
+
+ Options
+
+
+ In the AixLib.Fluid package,
+ most models have a boolean parameter called
+ allowFlowReversal. If set to true, then the
+ flow can be in either direction, otherwise it needs to be from the
+ inlet to the outlet port. This parameter is also used in the AixLib.Fluid.FMI package. The
+ package was designed in such a way that an FMU, if exported with
+ allowFlowReversal=false has as input the mass flow rate,
+ pressure and fluid properties of the inflowing fluid. The outputs are
+ the outlet mass flow rate, outlet pressure and the fluid properties
+ of the outflowing medium. This allows simulators such as Ptolemy II
+ to evaluate the FMUs in the direction of the mass flow by first
+ setting all inputs, then evaluating the model equations, and finally
+ retrieving the outputs before proceeding the simulation with the next
+ downstream component. If allowFlowReversal=true, then
+ the connectors have additional signals for the properties of the
+ fluid if it flows backwards.
- Moreover, weather data need not span a whole year, or it can span
- across New Year. In this case, the simulation cannot exceed the time
- of the weather data file. Otherwise, the simulation stops with an
- error.
+ Most components have a boolean parameter use_p_in. If
+ use_p_in=true, then the pressure is used from the
+ connector, and based on the mass flow rate, the outlet pressure is
+ computed and assigned to the outlet connectors. If
+ use_p_in=false, then the pressure as declared by the
+ constant p_default of the medium model is used, and the
+ component computes no pressure drop. Setting
+ use_p_in=false therefore leads to fewer equations, but
+ it requires a component that specifies the mass flow rate, such as
+
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.IdealSource_m_flow.
-
- As weather data have one entry at the start of the time interval, the
- end time of the weather data file is computed as the last time entry
- plus the average time increment of the file. For example, an hourly
- weather data file has 8760 entries, starting on January 1 at 0:00.
- The last entry in the file will be for December 31 at 23:00. As the
- time increment is 1 hour, the model assumes the weather file to end
- at December 31 at 23:00 plus 1 hour, e.g., at January 1 at 0:00.
-
Notes
+
+ Note the following when exporting HVAC component models as an FMU:
+
-
- In HVAC systems, when the fan is off, changes in atmospheric
- pressure can cause small air flow rates in the duct system due to
- change in pressure and hence in the mass of air that is stored in
- air volumes (such as in fluid junctions or in the room model).
- This may increase computing time. Therefore, the default value
- for the atmospheric pressure is set to a constant. Furthermore,
- if the initial pressure of air volumes are different from the
- atmospheric pressure, then fast pressure transients can happen in
- the first few seconds of the simulation. This can cause numerical
- problems for the solver. To avoid this problem, set the
- atmospheric pressure to the same value as the medium default
- pressure, which is typically set to the parameter
- Medium.p_default. For medium models for moist air
- and dry air, the default is Medium.p_default=101325
- Pascals.
+ For models with control volumes, the mass balance must be
+ configured using
+ massDynamics=Modelica.Fluid.Types.Dynamics.SteadyState
+ when used with the media AixLib.Media.Air. Otherwise,
+ the translation stops with the error
-
- -
+
+The model requires derivatives of some inputs as listed below:
+1 inlet.p
+
- Different units apply depending on whether data are obtained from
- a file, or from a parameter or an input connector:
+ The reason is that for AixLib.Media.Air, mass is
+ proportional to pressure and pressure is proportional to density.
+ Hence, dm/dt requires dp/dt, but the time
+ derivative of the pressure is not an input to the model.
+
+
+ For AixLib.Media.Water, this
+ setting is not needed as the mass is independent of pressure.
-
- - When using TMY3 data from a file (e.g.
-
USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.mos), the
- units must be the same as the original TMY3 file used by
- EnergyPlus (e.g.
- USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.epw). The
- TMY3 data used by EnergyPlus are in both SI units and non-SI
- units. If Resources/bin/ConvertWeatherData.jar is
- used to convert the .epw file to an
- .mos file, the units of the TMY3 data are preserved
- and the file can be directly used by this data reader. The data
- reader will automatically convert units to the SI units used by
- Modelica. For example, the dry bulb temperature
- TDryBul in TMY3 is in degree Celsius. The data
- reader will automatically convert the data to Kelvin. The wind
- direction winDir in TMY3 is degrees and will be
- automatically converted to radians.
-
- - When using data from a parameter or from an input connector,
- the data must be in the SI units used by Modelica. For instance,
- the unit must be
Pa for pressure, K for
- temperature, W/m2 for solar radiations and
- rad for wind direction.
-
-
-
- Hourly and subhourly timestamp are handled in a different way in
- .epw files. From the EnergyPlus Auxiliary Programs
- Document (v9.3.0, p. 63): In hourly data the minute field can be
- 00 or 60. In this case as mentioned in
- the previous section, the weather data is reported at the hourly
- value and the minute field has to be ignored, writing 1,
- 60 or 1, 00 is equivalent. If the minute
- field is between 00 and 60, the file
- becomes subhourly, in this case the timestamp corresponds to the
- minute field in the considered hour. For example: 1,
- 30 is equivalent to 00:30 and 3, 45 is
- equivalent to 02:45.
- (Note the offset in the hour digit.)
+ The model AixLib.Fluid.Movers.FlowControlled_m_flow
+ cannot be exported as an FMU. This is because it assignes the
+ mass flow rate. However, the input connector AixLib.Fluid.FMI.Interfaces.Inlet
+ already declares the mass flow rate as an input. Therefore, the
+ mass flow rate is overdetermined. As a fall back, if a user needs
+ to set the mass flow rate, he/she can do so by using AixLib.Fluid.FMI.Source_T,
+ which takes as an input signal the mass flow rate.
- - The ReaderTMY3 should only be used with TMY3 data. It contains a
- time shift for solar radiation data that is explained below. This
- time shift needs to be removed if the user may want to use the
- ReaderTMY3 for other weather data types.
-
+
+ When connecting fluid flow components in a loop, be careful to avoid
+ circular assignments for example for the temperature, as these can of
+ course not be simulated. An example of such an ill-posed problem is
+ to connect the outlet of AixLib.Fluid.FixedResistances.PressureDrop
+ to its inlet. In this situation, neither pressure, nor mass flow rate
+ or temperature can be computed. To model such loops, a control volume
+ with a dynamic energy balance must be presented, and the medium needs
+ to be compressible.
+
- Implementation
+ References
-
- Start and end data for annual weather data files
-
- The TMY3 weather data, as well as the EnergyPlus weather data, start
- at 1:00 AM on January 1, and provide hourly data until midnight on
- December 31. Thus, the first entry for temperatures, humidity, wind
- speed etc. are values at 1:00 AM and not at midnight. Furthermore,
- the TMY3 weather data files can have values at midnight of December
- 31 that may be significantly different from the values at 1:00 AM on
- January 1. Since annual simulations require weather data that start
- at 0:00 on January 1, data need to be provided for this hour. Due to
- the possibly large change in weatherdata between 1:00 AM on January 1
- and midnight at December 31, the weather data files in the AixLib
- library do not use the data entry from midnight at December 31 as the
- value for t=0. Rather, the value from 1:00 AM on January 1 is
- duplicated and used for 0:00 on January 1. To maintain a data record
- with 8760 hours, the weather data record from midnight at
- December 31 is deleted. These changes in the weather data file are
- done in the Java program
- AixLib/Resources/bin/ConvertWeatherData.jar that
- converts EnergyPlus weather data file to Modelica weather data files,
- and which is described above. The length of the weather data is
- calculated as the end time stamp minus start time stamp plus average
- increment, where the average increment is equal to the end time stamp
- minus start time stamp divided by the number of rows minus 1. This
- only works correctly for weather files with equidistant time stamps.
+ Michael Wetter, Marcus Fuchs and Thierry Stephane Nouidui.
+
+ Design choices for thermofluid flow components and systems that are
+ exported as Functional Mockup Units.
+ Proc. of the 11th International Modelica Conference, p. 31-41,
+ Versailles, France, September 2015.
-
- Time shift for solar radiation data
-
+
+-------- Errors --------
+line 18 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+
+
+---- AixLib/Fluid/FMI/ExportContainers/ThermalZones.mo ----
+-------- HTML Code --------
+
+
+ Model that is used as a container for a multiple thermal zones
+ that are to be exported as an FMU.
+
+ Typical use and important parameters
+
+ To use this model as a container for an FMU, extend
+ from this model, rather than instantiate it,
+ add your thermal zones. For each thermal zone,
+ add a vector of mass flow rate sensors.
+ By extending from this model, the top-level
+ signal connectors on the left stay at the top-level, and hence
+ will be visible at the FMI interface.
+
+
+ Note that
+
+ -
+ A vector of mass flow rate sensors is used to connect
+ one element of the thermal zone adapter with one thermal zone.
+
+ -
+ The size of the thermal zone adapter must be the same as the number
+ of vectors of mass flow rate sensors.
+
+ -
+ The vector of mass flow rate sensors must have the size
nPorts.
+
+ -
+ All fluid ports of the mass flow rate sensor must be connected.
+
+ -
+ If mass flow rate sensors are not used, and your themal zone
+ has fluid ports which are autosized, then a direct connection between
+ an element of the thermal zone adpater
theZonAda and your thermal
+ zone will be rejected. The reason is because autosized fluid ports
+ can only be connected to vector of ports whose sizes are literal.
+
+
+
+
+ The example
+
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZones
+ shows how multiple simple thermal zones can be implemented and exported as
+ an FMU.
+
+
+
+
+ The conversion between the fluid ports and signal ports is done
+ in the thermal zone adapter theZonAda[nZon].
+ This adapter has a vector of fluid ports called ports[nPorts]
+ which needs to be connected to the air volume of the thermal zones.
+ At this port, air exchanged between the thermal zones, the HVAC system
+ and any infiltration flow paths.
+
+
+ This model has input signals fluPor[nZon, nPorts] which carry
+ the mass flow rate for each flow that is connected to ports[1:nPorts]
+ for the respective zone, together with its
+ temperature, water vapor mass fraction per total mass of the air (not per kg dry
+ air), and trace substances. These quantities are always as if the flow
+ enters the respective room, even if the flow is zero or negative.
+ If a medium has no moisture, e.g., if Medium.nXi=0, or
+ if it has no trace substances, e.g., if Medium.nC=0, then
+ the output signal for these properties are removed.
+ Thus, a thermal zone model that uses these signals to compute the
+ heat added by the HVAC system need to implement an equation such as
+
+
+ Qsen = max(0, ṁsup) cp (Tsup - Tair,zon),
+
+
+ where
+ Qsen is the sensible heat flow rate added to the thermal zone,
+ ṁsup is the supply air mass flow rate from
+ the port fluPor (which is negative if it is an exhaust),
+ cp is the specific heat capacity at constant pressure,
+ Tsup is the supply air temperature and
+ Tair,zon is the zone air temperature.
+ Note that without the max(·, ·), the energy
+ balance would be wrong.
+ For example,
+
+ the control volumes in
+
+ AixLib.Fluid.MixingVolumes
+ implement such a max(·, ·) function.
+
+
+ For each zone, its air temperature,
+ water vapor mass fraction per total mass of the air (unless Medium.nXi=0)
+ and trace substances (unless Medium.nC=0)
+ can be obtained from the outupt connector
+ fluPor[1:nZon].backward.
+ These signals are the same as the inflowing fluid stream(s)
+ at the port theAdaZon[1:nZon].ports[1:nPorts].
+ The fluid connector ports[nPorts] has a prescribed mass flow rate, but
+ it does not set any pressure.
+
+
+ This model has a user-defined parameter nPorts
+ which sets the number of fluid ports, which in turn is used
+ for the ports fluPor and ports.
+ All zones must have the same number of fluid ports nPorts.
+ All nPorts
+ ports[1:nPorts] need to be connected as demonstrated in the example
+
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZones.
+
+
+
+
+
+
+ -
+ January 18, 2019, by Jianjun Hu:
+ Limited the media choice to moist air.
+ See #1050.
+
+ -
+ September 20, 2016, by Thierry S. Nouidui:
+ Revised documentation to explain the rationale
+ of needing mass flow rate sensors.
+
+ -
+ June 29, 2016, by Michael Wetter:
+ Revised implementation and documentation.
+
+ -
+ April 27, 2016, by Thierry S. Nouidui:
+ First implementation.
+
+
+
+-------- Corrected Code --------
- To read weather data from the TMY3 weather data file, there are two
- data readers in this model. One data reader obtains all data except
- solar radiation, and the other data reader reads only the solar
- radiation data, shifted by 30 minutes. The reason for this
- time shift is as follows: The TMY3 weather data file contains for
- solar radiation the \"...radiation received on a horizontal surface
- during the 60-minute period ending at the timestamp.\" Thus, as the
- figure below shows, a more accurate interpolation is obtained if time
- is shifted by 30 minutes prior to reading the weather data.
-
-
-
+ Model that is used as a container for a multiple thermal zones that
+ are to be exported as an FMU.
- References
+ Typical use and important parameters
+
+ To use this model as a container for an FMU, extend from this model,
+ rather than instantiate it, add your thermal zones. For each thermal
+ zone, add a vector of mass flow rate sensors. By extending from this
+ model, the top-level signal connectors on the left stay at the
+ top-level, and hence will be visible at the FMI interface.
+ Note that
- - Wilcox S. and W. Marion. Users Manual for TMY3 Data Sets.
- Technical Report, NREL/TP-581-43156, revised May 2008.
-
-
-
- - September 6, 2021, by Ettore Zanetti:
- Changed alt and lat to real inputs.
- This is for IBPSA,
- #1477.
-
- - May 2, 2021, by Ettore Zanetti:
- Added altitude to parameters.
- This is for IBPSA,
- #1477.
-
- - October 4, 2020, by Ettore Zanetti:
- Updated documentation for Java weather file generator.
- This is for #1396.
-
- - August 20, 2019, by Filip Jorissen:
- Better clarified the meaning of time in the
- documentation.
- This is for #1192.
-
- - March 5, 2019, by Michael Wetter:
- Updated documentation.
- This is for #842.
-
- - September 20, 2018, by Michael Wetter:
- Corrected documentation.
- This is for #1022.
-
- - December 4, 2017, by Michael Wetter:
- Removed function call to getAbsolutePath, as this
- causes in Dymola 2018FD01 the error \"A call of loadResource with a
- non-literal string remains in the generated code; it will not work
- for an URI.\" when exporting
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZone as
- an FMU. Instead, if the weather file is specified as a Modelica,
- URI, syntax such as
- Modelica.Utilities.Files.loadResource(\"modelica://AixLib/Resources/weatherdata/USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.mos\")
- should be used.
- This is for #867.
-
- - February 18, 2017, by Filip Jorissen:
- Infrared radiation on horizontal surface is now delayed by 30
- minutes such that the results in
- TBlaSky are consistent. This is for #648.
-
- - December 06, 2016, by Thierry S. Nouidui:
- Constrained the direct normal radiation to not be bigger than the
- solar constant when using global and diffuse solar radiation data
- provided via the inputs connectors. This is for #608.
-
- - April 21, 2016, by Michael Wetter:
- Introduced absFilNam to avoid multiple calls to
-
- AixLib.BoundaryConditions.WeatherData.BaseClasses.getAbsolutePath.
- This is for Buildings,
- #506.
-
- - January 6, 2016, by Moritz Lauster:
- Changed output radHorIR to HHorIR. This
- is for #376.
-
- - January 4, 2016, by Moritz Lauster:
- Added a table in documentation with output variables accessible via
- weaBus. This is for #376.
-
- - December 15, 2015, by Michael Wetter:
- Added the block cheTemBlaSky. This also allows to
- graphically connect the black body sky temperature to the weather
- bus, which is required in Dymola 2016 for the variable
- weaBus.TBlaSky to appear in the graphical editor. This
- is for #377.
-
- - September 24, 2015, by Marcus Fuchs:
- Replace Dymola specific annotation by loadSelector for
- MSL compliancy as reported by @tbeu at RWTH-EBC/AixLib#107
-
- - June 6, 2015, by Michael Wetter:
- Removed redundant but consistent connect(TBlaSkyCom.TBlaSky,
- weaBus.TBlaSky) statement. This avoids a warning if
- AixLib.BoundaryConditions.SolarIrradiation.BaseClasses.Examples.SkyClearness
- is translated in pedantic mode in Dymola 2016. This is for #266.
-
- - March 26, 2015, by Michael Wetter:
- Added option to obtain the black body sky temperature from a
- parameter or an input signal.
-
- - October 17, 2014, by Michael Wetter:
- Corrected error that led the total and opaque sky cover to be ten
- times too low if its value was obtained from the parameter or the
- input connector. For the standard configuration in which the sky
- cover is obtained from the weather data file, the model was
- correct. This error only affected the other two possible
- configurations.
-
- - September 12, 2014, by Michael Wetter:
- Removed redundant connection connect(conHorRad.HOut,
- cheHorRad.HIn);.
-
- - May 30, 2014, by Michael Wetter:
- Removed undesirable annotation Evaluate=true.
-
- - May 5, 2013, by Thierry S. Nouidui:
- Added the option to use a constant, an input signal or the weather
- file as the source for the ceiling height, the total sky cover, the
- opaque sky cover, the dew point temperature, and the infrared
- horizontal radiation HInfHor.
-
- - October 8, 2013, by Michael Wetter:
- Improved the algorithm that determines the absolute path of the
- file. Now weather files are searched in the path specified, and if
- not found, the urls file://, modelica://
- and modelica://AixLib are added in this order to
- search for the weather file. This allows using the data reader
- without having to specify an absolute path, as long as the
- AixLib library is on the MODELICAPATH.
- This change was implemented in
- AixLib.BoundaryConditions.WeatherData.BaseClasses.getAbsolutePath
- and improves this weather data reader.
-
- - May 2, 2013, by Michael Wetter:
- Added function call to getAbsolutePath.
+ - A vector of mass flow rate sensors is used to connect one element
+ of the thermal zone adapter with one thermal zone.
- - October 16, 2012, by Michael Wetter:
- Added computation of the wet bulb temperature. Computing the wet
- bulb temperature introduces a nonlinear equation. As we have not
- observed an increase in computing time because of computing the wet
- bulb temperature, it is computed by default. By setting the
- parameter computeWetBulbTemperature=false, the
- computation of the wet bulb temperature can be removed. Revised
- documentation.
+ - The size of the thermal zone adapter must be the same as the
+ number of vectors of mass flow rate sensors.
- - August 11, 2012, by Wangda Zuo:
- Renamed radHor to radHorIR and improved
- the optional inputs for radiation data.
+ - The vector of mass flow rate sensors must have the size
+
nPorts.
- - July 24, 2012, by Wangda Zuo:
- Corrected the notes of SI unit requirements for input files.
+ - All fluid ports of the mass flow rate sensor must be connected.
- - July 13, 2012, by Michael Wetter:
- Removed assignment of HGloHor_in in its declaration,
- because this gives an overdetermined system if the input connector
- is used. Removed non-required assignments of attribute
- displayUnit.
+ - If mass flow rate sensors are not used, and your themal zone has
+ fluid ports which are autosized, then a direct connection between an
+ element of the thermal zone adpater
theZonAda and your
+ thermal zone will be rejected. The reason is because autosized fluid
+ ports can only be connected to vector of ports whose sizes are
+ literal.
- - February 25, 2012, by Michael Wetter:
- Added subbus for solar position, which is needed by irradition and
- shading model.
+
+
+ The example
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZones
+ shows how multiple simple thermal zones can be implemented and
+ exported as an FMU.
+
+
+ The conversion between the fluid ports and signal ports is done in
+ the thermal zone adapter theZonAda[nZon]. This adapter
+ has a vector of fluid ports called ports[nPorts] which
+ needs to be connected to the air volume of the thermal zones. At this
+ port, air exchanged between the thermal zones, the HVAC system and
+ any infiltration flow paths.
+
+
+ This model has input signals fluPor[nZon, nPorts] which
+ carry the mass flow rate for each flow that is connected to
+ ports[1:nPorts] for the respective zone, together with
+ its temperature, water vapor mass fraction per total mass of the air
+ (not per kg dry air), and trace substances. These quantities are
+ always as if the flow enters the respective room, even if the flow is
+ zero or negative. If a medium has no moisture, e.g., if
+ Medium.nXi=0, or if it has no trace substances, e.g., if
+ Medium.nC=0, then the output signal for these properties
+ are removed. Thus, a thermal zone model that uses these signals to
+ compute the heat added by the HVAC system need to implement an
+ equation such as
+
+
+ Qsen = max(0, ṁsup) cp
+ (Tsup - Tair,zon),
+
+
+ where Qsen is the sensible heat flow rate added to
+ the thermal zone, ṁsup is the supply air mass flow
+ rate from the port fluPor (which is negative if it is an
+ exhaust), cp is the specific heat capacity at
+ constant pressure, Tsup is the supply air
+ temperature and Tair,zon is the zone air
+ temperature. Note that without the max(·, ·), the energy
+ balance would be wrong. For example,
+ the control volumes in AixLib.Fluid.MixingVolumes
+ implement such a max(·, ·) function.
+
+
+ For each zone, its air temperature, water vapor mass fraction per
+ total mass of the air (unless Medium.nXi=0) and trace
+ substances (unless Medium.nC=0) can be obtained from the
+ outupt connector fluPor[1:nZon].backward. These signals
+ are the same as the inflowing fluid stream(s) at the port
+ theAdaZon[1:nZon].ports[1:nPorts]. The fluid connector
+ ports[nPorts] has a prescribed mass flow rate, but it
+ does not set any pressure.
+
+
+ This model has a user-defined parameter nPorts which
+ sets the number of fluid ports, which in turn is used for the ports
+ fluPor and ports. All zones must have the
+ same number of fluid ports nPorts. All
+ nPorts ports[1:nPorts] need to be connected
+ as demonstrated in the example
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZones.
+
+
+
+
+
+ - January 18, 2019, by Jianjun Hu:
+ Limited the media choice to moist air. See #1050.
- - November 29, 2011, by Michael Wetter:
- Fixed wrong display unit for pAtm_in_internal and made
- propagation of parameter final.
+ - September 20, 2016, by Thierry S. Nouidui:
+ Revised documentation to explain the rationale of needing mass flow
+ rate sensors.
- - October 27, 2011, by Wangda Zuo:
-
- - Added optional connectors for dry bulb temperature, relative
- humidity, wind speed, wind direction, global horizontal
- radiation, diffuse horizontal radiation.
-
- - Separate the unit conversion for TMY3 data and data validity
- check.
-
-
+ - June 29, 2016, by Michael Wetter:
+ Revised implementation and documentation.
- - October 3, 2011, by Michael Wetter:
- Propagated value for sky temperature calculation to make it
- accessible as a parameter.
+ - April 27, 2016, by Thierry S. Nouidui:
+ First implementation.
- - July 20, 2011, by Michael Wetter:
- Added the option to use a constant, an input signal or the weather
- file as the source for the atmospheric pressure.
+
+
+-------- Errors --------
+line 78 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/ThermalZones/ReducedOrder/RC/TwoElements.mo ----
+-------- HTML Code --------
+
+
+ -
+ March 7, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for
+ #1542.
+
+ -
+ July 11, 2019, by Katharina Brinkmann:
+ Renamed alphaInt to hConInt,
+ alphaIntWall to hConIntWall
+
+ -
+ January 25, 2019, by Michael Wetter:
+ Added start value to avoid warning in JModelica.
+
+ -
+ April 18, 2015, by Moritz Lauster:
+ First implementation.
+
+
+
+ This model distinguishes between internal
+ thermal masses and exterior walls. While exterior walls contribute to heat
+ transfer to the ambient, adiabatic conditions apply to internal masses.
+ Parameters for the internal wall element are the length of the RC-chain
+ nInt, the vector of the capacities
+ CInt[nInt] and the vector of the resistances RInt[nInt].
+ This approach allows considering the dynamic behaviour induced by internal
+ heat storage.
+
+
+ The image below shows the RC-network of this model.
+
+
+ ![\"image\"/](\"modelica://AixLib/Resources/Images/ThermalZones/ReducedOrder/RC/TwoElements.png\")
+
+
+-------- Corrected Code --------
+
+ - March 7, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for #1542.
- - March 15, 2011, by Wangda Zuo:
- Delete the wet bulb temperature since it may cause numerical
- problem.
+ - July 11, 2019, by Katharina Brinkmann:
+ Renamed alphaInt to hConInt,
+ alphaIntWall to hConIntWall
- - March 7, 2011, by Wangda Zuo:
- Added wet bulb temperature. Changed reader to read only needed
- columns. Added explanation for 30 minutes shift for radiation data.
+ - January 25, 2019, by Michael Wetter:
+ Added start value to avoid warning in JModelica.
- - March 5, 2011, by Michael Wetter:
- Changed implementation to obtain longitude and time zone directly
- from weather file.
+ - April 18, 2015, by Moritz Lauster:
+ First implementation.
+
+
+
+ This model distinguishes between internal thermal masses and exterior
+ walls. While exterior walls contribute to heat transfer to the
+ ambient, adiabatic conditions apply to internal masses. Parameters
+ for the internal wall element are the length of the RC-chain
+ nInt, the vector of the capacities
+ CInt[nInt] and the vector of the resistances
+ RInt[nInt]. This approach allows considering the dynamic
+ behaviour induced by internal heat storage.
+
+
+ The image below shows the RC-network of this model.
+
+
+
+
+
+-------- Errors --------
+line 14 column 4 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Utilities/Math/Polynomial.mo ----
+-------- HTML Code --------
+
+ This block computes a polynomial of arbitrary order. The polynomial has the form
+ y = a1 + a2 x + a3 x2 + ...
+
+
+ -
+ September 21, 2021, by Michael Wetter:
+ Renamed class to correct typo in class name.
+ This is for
+ IBPSA, #1524.
+
+ -
+ November 28, 2013, by Marcus Fuchs:
+ First implementation.
+
+
+
+-------- Corrected Code --------
+
+ This block computes a polynomial of arbitrary order. The polynomial
+ has the form
+
+
+ y = a1 + a2 x + a3 x2 + ...
+
+
+ - September 21, 2021, by Michael Wetter:
+ Renamed class to correct typo in class name.
+ This is for IBPSA,
+ #1524.
- - June 25, 2010, by Wangda Zuo:
+ - November 28, 2013, by Marcus Fuchs:
First implementation.
-------- Errors --------
-line 24 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 425 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 469 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 640 column 2 - Warning: attribute "align" not allowed for HTML5
+line 3 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/BaseClasses/FlowModels/basicFlowFunction_dp.mo ----
+---- AixLib/Fluid/Humidifiers/SprayAirWasher_X.mo ----
-------- HTML Code --------
- Function that computes the pressure drop of flow elements as
+ Model for a spray air washer with a prescribed outlet water vapor mass fraction
+ in kg/kg total air.
-
- m = sign(Δp) k √ Δp
+
+ This model forces the outlet water mass fraction at port_b to be
+ no lower than the
+ input signal X_wSet, subject to optional limits on the
+ maximum water vapor mass flow rate that is added, as
+ described by the parameter mWatMax_flow.
+ By default, the model has unlimited capacity.
- with regularization near the origin.
- Therefore, the flow coefficient is
+ The output signal mWat_flow ≥ 0 is the moisture added
+ to the medium if the flow rate is from port_a to port_b.
+ If the flow is reversed, then mWat_flow = 0.
+ The outlet specific enthalpy at port_b is increased by
+ the enthalpy of liquid water at 10°C times the mass of water that was added.
+ Therefore, the temperature of the leaving fluid is below the inlet temperature.
+
+
+ The outlet conditions at port_a are not affected by this model,
+ other than for a possible pressure difference due to flow friction.
+
+
+ If the parameter energyDynamics is different from
+ Modelica.Fluid.Types.Dynamics.SteadyState,
+ the component models the dynamic response using a first order differential equation.
+ The time constant of the component is equal to the parameter tau.
+ This time constant is adjusted based on the mass flow rate using
- k = m ⁄ √ Δp
+ τeff = τ |ṁ| ⁄ ṁnom
- The input m_flow_turbulent determines the location of the regularization.
+ where
+ τeff is the effective time constant for the given mass flow rate
+ ṁ and
+ τ is the time constant at the nominal mass flow rate
+ ṁnom.
+ This type of dynamics is equal to the dynamics that a completely mixed
+ control volume would have.
+
+
+ Optionally, this model can have a flow resistance.
+ Set dp_nominal = 0 to disable the flow friction calculation.
+
+
+ For a model that uses a control signal u ∈ [0, 1] and multiplies
+ this with the nominal water mass flow rate, use
+
+ AixLib.Fluid.Humidifiers.Humidifier_u
+
+
+ Limitations
+
+ This model only adds water vapor for the flow from
+ port_a to port_b.
+ The water vapor of the reverse flow is not affected by this model.
+
+
+ This model does not affect the enthalpy of the air. Therefore,
+ if water is added, the temperature will decrease, e.g., the humidification
+ is adiabatic.
-
- November 9, 2019, by Filip Jorissen:
- Added smooth(2, . ) for avoiding
- a warning in the check valve model.
- See #1240.
-
- -
- January 4, 2019, by Michael Wetter:
- Set `Inline=false`.
- See #1070.
-
- -
- May 1, 2017, by Filip Jorissen:
- Revised implementation such that
- basicFlowFunction_dp
- is C2 continuous.
- See #725.
-
- -
- March 19, 2016, by Michael Wetter:
- Added abs function for
- AixLib.Fluid.FixedResistances.Validation.PressureDropsExplicit
- to work in OpenModelica.
- See
- OpenModelica ticket 3778.
-
- -
- January 22, 2016, by Michael Wetter:
- Corrected type declaration of pressure difference.
- This is
- for #404.
-
- -
- July 28, 2015, by Michael Wetter:
- Removed double declaration of smooth(..) and smoothOrder
- and changed Inline=true to LateInline=true.
- This is for
- issue 301.
+ March 8, 2022, by Michael Wetter:
+ Renamed parameter massDynamics to energyDynamics for consistency with other models.
-
- July 15, 2015, by Filip Jorissen:
- New, more efficient implementation based on regularisation using simple polynomial.
- Expanded common subexpressions for function inlining to be possible.
- Set Inline=true for inlining to occur.
+ December 14, 2018, by Michael Wetter:
+ Restricted base class for medium to one that implements
+ the function enthalpyOfLiquid.
This is for
- #279.
-
- -
- January 9, 2014, by Michael Wetter:
- Correct revision section, of which there were two.
-
- -
- August 10, 2011, by Michael Wetter:
- Removed if-then optimization that set m_flow=0 if dp=0,
- as this causes the derivative to be discontinuous at dp=0.
-
- -
- August 4, 2011, by Michael Wetter:
- Removed option to use a linear function. The linear implementation is now done
- in models that call this function. With the previous implementation,
- the symbolic processor may not rearrange the equations, which can lead
- to coupled equations instead of an explicit solution.
-
- -
- March 29, 2010 by Michael Wetter:
- Changed implementation to allow k=0, which is
- the case for a closed valve with no leakage
+ #1057.
-
- April 13, 2009, by Michael Wetter:
+ May 3, 2017, by Michael Wetter:
First implementation.
-------- Corrected Code --------
- Function that computes the pressure drop of flow elements as
+ Model for a spray air washer with a prescribed outlet water vapor
+ mass fraction in kg/kg total air.
-
- m = sign(Δp) k √ Δp
-
+
+ This model forces the outlet water mass fraction at
+ port_b to be no lower than the input signal
+ X_wSet, subject to optional limits on the maximum water
+ vapor mass flow rate that is added, as described by the parameter
+ mWatMax_flow. By default, the model has unlimited
+ capacity.
- with regularization near the origin. Therefore, the flow coefficient
- is
+ The output signal mWat_flow ≥ 0 is the moisture added to
+ the medium if the flow rate is from port_a to
+ port_b. If the flow is reversed, then mWat_flow =
+ 0. The outlet specific enthalpy at port_b is
+ increased by the enthalpy of liquid water at 10°C times the
+ mass of water that was added. Therefore, the temperature of the
+ leaving fluid is below the inlet temperature.
-
- k = m ⁄ √ Δp
-
+
+ The outlet conditions at port_a are not affected by this
+ model, other than for a possible pressure difference due to flow
+ friction.
- The input m_flow_turbulent determines the location of
- the regularization.
+ If the parameter energyDynamics is different from
+ Modelica.Fluid.Types.Dynamics.SteadyState, the component
+ models the dynamic response using a first order differential
+ equation. The time constant of the component is equal to the
+ parameter tau. This time constant is adjusted based on
+ the mass flow rate using
-
- - November 9, 2019, by Filip Jorissen:
- Added smooth(2, . ) for avoiding a warning in the
- check valve model.
- See #1240.
-
- - January 4, 2019, by Michael Wetter:
- Set `Inline=false`.
- See #1070.
-
- - May 1, 2017, by Filip Jorissen:
- Revised implementation such that
- basicFlowFunction_dp is C2 continuous. See #725.
-
- - March 19, 2016, by Michael Wetter:
- Added abs function for
- AixLib.Fluid.FixedResistances.Validation.PressureDropsExplicit
- to work in OpenModelica. See OpenModelica
- ticket 3778.
-
- - January 22, 2016, by Michael Wetter:
- Corrected type declaration of pressure difference. This is for
- #404.
-
- - July 28, 2015, by Michael Wetter:
- Removed double declaration of smooth(..) and
- smoothOrder and changed Inline=true to
- LateInline=true. This is for issue 301.
-
- - July 15, 2015, by Filip Jorissen:
- New, more efficient implementation based on regularisation using
- simple polynomial. Expanded common subexpressions for function
- inlining to be possible. Set Inline=true for inlining
- to occur. This is for #279.
-
- - January 9, 2014, by Michael Wetter:
- Correct revision section, of which there were two.
-
- - August 10, 2011, by Michael Wetter:
- Removed if-then optimization that set
- m_flow=0 if dp=0, as this causes the
- derivative to be discontinuous at dp=0.
-
- - August 4, 2011, by Michael Wetter:
- Removed option to use a linear function. The linear implementation
- is now done in models that call this function. With the previous
- implementation, the symbolic processor may not rearrange the
- equations, which can lead to coupled equations instead of an
- explicit solution.
+
+ τeff = τ |ṁ| ⁄ ṁnom
+
+
+ where τeff is the effective time constant for the
+ given mass flow rate ṁ and τ is the time constant at
+ the nominal mass flow rate ṁnom. This type of
+ dynamics is equal to the dynamics that a completely mixed control
+ volume would have.
+
+
+ Optionally, this model can have a flow resistance. Set
+ dp_nominal = 0 to disable the flow friction calculation.
+
+
+ For a model that uses a control signal u ∈ [0, 1] and
+ multiplies this with the nominal water mass flow rate, use AixLib.Fluid.Humidifiers.Humidifier_u
+
+
+ Limitations
+
+
+ This model only adds water vapor for the flow from
+ port_a to port_b. The water vapor of the
+ reverse flow is not affected by this model.
+
+
+ This model does not affect the enthalpy of the air. Therefore, if
+ water is added, the temperature will decrease, e.g., the
+ humidification is adiabatic.
+
+
+ - March 8, 2022, by Michael Wetter:
+ Renamed parameter massDynamics to
+ energyDynamics for consistency with other models.
- - March 29, 2010 by Michael Wetter:
- Changed implementation to allow k=0, which is the case
- for a closed valve with no leakage
+ - December 14, 2018, by Michael Wetter:
+ Restricted base class for medium to one that implements the
+ function enthalpyOfLiquid.
+ This is for #1057.
- - April 13, 2009, by Michael Wetter:
+ - May 3, 2017, by Michael Wetter:
First implementation.
-------- Errors --------
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
-line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+line 33 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Types.mo ----
+---- AixLib/Fluid/Movers/BaseClasses/Characteristics/pressure.mo ----
-------- HTML Code --------
-
-
- Enumeration to define the choice of valve flow coefficient
- (to be selected via choices menu):
-
-
-
- | Enumeration |
- Description |
|---|
-
- | OpPoint |
- flow coefficient defined by ratio m_flow_nominal/sqrt(dp_nominal) |
-
- | Kv |
- Kv (metric) flow coefficient |
-
- | Cv |
- Cv (US) flow coefficient |
-
- | Av |
- Av (metric) flow coefficient |
-
-
-
-
- The details of the coefficients are explained in the
-
- Users Guide.
-
-
-
- Enumeration that defines the heat exchanger construction.
+ This function computes the fan static
+ pressure raise as a function of volume flow rate and revolution in the form
-
- The following heat exchanger configurations are available in this enumeration:
+
+ Δp = rN2 s(V̇/rN, d),
-
- | Enumeration | Description |
|---|
- | ParallelFlow | Parallel flow |
- | CounterFlow | Counter flow |
- | CrossFlowUnmixed | Cross flow, both streams unmixed |
- | CrossFlowStream1MixedStream2Unmixed | Cross flow, stream 1 mixed, stream 2 unmixed |
- | CrossFlowStream1UnmixedStream2Mixed | Cross flow, stream 1 unmixed, stream 2 mixed |
- | ConstantTemperaturePhaseChange | Constant temperature phase change in one stream |
-
-
- Note that for a given heat exchanger, the
- HeatExchangerConfiguration is fixed. However, if the capacity
- flow rates change, then the
-
- AixLib.Fluid.Types.HeatExchangerFlowRegime may change. For example,
- a counter flow heat exchanger has HeatExchangerConfiguration=CounterFlow,
- but the
- AixLib.Fluid.Types.HeatExchangerFlowRegime can change to parallel flow if one of the two capacity flow rates reverts
- its direction.
-
-
-
- -
- March 27, 2017, by Michael Wetter:
- Added ConstantTemperaturePhaseChange.
- This is for
-
- AixLib #694.
-
- -
- February 18, 2009, by Michael Wetter:
- First implementation.
-
-
-
- Enumeration to define the heat exchanger flow regime.
+ where
+ Δp is the pressure rise,
+ rN is the normalized fan speed,
+ V̇ is the volume flow rate and
+ d are performance data for fan or pump power consumption at rN=1.
+ Implementation
- This enumeration defines for the current capacity flow rate the kind of
- heat transfer relation that will be used to compute the relation between
- effectiveness and Number of Transfer Units.
+ The function s(·, ·) is a cubic hermite spline.
+ If the data d define a monotone decreasing sequence, then
+ s(·, d) is a monotone decreasing function.
- The following heat exchanger flow regimes are available in this enumeration:
+ The function allows rN to be zero.
-
- | Enumeration | Description |
|---|
- | ParallelFlow | Parallel flow |
- | CounterFlow | Counter flow |
- | CrossFlowUnmixed | Cross flow, both streams unmixed |
- | CrossFlowCMinMixedCMaxUnmixed | Cross flow, CMin mixed, CMax unmixed |
- | CrossFlowCMinUnmixedCMaxMixed | Cross flow, CMin unmixed, CMax mixed |
- | ConstantTemperaturePhaseChange | Constant temperature phase change in one stream |
-
-
- March 27, 2017, by Michael Wetter:
- Added ConstantTemperaturePhaseChange.
- This is for
-
- AixLib #694.
-
- -
- February 18, 2009, by Michael Wetter:
- First implementation.
-
-
-
-
- This type allows defining which type of input should be used for movers.
- This can either be
-
-
- -
- a constant set point declared by a parameter,
-
- -
- a series of possible set points that can be switched using an integer input, or
-
- -
- a continuously variable set point.
+ September 8, 2016, by Michael Wetter and Filip Jorissen:
+ Changed implementation to allow r_N = 0.
+ This is
+ for #458.
-
-
-
-
- This package contains type definitions.
-
-
-------- Corrected Code --------
- Enumeration to define the choice of valve flow coefficient (to be
- selected via choices menu):
+ This function computes the fan static pressure raise as a function of
+ volume flow rate and revolution in the form
-
-
- |
- Enumeration
- |
-
- Description
- |
-
-
- |
- OpPoint
- |
-
- flow coefficient defined by ratio m_flow_nominal/sqrt(dp_nominal)
- |
-
-
- |
- Kv
- |
-
- Kv (metric) flow coefficient
- |
-
-
- |
- Cv
- |
-
- Cv (US) flow coefficient
- |
-
-
- |
- Av
- |
-
- Av (metric) flow coefficient
- |
-
-
-
- The details of the coefficients are explained in the
- Users Guide.
+
+ Δp = rN2 s(V̇/rN, d),
- Enumeration that defines the heat exchanger construction.
+ where Δp is the pressure rise, rN is the
+ normalized fan speed, V̇ is the volume flow rate and d
+ are performance data for fan or pump power consumption at
+ rN=1.
+
+ Implementation
+
- The following heat exchanger configurations are available in this
- enumeration:
+ The function s(·, ·) is a cubic hermite spline. If the data
+ d define a monotone decreasing sequence, then s(·, d)
+ is a monotone decreasing function.
-
-
- |
- Enumeration
- |
-
- Description
- |
-
-
- |
- ParallelFlow
- |
-
- Parallel flow
- |
-
-
- |
- CounterFlow
- |
-
- Counter flow
- |
-
-
- |
- CrossFlowUnmixed
- |
-
- Cross flow, both streams unmixed
- |
-
-
- |
- CrossFlowStream1MixedStream2Unmixed
- |
-
- Cross flow, stream 1 mixed, stream 2 unmixed
- |
-
-
- |
- CrossFlowStream1UnmixedStream2Mixed
- |
-
- Cross flow, stream 1 unmixed, stream 2 mixed
- |
-
-
- |
- ConstantTemperaturePhaseChange
- |
-
- Constant temperature phase change in one stream
- |
-
-
- Note that for a given heat exchanger, the
- HeatExchangerConfiguration is fixed. However, if the
- capacity flow rates change, then the AixLib.Fluid.Types.HeatExchangerFlowRegime
- may change. For example, a counter flow heat exchanger has
- HeatExchangerConfiguration=CounterFlow, but the AixLib.Fluid.Types.HeatExchangerFlowRegime
- can change to parallel flow if one of the two capacity flow rates
- reverts its direction.
+ The function allows rN to be zero.
- - March 27, 2017, by Michael Wetter:
- Added ConstantTemperaturePhaseChange.
+ - September 8, 2016, by Michael Wetter and Filip Jorissen:
+ Changed implementation to allow r_N = 0.
This is for AixLib
- #694.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/458\">#458.
- - February 18, 2009, by Michael Wetter:
+ - September 7, 2016, by Michael Wetter:
+ Moved function which was a protected function to make it public, as
+ it is now called by AixLib.Fluid.Movers.BaseClasses.FlowMachineInterface.
+
+
+
+-------- Errors --------
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/BoundaryConditions/Validation/BESTEST/WD300.mo ----
+-------- HTML Code --------
+
+
+ -
+ September 6, 2021, by Ettore Zanetti:
+ Removed parameter lat as it is now obtained from the weather data bus.
+ This is for
+ IBPSA, #1477.
+
+ -
+ March 11, 2020, by Ettore Zanetti:
+ First implementation.
+
+ -
+ April 14, 2020, by Ettore Zanetti:
+ Rework after comments from pull request
+ #1339.
+
+ -
+ May 2, 2021, by Ettore Zanetti:
+ Updated weather file as explained in #1478.
+
+
+
+ WD300: Southern Hemisphere Case
+ Weather data file : WD300.epw
+ Table 1: Site Data for Weather file WD300.epw
+
+ Latitude |
+ 33.393° south |
+
+
+ Longitude |
+ 70.786° west |
+
+
+ Altitude |
+ 474 m |
+
+
+ Time Zone |
+ -4 |
+
+
+
+-------- Corrected Code --------
+
+ - September 6, 2021, by Ettore Zanetti:
+ Removed parameter lat as it is now obtained from the
+ weather data bus.
+ This is for IBPSA,
+ #1477.
+
+ - March 11, 2020, by Ettore Zanetti:
First implementation.
+ - April 14, 2020, by Ettore Zanetti:
+ Rework after comments from pull request #1339.
+
+ - May 2, 2021, by Ettore Zanetti:
+ Updated weather file as explained in #1478.
+
+
+ WD300: Southern Hemisphere Case
+
- Enumeration to define the heat exchanger flow regime.
-
-
- This enumeration defines for the current capacity flow rate the kind
- of heat transfer relation that will be used to compute the relation
- between effectiveness and Number of Transfer Units.
+ Weather data file : WD300.epw
- The following heat exchanger flow regimes are available in this
- enumeration:
+ Table 1: Site Data for Weather file WD300.epw
-
-
- |
- Enumeration
- |
-
- Description
- |
-
-
- |
- ParallelFlow
- |
-
- Parallel flow
- |
-
-
- |
- CounterFlow
- |
-
- Counter flow
- |
-
-
- |
- CrossFlowUnmixed
- |
-
- Cross flow, both streams unmixed
- |
-
-
- |
- CrossFlowCMinMixedCMaxUnmixed
- |
-
- Cross flow, CMin mixed, CMax unmixed
- |
-
+
|
- CrossFlowCMinUnmixedCMaxMixed
+
+ Latitude
+
|
- Cross flow, CMin unmixed, CMax mixed
+
+ 33.393° south
+
|
|
- ConstantTemperaturePhaseChange
+
+ Longitude
+
|
- Constant temperature phase change in one stream
- |
-
-
-
- - March 27, 2017, by Michael Wetter:
- Added ConstantTemperaturePhaseChange.
- This is for AixLib
- #694.
-
- - February 18, 2009, by Michael Wetter:
- First implementation.
-
-
-
- This type allows defining which type of input should be used for
- movers. This can either be
-
-
- - a constant set point declared by a parameter,
-
- - a series of possible set points that can be switched using an
- integer input, or
-
- - a continuously variable set point.
-
-
-
- - April 2, 2015, by Filip Jorissen:
- First implementation.
-
-
-
- This package contains type definitions.
-
+
+ 70.786° west
+
+
+
+
+ |
+
+ Altitude
+
+ |
+
+
+ 474 m
+
+ |
+
+
+ |
+
+ Time Zone
+
+ |
+
+
+ -4
+
+ |
+
+
-------- Errors --------
-line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-
-
-line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-
-
-line 13 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/PlugFlowAIT.mo ----
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/gFunction.mo ----
-------- HTML Code --------
- The example contains
- experimental data from a real district heating network.
+ This function implements the g-function evaluation method introduced by
+ Cimmino and Bernier (see: Cimmino and Bernier (2014), and Cimmino (2018)) based
+ on the g-function function concept first introduced by Eskilson (1987).
+ The g-function gives the relation between the variation of the borehole
+ wall temperature at a time t and the heat extraction and injection rates
+ at all times preceding time t as
- The pipes' temperatures are not initialized. Therefore, results of
- outflow temperature before approximately the first 10000 seconds should not be
- considered.
+
+
- Note that these three models are identical, except for the pipe model that is used:
+ where Tb is the borehole wall temperature,
+ Tg is the undisturbed ground temperature, Q is the
+ heat injection rate into the ground through the borehole wall per unit borehole
+ length, ks is the soil thermal conductivity and g is
+ the g-function.
-
- This comparison between different discretization levels and pipe models is made
- to check the influence of the discretization and pipe model on computation time
- and simulation accuracy.
+ The g-function is constructed from the combination of the combination of
+ the finite line source (FLS) solution (see
+
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.finiteLineSource),
+ the cylindrical heat source (CHS) solution (see
+
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.cylindricalHeatSource),
+ and the infinite line source (ILS) solution (see
+
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.infiniteLineSource).
+ To obtain the g-function of a bore field, each borehole is divided into a
+ series of nSeg segments of equal length, each modeled as a line
+ source of finite length. The finite line source solution is superimposed in
+ space to obtain a system of equations that gives the relation between the heat
+ injection rate at each of the segments and the borehole wall temperature at each
+ of the segments. The system is solved to obtain the uniform borehole wall
+ temperature required at any time to maintain a constant total heat injection
+ rate (Qtot = 2πksHtot) into the bore
+ field. The uniform borehole wall temperature is then equal to the finite line
+ source based g-function.
- Test bench schematic
-
+
+ Since this g-function is based on line sources of heat, rather than
+ cylinders, the g-function is corrected to consider the cylindrical
+ geometry. The correction factor is then the difference between the cylindrical
+ heat source solution and the infinite line source solution, as proposed by
+ Li et al. (2014) as
- Calibration
- To calculate the length specific thermal resistance R of the pipe,
- the thermal resistance of the surrounding ground is added, which yields
-
- R=1/(0.208)+1/(2 lambda_g Modelica.Constants.pi) log(1/0.18),
- where the thermal conductivity of the ground lambda_g = 2.4 W/(m K).
+
+ g(t) = gFLS + (gCHS - gILS)
+
+ Implementation
+
+ The calculation of the g-function is separated into two regions: the
+ short-time region and the long-time region. In the short-time region,
+ corresponding to times t < 1 hour, heat interaction between boreholes
+ and axial variations of heat injection rate are not considered. The
+ g-function is calculated using only one borehole and one segment. In the
+ long-time region, corresponding to times t > 1 hour, all boreholes
+ are represented as series of nSeg line segments and the
+ g-function is evaluated as described above.
+
+ References
+
+ Cimmino, M. and Bernier, M. 2014. A semi-analytical method to generate
+ g-functions for geothermal bore fields. International Journal of Heat and
+ Mass Transfer 70: 641-650.
+
+
+ Cimmino, M. 2018. Fast calculation of the g-functions of geothermal borehole
+ fields using similarities in the evaluation of the finite line source
+ solution. Journal of Building Performance Simulation. DOI:
+ 10.1080/19401493.2017.1423390.
+
+
+ Eskilson, P. 1987. Thermal analysis of heat extraction boreholes. Ph.D.
+ Thesis. Department of Mathematical Physics. University of Lund. Sweden.
+
+
+ Li, M., Li, P., Chan, V. and Lai, A.C.K. 2014. Full-scale temperature
+ response function (G-function) for heat transfer by borehole heat exchangers
+ (GHEs) from sub-hour to decades. Applied Energy 136: 197-205.
-
- March 7, 2020, by Michael Wetter:
- Replaced measured data from specification in Modelica file to external table,
- as this reduces the computing time.
- This is for
- #1289.
-
- -
- May 15, 2019, by Jianjun Hu:
- Replaced fluid source. This is for
- #1072.
-
- - July 4, 2016 by Bram van der Heijde:
Added parameters to test the
- influence of allowFlowReversal and the presence of explicit volumes in the pipe.
+ March 22, 2018 by Massimo Cimmino:
+ First implementation.
- - January 26, 2016 by Carles Ribas:
First implementation.
-------- Corrected Code --------
- The example contains experimental data from a real district heating
- network.
+ This function implements the g-function evaluation method
+ introduced by Cimmino and Bernier (see: Cimmino and Bernier (2014),
+ and Cimmino (2018)) based on the g-function function concept
+ first introduced by Eskilson (1987). The g-function gives the
+ relation between the variation of the borehole wall temperature at a
+ time t and the heat extraction and injection rates at all
+ times preceding time t as
+
+
+
- The pipes' temperatures are not initialized. Therefore, results of
- outflow temperature before approximately the first 10000 seconds
- should not be considered.
+ where Tb is the borehole wall temperature,
+ Tg is the undisturbed ground temperature, Q
+ is the heat injection rate into the ground through the borehole wall
+ per unit borehole length, ks is the soil thermal
+ conductivity and g is the g-function.
- Note that these three models are identical, except for the pipe model
- that is used:
+ The g-function is constructed from the combination of the
+ combination of the finite line source (FLS) solution (see
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.finiteLineSource),
+ the cylindrical heat source (CHS) solution (see
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.cylindricalHeatSource),
+ and the infinite line source (ILS) solution (see
+ AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.ThermalResponseFactors.infiniteLineSource).
+ To obtain the g-function of a bore field, each borehole is
+ divided into a series of nSeg segments of equal length,
+ each modeled as a line source of finite length. The finite line
+ source solution is superimposed in space to obtain a system of
+ equations that gives the relation between the heat injection rate at
+ each of the segments and the borehole wall temperature at each of the
+ segments. The system is solved to obtain the uniform borehole wall
+ temperature required at any time to maintain a constant total heat
+ injection rate (Qtot =
+ 2πksHtot) into the bore field. The uniform
+ borehole wall temperature is then equal to the finite line source
+ based g-function.
-
- This comparison between different discretization levels and pipe
- models is made to check the influence of the discretization and pipe
- model on computation time and simulation accuracy.
+ Since this g-function is based on line sources of heat, rather
+ than cylinders, the g-function is corrected to consider the
+ cylindrical geometry. The correction factor is then the difference
+ between the cylindrical heat source solution and the infinite line
+ source solution, as proposed by Li et al. (2014) as
+
+
+ g(t) = gFLS + (gCHS - gILS)
- Test bench schematic
+ Implementation
-
+ The calculation of the g-function is separated into two
+ regions: the short-time region and the long-time region. In the
+ short-time region, corresponding to times t < 1 hour, heat
+ interaction between boreholes and axial variations of heat injection
+ rate are not considered. The g-function is calculated using
+ only one borehole and one segment. In the long-time region,
+ corresponding to times t > 1 hour, all boreholes are
+ represented as series of nSeg line segments and the
+ g-function is evaluated as described above.
- Calibration
+ References
- To calculate the length specific thermal resistance R of
- the pipe, the thermal resistance of the surrounding ground is added,
- which yields
+ Cimmino, M. and Bernier, M. 2014. A semi-analytical method to
+ generate g-functions for geothermal bore fields. International
+ Journal of Heat and Mass Transfer 70: 641-650.
-
- R=1/(0.208)+1/(2 lambda_g Modelica.Constants.pi)
- log(1/0.18),
+
+ Cimmino, M. 2018. Fast calculation of the g-functions of
+ geothermal borehole fields using similarities in the evaluation of
+ the finite line source solution. Journal of Building Performance
+ Simulation. DOI: 10.1080/19401493.2017.1423390.
- where the thermal conductivity of the ground lambda_g =
- 2.4 W/(m K).
+ Eskilson, P. 1987. Thermal analysis of heat extraction
+ boreholes. Ph.D. Thesis. Department of Mathematical Physics.
+ University of Lund. Sweden.
+
+
+ Li, M., Li, P., Chan, V. and Lai, A.C.K. 2014. Full-scale
+ temperature response function (G-function) for heat transfer by
+ borehole heat exchangers (GHEs) from sub-hour to decades. Applied
+ Energy 136: 197-205.
- - March 7, 2020, by Michael Wetter:
- Replaced measured data from specification in Modelica file to
- external table, as this reduces the computing time.
- This is for #1289.
-
- - May 15, 2019, by Jianjun Hu:
- Replaced fluid source. This is for #1072.
-
- - July 4, 2016 by Bram van der Heijde:
- Added parameters to test the influence of allowFlowReversal and the
- presence of explicit volumes in the pipe.
-
- - January 26, 2016 by Carles Ribas:
+ - March 22, 2018 by Massimo Cimmino:
First implementation.
-------- Errors --------
-line 48 column 2 - Warning: attribute "align" not allowed for HTML5
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+line 49 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/ThermalZones/ReducedOrder/RC/BaseClasses/splitFacVal.mo ----
+---- AixLib/BoundaryConditions/Validation/BESTEST/WD200.mo ----
-------- HTML Code --------
- Calculates the ratio of the surface areas of a wall to the total wall area,
- unless the area is zero. It subtracts the wall area AExt
- for first entry in AArray and AWin for
- second entry in AArray unless AArray[1] and/or
- AArray[2] are not zero. This is done separately for each
- orientation. Consequently, the function gives an nRow x nCol
- array back as output. Each row stands for one area in
- AArray and each column for one orientation in
- AExt and AWin. The function is used to
- calculate the split factors for
-
- AixLib.ThermalZones.ReducedOrder.RC.BaseClasses.ThermSplitter.
- For internal gains, the calculation is:
-
- SplitFaci = AArray[i]
- /ATot
-
- whereby ATot is the sum of AArray. To
- perform this,
- AExt and AWin can just be set to vectors of
- zeros with length 1.
- For solar radiation through windows, the window and wall area with the same
- orientation as the incoming radiation should be subtracted as these areas
- cannot be hit by the radiation. This needs to be done separately for each
- orientation and for exterior walls and windows only, according to:
-
- SplitFaci,k = (AArray[i]
- - AExt[k])
- /(ATot
- - AExt[k]
- -AWin[k])
-
- and
-
- SplitFaci,k = (AArray[i]
- - AWin[k])
- /(ATot
- - AExt[k]
- - AWin[k])
-
- respectively. For all other walls, the equation is:
-
- SplitFaci,k = AArray[i]
- /(ATot
- - AExt[k]
- - AWin[k])
-
-
-
- - December 15, 2015 by Moritz Lauster:
- First Implementation.
-
-
-
+
+ -
+ September 6, 2021, by Ettore Zanetti:
+ Removed parameter lat as it is now obtained from the weather data bus.
+ This is for
+ IBPSA, #1477.
+
+ -
+ March 11, 2020, by Ettore Zanetti:
+ First implementation.
+
+ -
+ April 14, 2020, by Ettore Zanetti:
+ Rework after comments from pull request
+ #1339.
+
+ -
+ May 2, 2021, by Ettore Zanetti:
+ Updated weather file as explained in #1478.
+
+
+
+ WD200: Low Elevation, Hot and Humid Case.
+ Weather data file : WD200.epw
+ Table 1: Site Data for Weather file WD200.epw
+
+ Latitude |
+ 33.633° north |
+
+
+ Longitude |
+ 84.433° west |
+
+
+ Altitude |
+ 308 m |
+
+
+ Time Zone |
+ -5 |
+
+
+
-------- Corrected Code --------
-
- Calculates the ratio of the surface areas of a wall to the total wall
- area, unless the area is zero. It subtracts the wall area
- AExt for first entry in AArray and
- AWin for second entry in AArray unless
- AArray[1] and/or AArray[2] are not zero.
- This is done separately for each orientation. Consequently, the
- function gives an nRow x nCol array back as output. Each
- row stands for one area in AArray and each column for
- one orientation in AExt and AWin. The
- function is used to calculate the split factors for AixLib.ThermalZones.ReducedOrder.RC.BaseClasses.ThermSplitter.
- For internal gains, the calculation is:
-
- SplitFaci = AArray[i] /ATot
- whereby ATot is the sum of AArray. To
-perform this, AExt and AWin can just be set
-to vectors of zeros with length 1. For solar radiation through windows,
-the window and wall area with the same orientation as the incoming
-radiation should be subtracted as these areas cannot be hit by the
-radiation. This needs to be done separately for each orientation and
-for exterior walls and windows only, according to:
-
- SplitFaci,k = (AArray[i] - AExt[k]) /(ATot - AExt[k]
- -AWin[k])
- and
-
- SplitFaci,k = (AArray[i] - AWin[k]) /(ATot - AExt[k] -
- AWin[k])
- respectively. For all other walls, the equation is:
-
- SplitFaci,k = AArray[i] /(ATot - AExt[k] - AWin[k])
-
- - December 15, 2015 by Moritz Lauster:
- First Implementation.
+ - September 6, 2021, by Ettore Zanetti:
+ Removed parameter lat as it is now obtained from the
+ weather data bus.
+ This is for IBPSA,
+ #1477.
+
+ - March 11, 2020, by Ettore Zanetti:
+ First implementation.
+
+ - April 14, 2020, by Ettore Zanetti:
+ Rework after comments from pull request #1339.
+
+ - May 2, 2021, by Ettore Zanetti:
+ Updated weather file as explained in #1478.
+
+ WD200: Low Elevation, Hot and Humid Case.
+
+
+ Weather data file : WD200.epw
+
+
+ Table 1: Site Data for Weather file WD200.epw
+
+
+
+ |
+
+ Latitude
+
+ |
+
+
+ 33.633° north
+
+ |
+
+
+ |
+
+ Longitude
+
+ |
+
+
+ 84.433° west
+
+ |
+
+
+ |
+
+ Altitude
+
+ |
+
+
+ 308 m
+
+ |
+
+
+ |
+
+ Time Zone
+
+ |
+
+
+ -5
+
+ |
+
+
-------- Errors --------
-line 15 column 4 - Warning: attribute "align" not allowed for HTML5
-line 27 column 4 - Warning: attribute "align" not allowed for HTML5
-line 35 column 4 - Warning: attribute "align" not allowed for HTML5
-line 43 column 4 - Warning: attribute "align" not allowed for HTML5
+line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/HeatPumps/ScrollWaterToWater.mo ----
+---- AixLib/Fluid/HeatPumps/Compressors/ReciprocatingCompressor.mo ----
-------- HTML Code --------
- Model for a water to water heat pump with a scroll compressor, as described
- in Jin (2002). The thermodynamic heat pump cycle is represented below.
-
-
-
-
-
- The rate of heat transferred to the evaporator is given by:
+ Model for a reciprocating processor, as detailed in Jin (2002). The rate of heat transferred to the evaporator is given by:
Q̇Eva = ṁref ( hVap(TEva) - hLiq(TCon) ).
@@ -21912,42 +18906,11 @@ line 43 column 4 - Warning: attribute "align" not allowed for HTML5
P = PTheoretical / η + PLoss,constant.
- Heat transfer in the evaporator and condenser is calculated using an
- ε-NTU method, assuming constant refrigerant temperature and constant heat
- transfer coefficient between fluid and refrigerant.
-
-
- Variable speed is achieved by multiplying the full load suction volume flow rate
+ Variable speed is acheived by multiplying the full load piston displacement
by the normalized compressor speed. The power and heat transfer rates are forced
to zero if the resulting heat pump state has higher evaporating pressure than
condensing pressure.
-
- The model parameters are obtained by calibration of the heat pump model to
- manufacturer performance data. Calibrated model parameters for various heat
- pumps from different manufacturers are found in
-
- AixLib.Fluid.HeatPumps.Data.ScrollWaterToWater. The calibrated model is
- located in
-
- AixLib.Fluid.HeatPumps.Calibration.ScrollWaterToWater.
-
- Options
-
- Parameters TConMax and TEvaMin
- may be used to set an upper or lower bound for the
- condenser and evaporator.
- The compressor is disabled when these conditions
- are not satisfied, or when the
- evaporator temperature is larger
- than the condenser temperature.
- This mimics the temperature protection
- of heat pumps and moreover it avoids
- non-converging algebraic loops of equations,
- or freezing of evaporator medium.
- This option can be disabled by setting
- enable_temperature_protection = false.
-
Assumptions and limitations
The compression process is assumed isentropic. The thermal energy
@@ -21965,29 +18928,27 @@ line 43 column 4 - Warning: attribute "align" not allowed for HTML5
-
+ January 25, 2019, by Michael Wetter:
+ Added start value to avoid warning in JModelica.
+
+ -
May 30, 2017, by Filip Jorissen:
- Revised documentation for temperature protection.
+ Removed pressure_error as
+ this is replaced by
+
+ AixLib.Fluid.HeatPumps.Compressors.BaseClasses.TemperatureProtection.
See #769.
-
- November 11, 2016, by Massimo Cimmino:
+ November 14, 2016, by Massimo Cimmino:
First implementation.
-------- Corrected Code --------
- Model for a water to water heat pump with a scroll compressor, as
- described in Jin (2002). The thermodynamic heat pump cycle is
- represented below.
-
-
-
-
-
- The rate of heat transferred to the evaporator is given by:
+ Model for a reciprocating processor, as detailed in Jin (2002). The
+ rate of heat transferred to the evaporator is given by:
Q̇Eva = ṁref (
@@ -22002,37 +18963,10 @@ line 43 column 4 - Warning: attribute "align" not allowed for HTML5
P = PTheoretical / η + PLoss,constant.
- Heat transfer in the evaporator and condenser is calculated using an
- ε-NTU method, assuming constant refrigerant temperature and constant
- heat transfer coefficient between fluid and refrigerant.
-
-
- Variable speed is achieved by multiplying the full load suction
- volume flow rate by the normalized compressor speed. The power and
- heat transfer rates are forced to zero if the resulting heat pump
- state has higher evaporating pressure than condensing pressure.
-
-
- The model parameters are obtained by calibration of the heat pump
- model to manufacturer performance data. Calibrated model parameters
- for various heat pumps from different manufacturers are found in
- AixLib.Fluid.HeatPumps.Data.ScrollWaterToWater.
- The calibrated model is located in AixLib.Fluid.HeatPumps.Calibration.ScrollWaterToWater.
-
-
- Options
-
-
- Parameters TConMax and TEvaMin may be used
- to set an upper or lower bound for the condenser and evaporator. The
- compressor is disabled when these conditions are not satisfied, or
- when the evaporator temperature is larger than the condenser
- temperature. This mimics the temperature protection of heat pumps and
- moreover it avoids non-converging algebraic loops of equations, or
- freezing of evaporator medium. This option can be disabled by setting
- enable_temperature_protection = false.
+ Variable speed is acheived by multiplying the full load piston
+ displacement by the normalized compressor speed. The power and heat
+ transfer rates are forced to zero if the resulting heat pump state
+ has higher evaporating pressure than condensing pressure.
Assumptions and limitations
@@ -22051,245 +18985,121 @@ line 43 column 4 - Warning: attribute "align" not allowed for HTML5
Oklahoma, USA. 2002.
-
--------- Errors --------
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
-line 12 column 2 - Warning: attribute "align" not allowed for HTML5
-line 18 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/Movers/Validation/PowerExact.mo ----
--------- HTML Code --------
-
-
- This example is identical to
-
- AixLib.Fluid.Movers.Validation.PowerSimplified, except that the
- performance data for the flow controlled pumps
- pump_dp and pump_m_flow contain
- the pressure curves and efficiency curves.
- The plot below shows that this leads to a computation of the power consumption
- that is identical to the one from the speed controlled pump pump_Nrpm.
-
-
-
-
-
-
- -
- October 15, 2021, by Hongxiang Fu:
- Fixed the image in the documentation which was cut off
- at the y-axis. This is for
- IBPSA, #1533.
-
- -
- March 2, 2016, by Filip Jorissen:
- First implementation for
- #417.
-
-
-
--------- Corrected Code --------
-
- This example is identical to AixLib.Fluid.Movers.Validation.PowerSimplified,
- except that the performance data for the flow controlled pumps
- pump_dp and pump_m_flow contain the
- pressure curves and efficiency curves. The plot below shows that this
- leads to a computation of the power consumption that is identical to
- the one from the speed controlled pump pump_Nrpm.
-
-
-
-
-
- - October 15, 2021, by Hongxiang Fu:
- Fixed the image in the documentation which was cut off at the
- y-axis. This is for IBPSA,
- #1533.
-
- - March 2, 2016, by Filip Jorissen:
- First implementation for #417.
-
-
-
--------- Errors --------
-line 12 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/BoundaryConditions/Validation/BESTEST/WD300.mo ----
--------- HTML Code --------
-
-
- -
- September 6, 2021, by Ettore Zanetti:
- Removed parameter lat as it is now obtained from the weather data bus.
- This is for
- IBPSA, #1477.
-
- -
- March 11, 2020, by Ettore Zanetti:
- First implementation.
-
- -
- April 14, 2020, by Ettore Zanetti:
- Rework after comments from pull request
- #1339.
-
- -
- May 2, 2021, by Ettore Zanetti:
- Updated weather file as explained in #1478.
-
-
-
- WD300: Southern Hemisphere Case
- Weather data file : WD300.epw
- Table 1: Site Data for Weather file WD300.epw
-
- Latitude |
- 33.393° south |
-
-
- Longitude |
- 70.786° west |
-
-
- Altitude |
- 474 m |
-
-
- Time Zone |
- -4 |
-
-
-
--------- Corrected Code --------
-
- - September 6, 2021, by Ettore Zanetti:
- Removed parameter lat as it is now obtained from the
- weather data bus.
- This is for IBPSA,
- #1477.
-
- - March 11, 2020, by Ettore Zanetti:
+ - November 14, 2016, by Massimo Cimmino:
First implementation.
- - April 14, 2020, by Ettore Zanetti:
- Rework after comments from pull request #1339.
-
- - May 2, 2021, by Ettore Zanetti:
- Updated weather file as explained in #1478.
-
-
- WD300: Southern Hemisphere Case
-
-
- Weather data file : WD300.epw
-
-
- Table 1: Site Data for Weather file WD300.epw
-
-
-
- |
-
- Latitude
-
- |
-
-
- 33.393° south
-
- |
-
-
- |
-
- Longitude
-
- |
-
-
- 70.786° west
-
- |
-
-
- |
-
- Altitude
-
- |
-
-
- 474 m
-
- |
-
-
- |
-
- Time Zone
-
- |
-
-
- -4
-
- |
-
-
-------- Errors --------
-line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+line 11 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/PrescribedOutlet.mo ----
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/infiniteLineSource.mo ----
-------- HTML Code --------
- Model that allows specifying the temperature and mass fraction of the fluid
- that leaves the model from port_b.
+ This function evaluates the infinite line source solution. This solution gives
+ the relation between the constant heat transfer rate (per unit length) injected
+ by a line heat source of infinite length and the temperature raise in the
+ medium. The infinite line source solution is defined by
+
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/InfiniteLineSource_01.png\")
- This model forces the outlet temperature at port_b to be equal to the temperature
- of the input signal TSet, subject to optional limits on the
- heating or cooling capacity QMax_flow ≥ 0 and QMin_flow ≤ 0.
- Similarly than for the temperature,
- this model also forces the outlet water mass fraction at port_b to be
- no lower than the
- input signal X_wSet, subject to optional limits on the
- maximum water vapor mass flow rate that is added, as
- described by the parameter mWatMax_flow.
- By default, the model has unlimited capacity, but control of temperature
- and humidity can be subject to capacity limits, or be disabled.
+ where ΔT(t,r) is the temperature raise after a time t of
+ constant heat injection and at a distance r from the line source,
+ Q' is the heat injection rate per unit length, ks is
+ the soil thermal conductivity and hILS is the infinite line
+ source solution.
- The output signal Q_flow is the heat added (for heating) or subtracted (for cooling)
- to the medium if the flow rate is from port_a to port_b.
- If the flow is reversed, then Q_flow=0.
+ The infinite line source solution is given by the exponential integral
+
+
+ ![\"image\"](\"modelica://AixLib/Resources/Images/Fluid/Geothermal/Borefields/InfiniteLineSource_02.png\")
- The outlet conditions at port_a are not affected by this model.
+ where αs is the ground thermal diffusivity. The
+ exponential integral is implemented in
+ AixLib.Utilities.Math.Functions.exponentialIntegralE1.
+
+
+
+ -
+ March 22, 2018 by Massimo Cimmino:
+ First implementation.
+
+
+
+-------- Corrected Code --------
+
+ This function evaluates the infinite line source solution. This
+ solution gives the relation between the constant heat transfer rate
+ (per unit length) injected by a line heat source of infinite length
+ and the temperature raise in the medium. The infinite line source
+ solution is defined by
+
+
+
+
+
+ where ΔT(t,r) is the temperature raise after a time t
+ of constant heat injection and at a distance r from the line
+ source, Q' is the heat injection rate per unit length,
+ ks is the soil thermal conductivity and
+ hILS is the infinite line source solution.
+
+
+ The infinite line source solution is given by the exponential
+ integral
+
+
+
+
+
+ where αs is the ground thermal diffusivity. The
+ exponential integral is implemented in AixLib.Utilities.Math.Functions.exponentialIntegralE1.
+
+
+ - March 22, 2018 by Massimo Cimmino:
+ First implementation.
+
+
+
+-------- Errors --------
+line 8 column 2 - Warning: attribute "align" not allowed for HTML5
+line 21 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Interfaces/PrescribedOutlet.mo ----
+-------- HTML Code --------
+
+
+ This model sets the temperature or the water vapor mass fraction
+ of the medium that leaves port_a
+ to the value given by the input TSet or X_wSet,
+ subject to optional limitations on the capacity
+ for heating and cooling, or limitations on the humidification or dehumidification
+ moisture mass flow rate.
+ Also, optionally the model allows to take into account first order dynamics.
- If the parameter energyDynamics is not equal to
+ If the parameters energyDynamics is not equal to
Modelica.Fluid.Types.Dynamics.SteadyState,
the component models the dynamic response using a first order differential equation.
The time constant of the component is equal to the parameter tau.
@@ -22308,43 +19118,15 @@ line 5 column 2 - Warning: The summary attribute on the element is obsol
control volume would have.
- Optionally, this model can have a flow resistance.
- If no flow resistance is requested, set dp_nominal=0.
-
-
- For a model that uses a control signal u ∈ [0, 1] and multiplies
- this with the nominal heating or cooling power, use
-
- AixLib.Fluid.HeatExchangers.HeaterCooler_u
-
-
- Limitations
-
- This model only adds or removes heat or water vapor for the flow from
- port_a to port_b.
- The enthalpy of the reverse flow is not affected by this model.
-
-
- If this model is used to cool air below the dew point temperature, the water mass fraction
- will not change.
-
-
- Note that for use_TSet = false, the enthalpy of the leaving fluid
- will not be changed, even if moisture is added. The enthalpy added (or removed)
- by the change in humidity is neglected. To properly account for change in enthalpy
- due to humidification, use instead
-
- AixLib.Fluid.Humidifiers.SprayAirWasher_X.
+ This model has no pressure drop.
+ See
+ AixLib.Fluid.HeatExchangers.PrescribedOutlet
+ for a model that instantiates this model and that has a pressure drop.
- Validation
- The model has been validated against the analytical solution in
- the examples
-
- AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet
- and
-
- AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet_dynamic.
+ In case of reverse flow,
+ the fluid that leaves port_a has the same
+ properties as the fluid that enters port_b.
@@ -22355,56 +19137,46 @@ line 5 column 2 - Warning: The summary attribute on the element is obsol
issue 1542.
-
- May 3, 2017, by Michael Wetter:
- Updated protected model for
- #763.
+ April 29, 2021, by Michael Wetter:
+ Removed duplicate declaration of m_flow_nominal which is already
+ declared in the base class.
-
- December 1, 2016, by Michael Wetter:
- Updated model as use_dh is no longer a parameter in the pressure drop model.
+ March 19, 2018, by Michael Wetter:
+ Added bugfix as the old model did not track TSet and X_wSet
+ simultaneously.
This is for
- #480.
+ #893.
-
- November 11, 2014, by Michael Wetter:
- Revised implementation.
+ May 3, 2017, by Michael Wetter:
+ Refactored model to allow X_wSet as an input.
+ This is for
+ #763.
-
- March 19, 2014, by Christoph Nytsch-Geusen:
- First implementation.
-
-
-
--------- Corrected Code --------
-
- Model that allows specifying the temperature and mass fraction of the
- fluid that leaves the model from port_b.
-
-
- This model forces the outlet temperature at port_b to be
- equal to the temperature of the input signal TSet,
- subject to optional limits on the heating or cooling capacity
- QMax_flow ≥ 0 and QMin_flow ≤ 0. Similarly
- than for the temperature, this model also forces the outlet water
- mass fraction at port_b to be no lower than the input
- signal X_wSet, subject to optional limits on the maximum
- water vapor mass flow rate that is added, as described by the
- parameter mWatMax_flow. By default, the model has
- unlimited capacity, but control of temperature and humidity can be
- subject to capacity limits, or be disabled.
-
-
- The output signal Q_flow is the heat added (for heating)
- or subtracted (for cooling) to the medium if the flow rate is from
- port_a to port_b. If the flow is reversed,
- then Q_flow=0.
-
+ January 26, 2016, by Michael Wetter:
+ Removed inequality comparison of real numbers in restrictCool
+ and in restrictHeat as this is not allowed in Modelica.
+
+ -
+ November 10, 2014, by Michael Wetter:
+ First implementation.
+
+
+
+-------- Corrected Code --------
- The outlet conditions at port_a are not affected by this
- model.
+ This model sets the temperature or the water vapor mass fraction of
+ the medium that leaves port_a to the value given by the
+ input TSet or X_wSet, subject to optional
+ limitations on the capacity for heating and cooling, or limitations
+ on the humidification or dehumidification moisture mass flow rate.
+ Also, optionally the model allows to take into account first order
+ dynamics.
- If the parameter energyDynamics is not equal to
+ If the parameters energyDynamics is not equal to
Modelica.Fluid.Types.Dynamics.SteadyState, the component
models the dynamic response using a first order differential
equation. The time constant of the component is equal to the
@@ -22422,45 +19194,14 @@ line 5 column 2 - Warning: The summary attribute on the element is obsol
volume would have.
- Optionally, this model can have a flow resistance. If no flow
- resistance is requested, set dp_nominal=0.
-
-
- For a model that uses a control signal u ∈ [0, 1] and
- multiplies this with the nominal heating or cooling power, use
- AixLib.Fluid.HeatExchangers.HeaterCooler_u
-
-
- Limitations
-
-
- This model only adds or removes heat or water vapor for the flow from
- port_a to port_b. The enthalpy of the
- reverse flow is not affected by this model.
-
-
- If this model is used to cool air below the dew point temperature,
- the water mass fraction will not change.
-
-
- Note that for use_TSet = false, the enthalpy of the
- leaving fluid will not be changed, even if moisture is added. The
- enthalpy added (or removed) by the change in humidity is neglected.
- To properly account for change in enthalpy due to humidification, use
- instead AixLib.Fluid.Humidifiers.SprayAirWasher_X.
+ This model has no pressure drop. See AixLib.Fluid.HeatExchangers.PrescribedOutlet
+ for a model that instantiates this model and that has a pressure
+ drop.
-
- Validation
-
- The model has been validated against the analytical solution in the
- examples AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet
- and
- AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet_dynamic.
+ In case of reverse flow, the fluid that leaves port_a
+ has the same properties as the fluid that enters port_b.
- March 3, 2022, by Michael Wetter:
@@ -22469,2545 +19210,5804 @@ line 5 column 2 - Warning: The summary attribute on the element is obsol
\"https://github.com/ibpsa/modelica-ibpsa/issues/1542\">issue
1542.
- - May 3, 2017, by Michael Wetter:
- Updated protected model for #763.
+ - April 29, 2021, by Michael Wetter:
+ Removed duplicate declaration of m_flow_nominal which
+ is already declared in the base class.
- - December 1, 2016, by Michael Wetter:
- Updated model as use_dh is no longer a parameter in
- the pressure drop model.
+ - March 19, 2018, by Michael Wetter:
+ Added bugfix as the old model did not track TSet and
+ X_wSet simultaneously.
This is for #480.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/893\">#893.
- - November 11, 2014, by Michael Wetter:
- Revised implementation.
+ - May 3, 2017, by Michael Wetter:
+ Refactored model to allow X_wSet as an input.
+ This is for #763.
- - March 19, 2014, by Christoph Nytsch-Geusen:
+ - January 26, 2016, by Michael Wetter:
+ Removed inequality comparison of real numbers in
+ restrictCool and in restrictHeat as this
+ is not allowed in Modelica.
+
+ - November 10, 2014, by Michael Wetter:
First implementation.
-------- Errors --------
-line 34 column 2 - Warning: attribute "align" not allowed for HTML5
+line 18 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/GroundTemperatureResponse.mo ----
+---- AixLib/Fluid/Sensors/LatentEnthalpyFlowRate.mo ----
-------- HTML Code --------
- This model calculates the ground temperature response to obtain the temperature
- at the borehole wall in a geothermal system where heat is being injected into or
- extracted from the ground.
-
-
- A load-aggregation scheme based on that developed by Claesson and Javed (2012) is
- used to calculate the borehole wall temperature response with the temporal superposition
- of ground thermal loads. In its base form, the
- load-aggregation scheme uses fixed-length aggregation cells to agglomerate
- thermal load history together, with more distant cells (denoted with a higher cell and vector index)
- representing more distant thermal history. The more distant the thermal load, the
- less impactful it is on the borehole wall temperature change at the current time step.
- Each cell has an aggregation time associated to it denoted by nu,
- which corresponds to the simulation time (since the beginning of heat injection or
- extraction) at which the cell will begin shifting its thermal load to more distant
- cells. To determine nu, cells have a temporal size rcel
- (rcel in this model)
- which follows the exponential growth
-
-
-
-
-
- where nCel is the number of consecutive cells which can have the same size.
- Decreasing rcel will generally decrease calculation times, at the cost of
- precision in the temporal superposition. rcel is expressed in multiples
- of the aggregation time resolution (via the parameter tLoaAgg).
- Then, nu may be expressed as the sum of all rcel values
- (multiplied by the aggregation time resolution) up to and including that cell in question.
-
-
- To determine the weighting factors, the borefield's temperature
- step response at the borefield wall is determined as
-
-
-
-
-
- where g(·) is the borefield's thermal response factor known as the g-function,
- H is the total length of all boreholes and ks is the thermal
- conductivity of the soil. The weighting factors kappa (κ in the equation below)
- for a given cell i are then expressed as follows.
-
-
-
-
-
- where ν refers to the vector nu in this model and
- Tstep(ν0)=0.
-
-
- At every aggregation time step, a time event is generated to perform the load aggregation steps.
- First, the thermal load is shifted. When shifting between cells of different size, total
- energy is conserved. This operation is illustred in the figure below by Cimmino (2014).
-
-
-
-
-
- After the cell-shifting operation is performed, the first aggregation cell has its
- value set to the average thermal load since the last aggregation step.
- Temporal superposition is then applied by means
- of a scalar product between the aggregated thermal loads QAgg_flow and the
- weighting factors κ.
-
-
- Due to Modelica's variable time steps, the load aggregation scheme is modified by separating
- the thermal response between the current aggregation time step and everything preceding it.
- This is done according to
-
-
-
-
-
-
-
- where Tb is the borehole wall temperature,
- Tg
- is the undisturbed ground temperature,
- Q is the ground thermal load per borehole length and h = g/(2 π ks)
- is a temperature response factor based on the g-function. tk
- is the last discrete aggregation time step, meaning that the current time t
- satisfies tk≤t≤tk+1.
- Δtagg(=tk+1-tk) is the
- parameter tLoaAgg in the present model.
-
-
- Thus,
- ΔTb*(t)
- is the borehole wall temperature change due to the thermal history prior to the current
- aggregation step. At every aggregation time step, load aggregation and temporal superposition
- are used to calculate its discrete value. Assuming no heat injection or extraction until
- tk+1, this term is assumed to have a linear
- time derivative, which is given by the difference between ΔTb*(tk+1)
- (the temperature change from load history at the next discrete aggregation time step, which
- is constant over the duration of the ongoing aggregation time step) and the total
- temperature change at the last aggregation time step, ΔTb(t).
-
-
-
-
-
- The second term ΔTb,q(t) concerns the ongoing aggregation time step.
- To obtain the time derivative of this term, the thermal response factor h is assumed
- to vary linearly over the course of an aggregation time step. Therefore, because
- the ongoing aggregation time step always concerns the first aggregation cell, its derivative (denoted
- by the parameter dTStepdt in this model) can be calculated as
- kappa[1], the first value in the kappa vector,
- divided by the aggregation time step Δt.
- The derivative of the temperature change at the borehole wall is then expressed
- as the multiplication of dTStepdt (which only needs to be
- calculated once at the start of the simulation) and the heat flow Q at
- the borehole wall.
-
-
-
+ This model outputs the latent enthalphy flow rate of the medium in the flow
+ between its fluid ports. In particular, if the total enthalpy flow rate is
-
-
+
+ Ḣtot = Ḣsen + Ḣlat,
- With the two terms in the expression of ΔTb(t) expressed
- as time derivatives, ΔTb(t) can itself also be
- expressed as its time derivative and implemented as such directly in the Modelica
- equations block with the der() operator.
-
-
-
-
-
+ where
+ Ḣsen = ṁ (1-Xw) cp,air,
+ then this sensor outputs Ḣ = Ḣlat.
- This load aggregation scheme is validated in
-
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.Validation.Analytic_20Years.
+ If the parameter tau is non-zero, then the measured
+ specific latent enthalpy hout that is used to
+ compute the latent enthalpy flow rate
+ Ḣlat = ṁ hout
+ is computed using a first order differential equation.
+ See
+ AixLib.Fluid.Sensors.UsersGuide for an explanation.
- References
- Cimmino, M. 2014. Développement et validation expérimentale de facteurs de réponse
- thermique pour champs de puits géothermiques,
- Ph.D. Thesis, École Polytechnique de Montréal.
+ For a sensor that measures
+ Ḣtot, use
+
+ AixLib.Fluid.Sensors.EnthalpyFlowRate.
+ For a sensor that measures
+ Ḣsen, use
+
+ AixLib.Fluid.Sensors.SensibleEnthalpyFlowRate.
- Claesson, J. and Javed, S. 2012. A load-aggregation method to calculate extraction temperatures of borehole heat exchangers. ASHRAE Transactions 118(1): 530-539.
+ The sensor is ideal, i.e., it does not influence the fluid.
+ The sensor can only be used with medium models that implement the function
+ enthalpyOfNonCondensingGas(T).
-
- August 30, 2018, by Michael Wetter:
- Refactored model to compute the temperature difference relative to the initial temperature,
- because the model is independent of the initial temperature.
+ October 19, 2020, by Antoine Gautier:
+ Changed default value for tau from 1 to 0.
+ This is for
+ #1406.
-
- April 5, 2018, by Alex Laferrière:
+ February 25, 2020, by Michael Wetter:
+ Changed icon to display its operating state.
+ This is for
+ #1294.
+
+ -
+ January 18, 2016 by Filip Jorissen:
+ Using parameter tauInv
+ since this now exists in
+ AixLib.Fluid.Sensors.BaseClasses.PartialDynamicFlowSensor.
+ This is for
+ #372.
+
+ -
+ September 10, 2013, by Michael Wetter:
+ Changed medium declaration in the extends statement
+ to replaceable to avoid a translation error in
+ OpenModelica.
+
+ -
+ August 31, 2013, by Michael Wetter:
+ Removed default value tau=0 as the base class
+ already sets tau=1.
+ This change was made so that all sensors use the same default value.
+
+ -
+ December 18, 2012, by Michael Wetter:
+ Moved computation of i_w to new base class
+
+ AixLib.Fluid.BaseClasses.IndexWater.
+ The value of this parameter is now assigned dynamically and does not require to be specified
+ by the user.
+
+ -
+ November 3, 2011, by Michael Wetter:
+ Moved der(h_out) := 0; from the initial algorithm section to
+ the initial equation section
+ as this assignment does not conform to the Modelica specification.
+
+ -
+ August 10, 2011 by Michael Wetter:
+ Added parameter i_w and an assert statement to
+ make sure it is set correctly. Without this change, Dymola
+ cannot differentiate the model when reducing the index of the DAE.
+
+ -
+ June 3, 2011 by Michael Wetter:
+ Revised implementation to add dynamics in such a way that
+ the time constant increases as the mass flow rate tends to zero.
+ This can improve the numerics.
+
+ -
+ February 22, by Michael Wetter:
+ Improved code that searches for index of 'water' in medium model.
+
+ -
+ September 9, 2009 by Michael Wetter:
First implementation.
+ Implementation is based on enthalpy sensor of Modelica.Fluid.
-------- Corrected Code --------
- This model calculates the ground temperature response to obtain the
- temperature at the borehole wall in a geothermal system where heat is
- being injected into or extracted from the ground.
-
-
- A load-aggregation scheme based on that developed by Claesson and
- Javed (2012) is used to calculate the borehole wall temperature
- response with the temporal superposition of ground thermal loads. In
- its base form, the load-aggregation scheme uses fixed-length
- aggregation cells to agglomerate thermal load history together, with
- more distant cells (denoted with a higher cell and vector index)
- representing more distant thermal history. The more distant the
- thermal load, the less impactful it is on the borehole wall
- temperature change at the current time step. Each cell has an
- aggregation time associated to it denoted by
- nu, which corresponds to the simulation time (since the
- beginning of heat injection or extraction) at which the cell will
- begin shifting its thermal load to more distant cells. To determine
- nu, cells have a temporal size rcel
- (rcel in this model) which follows the exponential
- growth
-
-
-
-
-
- where nCel is the number of consecutive cells which
- can have the same size. Decreasing rcel will
- generally decrease calculation times, at the cost of precision in the
- temporal superposition. rcel is expressed in multiples
- of the aggregation time resolution (via the parameter
- tLoaAgg). Then, nu may be expressed as the
- sum of all rcel values (multiplied by the aggregation
- time resolution) up to and including that cell in question.
-
-
- To determine the weighting factors, the borefield's temperature step
- response at the borefield wall is determined as
-
-
-
-
-
- where g(·) is the borefield's thermal response factor known as
- the g-function, H is the total length of all
- boreholes and ks is the thermal conductivity of the
- soil. The weighting factors kappa (κ in the
- equation below) for a given cell i are then expressed as
- follows.
-
-
-
-
-
- where ν refers to the vector nu in this model and
- Tstep(ν0)=0.
-
-
- At every aggregation time step, a time event is generated to perform
- the load aggregation steps. First, the thermal load is shifted. When
- shifting between cells of different size, total energy is conserved.
- This operation is illustred in the figure below by Cimmino (2014).
-
-
-
-
-
- After the cell-shifting operation is performed, the first aggregation
- cell has its value set to the average thermal load since the last
- aggregation step. Temporal superposition is then applied by means of
- a scalar product between the aggregated thermal loads
- QAgg_flow and the weighting factors κ.
-
-
- Due to Modelica's variable time steps, the load aggregation scheme is
- modified by separating the thermal response between the current
- aggregation time step and everything preceding it. This is done
- according to
-
-
-
-
-
+ This model outputs the latent enthalphy flow rate of the
+ medium in the flow between its fluid ports. In particular, if the
+ total enthalpy flow rate is
-
- where Tb is the borehole wall temperature,
- Tg is the undisturbed ground temperature, Q
- is the ground thermal load per borehole length and h = g/(2 π
- ks) is a temperature response factor based on the
- g-function. tk is the last discrete aggregation
- time step, meaning that the current time t satisfies
- tk≤t≤tk+1.
- Δtagg(=tk+1-tk) is the
- parameter tLoaAgg in the present model.
+
+ Ḣtot = Ḣsen + Ḣlat,
- Thus, ΔTb*(t) is the borehole wall temperature
- change due to the thermal history prior to the current aggregation
- step. At every aggregation time step, load aggregation and temporal
- superposition are used to calculate its discrete value. Assuming no
- heat injection or extraction until tk+1, this term
- is assumed to have a linear time derivative, which is given by the
- difference between ΔTb*(tk+1) (the
- temperature change from load history at the next discrete aggregation
- time step, which is constant over the duration of the ongoing
- aggregation time step) and the total temperature change at the last
- aggregation time step, ΔTb(t).
-
-
-
+ where Ḣsen = ṁ (1-Xw)
+ cp,air, then this sensor outputs Ḣ =
+ Ḣlat.
- The second term ΔTb,q(t) concerns the ongoing
- aggregation time step. To obtain the time derivative of this term,
- the thermal response factor h is assumed to vary linearly over
- the course of an aggregation time step. Therefore, because the
- ongoing aggregation time step always concerns the first aggregation
- cell, its derivative (denoted by the parameter dTStepdt
- in this model) can be calculated as kappa[1], the first
- value in the kappa vector, divided by the aggregation
- time step Δt. The derivative of the temperature change at the
- borehole wall is then expressed as the multiplication of
- dTStepdt (which only needs to be calculated once at the
- start of the simulation) and the heat flow Q at the borehole
- wall.
-
-
-
-
-
-
+ If the parameter tau is non-zero, then the measured
+ specific latent enthalpy hout that is used to
+ compute the latent enthalpy flow rate Ḣlat = ṁ
+ hout is computed using a first order differential
+ equation. See AixLib.Fluid.Sensors.UsersGuide
+ for an explanation.
- With the two terms in the expression of ΔTb(t)
- expressed as time derivatives, ΔTb(t) can itself
- also be expressed as its time derivative and implemented as such
- directly in the Modelica equations block with the der()
- operator.
-
-
-
+ For a sensor that measures Ḣtot, use AixLib.Fluid.Sensors.EnthalpyFlowRate.
-
-
-
- This load aggregation scheme is validated in
- AixLib.Fluid.Geothermal.Borefields.BaseClasses.HeatTransfer.Validation.Analytic_20Years.
-
-
- References
-
-
- Cimmino, M. 2014. Développement et validation expérimentale de
- facteurs de réponse thermique pour champs de puits géothermiques,
- Ph.D. Thesis, École Polytechnique de Montréal.
+ For a sensor that measures Ḣsen, use AixLib.Fluid.Sensors.SensibleEnthalpyFlowRate.
- Claesson, J. and Javed, S. 2012. A load-aggregation method to
- calculate extraction temperatures of borehole heat exchangers.
- ASHRAE Transactions 118(1): 530-539.
+ The sensor is ideal, i.e., it does not influence the fluid. The
+ sensor can only be used with medium models that implement the
+ function enthalpyOfNonCondensingGas(T).
- - August 30, 2018, by Michael Wetter:
- Refactored model to compute the temperature difference relative to
- the initial temperature, because the model is independent of the
- initial temperature.
+ - October 19, 2020, by Antoine Gautier:
+ Changed default value for tau from 1 to
+ 0.
+ This is for #1406.
- - April 5, 2018, by Alex Laferrière:
- First implementation.
+ - February 25, 2020, by Michael Wetter:
+ Changed icon to display its operating state.
+ This is for #1294.
+
+ - January 18, 2016 by Filip Jorissen:
+ Using parameter tauInv since this now exists in
+
+ AixLib.Fluid.Sensors.BaseClasses.PartialDynamicFlowSensor. This
+ is for #372.
+
+ - September 10, 2013, by Michael Wetter:
+ Changed medium declaration in the extends statement to
+ replaceable to avoid a translation error in
+ OpenModelica.
+
+ - August 31, 2013, by Michael Wetter:
+ Removed default value tau=0 as the base class already
+ sets tau=1. This change was made so that all sensors
+ use the same default value.
+
+ - December 18, 2012, by Michael Wetter:
+ Moved computation of i_w to new base class AixLib.Fluid.BaseClasses.IndexWater.
+ The value of this parameter is now assigned dynamically and does
+ not require to be specified by the user.
+
+ - November 3, 2011, by Michael Wetter:
+ Moved der(h_out) := 0; from the initial algorithm
+ section to the initial equation section as this assignment does not
+ conform to the Modelica specification.
+
+ - August 10, 2011 by Michael Wetter:
+ Added parameter i_w and an assert statement to make
+ sure it is set correctly. Without this change, Dymola cannot
+ differentiate the model when reducing the index of the DAE.
+
+ - June 3, 2011 by Michael Wetter:
+ Revised implementation to add dynamics in such a way that the time
+ constant increases as the mass flow rate tends to zero. This can
+ improve the numerics.
+
+ - February 22, by Michael Wetter:
+ Improved code that searches for index of 'water' in medium model.
+
+ - September 9, 2009 by Michael Wetter:
+ First implementation. Implementation is based on enthalpy sensor of
+ Modelica.Fluid.
-------- Errors --------
-line 22 column 2 - Warning: attribute "align" not allowed for HTML5
-line 37 column 2 - Warning: attribute "align" not allowed for HTML5
-line 46 column 2 - Warning: attribute "align" not allowed for HTML5
-line 58 column 2 - Warning: attribute "align" not allowed for HTML5
-line 73 column 2 - Warning: attribute "align" not allowed for HTML5
-line 101 column 2 - Warning: attribute "align" not allowed for HTML5
-line 117 column 2 - Warning: attribute "align" not allowed for HTML5
-line 120 column 2 - Warning: attribute "align" not allowed for HTML5
-line 129 column 2 - Warning: attribute "align" not allowed for HTML5
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/MSLAIT2Nodes.mo ----
+---- AixLib/BoundaryConditions/WeatherData/ReaderTMY3.mo ----
-------- HTML Code --------
- The example contains
-
- experimental data from a real district heating network.
- This data is used to validate this library's
- plug flow pipe model
- in
- AixLib.Fluid.FixedResistances.Validation.PlugFlowPipes.PlugFlowAIT.
+
+ Block to output the latitude of the location.
+ This block is added so that the latitude is displayed
+ with a comment in the GUI of the weather bus connector.
+
+ Implementation
+
+ If
+
+ Modelica.Blocks.Sources.Constant where used, then
+ the comment for the latitude would be \"Connector of Real output signal\".
+ As this documentation string cannot be overwritten, a new block
+ was implemented.
+
+
+
+ -
+ January 4, 2016, by Michael Wetter:
+ First implementation.
+
+
+
+
+ Block to output the longitude of the location.
+ This block is added so that the longitude is displayed
+ with a comment in the GUI of the weather bus connector.
+
+ Implementation
+
+ If
+
+ Modelica.Blocks.Sources.Constant where used, then
+ the comment for the longitude would be \"Connector of Real output signal\".
+ As this documentation string cannot be overwritten, a new block
+ was implemented.
+
+
+
+ -
+ January 4, 2016, by Michael Wetter:
+ First implementation.
+
+
+
+
+ Block to output the altitude of the location.
+ This block is added so that the altitude is displayed
+ with a comment in the GUI of the weather bus connector.
+
+ Implementation
+
+ If
+
+ Modelica.Blocks.Sources.Constant where used, then
+ the comment for the Altitude would be \"Connector of Real output signal\".
+ As this documentation string cannot be overwritten, a new block
+ was implemented.
+
+
+
+ -
+ May 2, 2021, by Ettore Zanetti:
+ First implementation.
+
+
+
+
+ This component reads TMY3 weather data (Wilcox and Marion, 2008) or user specified weather data.
+ The Modelica built-in variable time determines what row
+ of the weather file is read.
+ The value of time is the number of seconds
+ that have passed since January 1st at midnight (00:00) in the local time zone.
+ The local time zone value, longitude and latitute are also read from the weather data,
+ such that the solar position computations are consistent with the weather data.
+
+
+ The weather data format is the Typical Meteorological Year (TMY3)
+ as obtained from the EnergyPlus web site at
+
+ http://energyplus.net/weather. These
+ data, which are in the EnergyPlus format, need to be converted as described
+ below.
+
+
+ Output to weaBus
+
+ The following variables serve as output and are accessible via weaBus:
+
+
+
+
+ | Name
+ |
+ Unit
+ |
+ Description
+ |
+
+
+
+
+ HDifHor
+ |
+
+ W/m2
+ |
+
+ Horizontal diffuse solar radiation.
+ |
+
+
+
+
+ HDifNor
+ |
+
+ W/m2
+ |
+
+ Direct normal radiation.
+ |
+
+
+
+
+ HGloHor
+ |
+
+ W/m2
+ |
+
+ Horizontal global radiation.
+ |
+
+
+
+
+ HHorIR
+ |
+
+ W/m2
+ |
+
+ Horizontal infrared irradiation.
+ |
+
+
+
+
+ TBlaSky
+ |
+
+ K
+ |
+
+ Output temperature.
+ |
+
+
+
+
+ TDewPoi
+ |
+
+ K
+ |
+
+ Dew point temperature.
+ |
+
+
+
+
+ TDryBul
+ |
+
+ K
+ |
+
+ Dry bulb temperature at ground level.
+ |
+
+
+
+
+ TWetBul
+ |
+
+ K
+ |
+
+ Wet bulb temperature.
+ |
+
+
+
+
+ celHei
+ |
+
+ m
+ |
+
+ Ceiling height.
+ |
+
+
+
+
+ cloTim
+ |
+
+ s
+ |
+
+ One-based day number in seconds.
+ |
+
+
+
+
+ lat
+ |
+
+ rad
+ |
+
+ Latitude of the location.
+ |
+
+
+
+
+ lon
+ |
+
+ rad
+ |
+
+ Longitude of the location.
+ |
+
+
+
+
+ nOpa
+ |
+
+ 1
+ |
+
+ Opaque sky cover [0, 1].
+ |
+
+
+
+
+ nTot
+ |
+
+ 1
+ |
+
+ Total sky Cover [0, 1].
+ |
+
+
+
+
+ pAtm
+ |
+
+ Pa
+ |
+
+ Atmospheric pressure.
+ |
+
+
+
+
+ relHum
+ |
+
+ 1
+ |
+
+ Relative humidity.
+ |
+
+
+
+
+ solAlt
+ |
+
+ rad
+ |
+
+ Altitude angle.
+ |
+
+
+
+
+ solDec
+ |
+
+ rad
+ |
+
+ Declination angle.
+ |
+
+
+
+
+ solHouAng
+ |
+
+ rad
+ |
+
+ Solar hour angle.
+ |
+
+
+
+
+ solTim
+ |
+
+ s
+ |
+
+ Solar time.
+ |
+
+
+
+
+ solZen
+ |
+
+ rad
+ |
+
+ Zenith angle.
+ |
+
+
+
+
+ winDir
+ |
+
+ rad
+ |
+
+ Wind direction.
+ |
+
+
+
+
+ winSpe
+ |
+
+ m/s
+ |
+
+ Wind speed.
+ |
+
+
+
+ Adding new weather data
+
+ To add new weather data, proceed as follows:
+
+ -
+ Download the weather data file with the
epw extension from
+
+ http://energyplus.net/weather.
+
+ -
+ Add the file to
AixLib/Resources/weatherdata (or to any directory
+ for which you have write permission).
+
+ -
+ On a console window, type
+ cd AixLib/Resources/weatherdata
+ java -jar ../bin/ConvertWeatherData.jar inputFile.epw
+
+ if inputFile contains space in the name:
+
+ java -jar ../bin/ConvertWeatherData.jar \"inputFile .epw\"
+
+ This will generate the weather data file inputFile.mos, which can be read
+ by the model
+
+ AixLib.BoundaryConditions.WeatherData.ReaderTMY3.
+
+
+
+ Location data that are read automatically from the weather data file
- Note that these three models are identical, except for the pipe model that is used:
+ The following location data are automatically read from the weather file:
+
+ Wet bulb temperature
- This comparison between different discretization levels and pipe models is made
- to check the influence of the discretization and pipe model on computation time
- and simulation accuracy.
-
- The pipes' temperatures are not initialized, thus results of outflow temperature
- before approximately the first 10000 seconds should not be considered.
-
- Test bench schematic
-
- Calibration
-
- To calculate the length specific thermal resistance R of the pipe,
- the thermal resistance of the surrounding ground is added.
-
-
- R=1/(0.208)+1/(2 lambdag Modelica.Constants.pi) log(1/0.18)
+ By default, the data bus contains the wet bulb temperature.
+ This introduces a nonlinear equation.
+ However, we have not observed an increase in computing time because
+ of this equation.
+ To disable the computation of the wet bulb temperature, set
+ computeWetBulbTemperature=false.
+
+ Using constant or user-defined input signals for weather data
- Where the thermal conductivity of the ground lambda_g = 2.4 W/(m K).
+ This model has the option of using a constant value, using the data from the weather file,
+ or using data from an input connector for the following variables:
-
-
- March 7, 2020, by Michael Wetter:
- Replaced measured data from specification in Modelica file to external table,
- as this reduces the computing time.
- This is for
- #1289.
+ The atmospheric pressure,
-
- May 15, 2019, by Jianjun Hu:
- Replaced fluid source. This is for
- #1072.
+ the ceiling height,
- - November 28, 2016 by Bram van der Heijde:
Remove pipVol.
+ -
+ the total sky cover,
-
- August 24, 2016 by Bram van der Heijde:
- Implement validation with MSL pipes for comparison, based on AIT validation.
+ the opaque sky cover,
-
- July 4, 2016 by Bram van der Heijde:
Added parameters to test the
- influence of allowFlowReversal and the presence of explicit volumes in the pipe.
+ the dry bulb temperature,
+
+ -
+ the dew point temperature,
+
+ -
+ the sky black body temperature,
+
+ -
+ the relative humidity,
+
+ -
+ the wind direction,
+
+ -
+ the wind speed,
+
+ -
+ the global horizontal radiation, direct normal and diffuse horizontal radiation,
+ and
+
+ -
+ the infrared horizontal radiation.
- - January 26, 2016 by Carles Ribas:
First implementation.
-
--------- Corrected Code --------
-
- The example contains
- experimental data from a real district heating network. This data
- is used to validate this library's plug flow
- pipe model in
- AixLib.Fluid.FixedResistances.Validation.PlugFlowPipes.PlugFlowAIT.
-
-
- Note that these three models are identical, except for the pipe model
- that is used:
-
-
-
- This comparison between different discretization levels and pipe
- models is made to check the influence of the discretization and pipe
- model on computation time and simulation accuracy.
-
-
- The pipes' temperatures are not initialized, thus results of outflow
- temperature before approximately the first 10000 seconds should not
- be considered.
-
-
- Test bench schematic
-
-
-
-
-
- Calibration
-
-
- To calculate the length specific thermal resistance R of
- the pipe, the thermal resistance of the surrounding ground is added.
-
-
- R=1/(0.208)+1/(2 lambdag Modelica.Constants.pi)
- log(1/0.18)
-
-
- Where the thermal conductivity of the ground lambda_g =
- 2.4 W/(m K).
-
-
- - March 7, 2020, by Michael Wetter:
- Replaced measured data from specification in Modelica file to
- external table, as this reduces the computing time.
- This is for #1289.
-
- - May 15, 2019, by Jianjun Hu:
- Replaced fluid source. This is for #1072.
-
- - November 28, 2016 by Bram van der Heijde:
- Remove pipVol.
-
- - August 24, 2016 by Bram van der Heijde:
- Implement validation with MSL pipes for comparison, based on AIT
- validation.
-
- - July 4, 2016 by Bram van der Heijde:
- Added parameters to test the influence of allowFlowReversal and the
- presence of explicit volumes in the pipe.
-
- - January 26, 2016 by Carles Ribas:
- First implementation.
-
-
-
--------- Errors --------
-line 51 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Media/Specialized/Water/TemperatureDependentDensity.mo ----
--------- HTML Code --------
-
-
- Base properties of the medium.
-
-
- This function computes the density as a function of temperature.
+ By default, all data are obtained from the weather data file,
+ except for the atmospheric pressure, which is set to the
+ parameter pAtm=101325 Pascals.
+
+
+ The parameter *Sou configures the source of the data.
+ For the atmospheric pressure, temperatures, relative humidity, wind speed and wind direction,
+ the enumeration
+
+ AixLib.BoundaryConditions.Types.DataSource
+ is used as follows:
+
+
+
+
+ Parameter *Sou
+ |
+ Data used to compute weather data.
+ |
+
+
+
+ |
+ File
+ |
+
+ Use data from file.
+ |
+
+
+
+ |
+ Parameter
+ |
+
+ Use value specified by the parameter.
+ |
+
+
+
+ |
+ Input
+ |
+
+ Use value from the input connector.
+ |
+
+
+
+ Because global, diffuse and direct radiation are related to each other, the parameter
+ HSou is treated differently.
+ It is set to a value of the enumeration
+
+ AixLib.BoundaryConditions.Types.RadiationDataSource,
+ and allows the following configurations:
+
+
+
+
+ Parameter HSou
+ |
+ Data used to compute weather data.
+ |
+
+
+
+ |
+ File
+ |
+
+ Use data from file.
+ |
+
+
+
+ |
+ Input_HGloHor_HDifHor
+ |
+
+ Use global horizontal and diffuse horizontal radiation from input connector.
+ |
+
+
+ |
+ Input_HDirNor_HDifHor
+ |
+
+ Use direct normal and diffuse horizontal radiation from input connector.
+ |
+
+
+ |
+ Input_HDirNor_HGloHor
+ |
+
+ Use direct normal and global horizontal radiation from input connector.
+ |
+
+
+
+ Length of weather data and simulation period
+
+ If weather data span a year, which is the default for TMY3 data, or multiple years,
+ then this model can be used for simulations that span multiple years. The simulation
+ start time needs to be set to the clock time of the respective start time. For example,
+ to start at January 2 at 10am, set start time to t=(24+10)*3600 seconds.
+ For this computation, the used date and time (here January 2, 10 am) must be expressed in the same time zone
+ as the one that is used to define the TMY3 file. This is usually the local (winter) time zone.
+ The parameter `timZon` represents the TMY3 file time zone, expressed in seconds compared to UTC.
- Implementation
- The function is based on the IDA implementation in therpro.nmf, which
- implements
+ Moreover, weather data need not span a whole year, or it can span across New Year.
+ In this case, the simulation cannot exceed the time of the weather data file. Otherwise,
+ the simulation stops with an error.
-
- d := 1000.12 + 1.43711e-2*T_degC -
- 5.83576e-3*T_degC^2 + 1.5009e-5*T_degC^3;
-
- This has been converted to Kelvin, which resulted in the above expression.
- In addition, below 5 °C and above 100 °C, the density is replaced
- by a linear function to avoid inflection points.
- This linear extension is such that the density is once continuously differentiable.
+ As weather data have one entry at the start of the time interval, the end time of the weather
+ data file is computed as the last time entry plus the average time increment of the file.
+ For example, an hourly weather data file has 8760 entries, starting on January 1 at 0:00.
+ The last entry in the file will be for December 31 at 23:00. As the time increment is 1 hour,
+ the model assumes the weather file to end at December 31 at 23:00 plus 1 hour, e.g., at January 1 at 0:00.
-
-
+
+ Notes
+
-
- December 18, 2013, by Michael Wetter:
- First implementation, based on the IDA implementation in therpro.nmf,
- but converted from Celsius to Kelvin and linearly extended.
-
-
-
- This function computes the dynamic viscosity.
+ In HVAC systems, when the fan is off, changes in atmospheric pressure can cause small air flow rates
+ in the duct system due to change in pressure and hence in the mass of air that is stored
+ in air volumes (such as in fluid junctions or in the room model).
+ This may increase computing time. Therefore, the default value for the atmospheric pressure is set to a constant.
+ Furthermore, if the initial pressure of air volumes are different
+ from the atmospheric pressure, then fast pressure transients can happen in the first few seconds of the simulation.
+ This can cause numerical problems for the solver. To avoid this problem, set the atmospheric pressure to the
+ same value as the medium default pressure, which is typically set to the parameter Medium.p_default.
+ For medium models for moist air and dry air, the default is
+ Medium.p_default=101325 Pascals.
-
-
- -
- December 2, 2013, by Michael Wetter:
- First implementation.
-
-
+ -
- This function computes the specific enthalpy.
+ Different units apply depending on whether data are obtained from a file, or
+ from a parameter or an input connector:
-
-
- December 11, 2013, by Michael Wetter:
- First implementation.
+ When using TMY3 data from a file (e.g. USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.mos), the units must be the same as the original TMY3 file used by EnergyPlus (e.g.
+ USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.epw).
+ The TMY3 data used by EnergyPlus are in both SI units and non-SI units.
+ If Resources/bin/ConvertWeatherData.jar is used to convert the .epw file to an .mos file, the units of the TMY3 data are preserved and the file can be directly
+ used by this data reader.
+ The data reader will automatically convert units to the SI units used by Modelica.
+ For example, the dry bulb temperature TDryBul in TMY3 is in degree Celsius.
+ The data reader will automatically convert the data to Kelvin.
+ The wind direction winDir in TMY3 is degrees and will be automatically converted to radians.
+
+ -
+ When using data from a parameter or from an input connector,
+ the data must be in the SI units used by Modelica.
+ For instance, the unit must be
+
Pa for pressure,
+ K for temperature,
+ W/m2 for solar radiations and
+ rad for wind direction.
-
+
+ -
- This function computes the specific enthalpy of liquid water.
+ Hourly and subhourly timestamp are handled in a different way in .epw files.
+ From the EnergyPlus Auxiliary Programs Document (v9.3.0, p. 63):
+ In hourly data the minute field can be 00 or 60. In this case as mentioned in the previous section, the weather data
+ is reported at the hourly value and the minute field has to be ignored, writing 1, 60 or 1, 00 is equivalent.
+ If the minute field is between 00 and 60, the file becomes subhourly, in this case the timestamp corresponds to the
+ minute field in the considered hour. For example: 1, 30 is equivalent to 00:30 and 3, 45 is equivalent to 02:45.
+ (Note the offset in the hour digit.)
-
-
-
- December 2, 2013, by Michael Wetter:
- First implementation.
+ The ReaderTMY3 should only be used with TMY3 data. It contains a time shift for solar radiation data
+ that is explained below. This time shift needs to be removed if the user may want to
+ use the ReaderTMY3 for other weather data types.
-
-
+
+ Implementation
+ Start and end data for annual weather data files
- This function computes the specific internal energy.
+ The TMY3 weather data, as well as the EnergyPlus weather data, start at 1:00 AM
+ on January 1, and provide hourly data until midnight on December 31.
+ Thus, the first entry for temperatures, humidity, wind speed etc. are values
+ at 1:00 AM and not at midnight. Furthermore, the TMY3 weather data files can have
+ values at midnight of December 31 that may be significantly different from the values
+ at 1:00 AM on January 1.
+ Since annual simulations require weather data that start at 0:00 on January 1,
+ data need to be provided for this hour. Due to the possibly large change in
+ weatherdata between 1:00 AM on January 1 and midnight at December 31,
+ the weather data files in the AixLib library do not use the data entry from
+ midnight at December 31 as the value for t=0. Rather, the
+ value from 1:00 AM on January 1 is duplicated and used for 0:00 on January 1.
+ To maintain a data record with 8760 hours, the weather data record from
+ midnight at December 31 is deleted.
+ These changes in the weather data file are done in the Java program
+ AixLib/Resources/bin/ConvertWeatherData.jar that converts
+ EnergyPlus weather data file to Modelica weather data files, and which is described
+ above.
+ The length of the weather data is calculated as the
+ end time stamp minus start time stamp plus average increment, where the
+ average increment is equal to the end time stamp minus start time stamp divided
+ by the number of rows minus 1.
+ This only works correctly for weather files with equidistant time stamps.
+ Time shift for solar radiation data
+
+ To read weather data from the TMY3 weather data file, there are
+ two data readers in this model. One data reader obtains all data
+ except solar radiation, and the other data reader reads only the
+ solar radiation data, shifted by 30 minutes.
+ The reason for this time shift is as follows:
+ The TMY3 weather data file contains for solar radiation the
+ \"...radiation received
+ on a horizontal surface during
+ the 60-minute period ending at
+ the timestamp.\"
+ Thus, as the figure below shows, a more accurate interpolation is obtained if
+ time is shifted by 30 minutes prior to reading the weather data.
+
+
+
+
+ References
-
- December 11, 2013, by Michael Wetter:
- First implementation.
+ Wilcox S. and W. Marion. Users Manual for TMY3 Data Sets.
+ Technical Report, NREL/TP-581-43156, revised May 2008.
-
- This function computes the specific entropy.
-
-
- To obtain the state for a given pressure, entropy and mass fraction, use
-
- AixLib.Media.Air.setState_psX.
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ September 6, 2021, by Ettore Zanetti:
+ Changed alt and lat to real inputs.
+ This is for
+ IBPSA, #1477.
+
+ -
+ May 2, 2021, by Ettore Zanetti:
+ Added altitude to parameters.
+ This is for
+ IBPSA, #1477.
+
+ -
+ October 4, 2020, by Ettore Zanetti:
+ Updated documentation for Java weather file generator.
+ This is for
+ #1396.
+
+ -
+ August 20, 2019, by Filip Jorissen:
+ Better clarified the meaning of time in the documentation.
+ This is for
+ #1192.
+
+ -
+ March 5, 2019, by Michael Wetter:
+ Updated documentation.
+ This is for
+ #842.
+
+ -
+ September 20, 2018, by Michael Wetter:
+ Corrected documentation.
+ This is for
+ #1022.
+
+ -
+ December 4, 2017, by Michael Wetter:
+ Removed function call to getAbsolutePath, as this causes in Dymola 2018FD01
+ the error
+ \"A call of loadResource with a non-literal string remains in the generated code; it will not work for an URI.\"
+ when exporting
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZone
+ as an FMU. Instead, if the weather file is specified as a Modelica, URI, syntax such as
+ Modelica.Utilities.Files.loadResource(\"modelica://AixLib/Resources/weatherdata/USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.mos\")
+ should be used.
+ This is for
+ #867.
+
+ -
+ February 18, 2017, by Filip Jorissen:
+ Infrared radiation on horizontal surface is now delayed by 30 minutes
+ such that the results in
+ TBlaSky
+ are consistent.
+ This is for
+ #648.
+
+ -
+ December 06, 2016, by Thierry S. Nouidui:
+ Constrained the direct normal radiation to not be bigger than the solar constant when using
+ global and diffuse solar radiation data provided via the inputs connectors.
+ This is for
+ #608.
+
+ -
+ April 21, 2016, by Michael Wetter:
+ Introduced absFilNam to avoid multiple calls to
+
+ AixLib.BoundaryConditions.WeatherData.BaseClasses.getAbsolutePath.
+ This is for
+ Buildings, #506.
+
+ -
+ January 6, 2016, by Moritz Lauster:
+ Changed output radHorIR to HHorIR.
+ This is for
+ #376.
+
+ -
+ January 4, 2016, by Moritz Lauster:
+ Added a table in documentation with output variables accessible via weaBus.
+ This is for
+ #376.
+
+ -
+ December 15, 2015, by Michael Wetter:
+ Added the block cheTemBlaSky. This also allows to graphically
+ connect the black body sky temperature to the weather bus, which is required
+ in Dymola 2016 for the variable weaBus.TBlaSky to appear
+ in the graphical editor.
+ This is for
+ #377.
-
-
-
- This function computes the specific Gibbs energy.
-
-
-
-
- December 2, 2013, by Michael Wetter:
- First implementation.
+ September 24, 2015, by Marcus Fuchs:
+ Replace Dymola specific annotation by loadSelector
+ for MSL compliancy as reported by @tbeu at
+ RWTH-EBC/AixLib#107
-
-
-
- This function computes the specific Helmholtz energy.
-
-
-
-
-
- This function computes the specific enthalpy for
- an isentropic state change from the temperature
- that corresponds to the state refState
- to reference_T.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ March 26, 2015, by Michael Wetter:
+ Added option to obtain the black body sky temperature
+ from a parameter or an input signal.
-
-
-
- This function returns the isobaric expansion coefficient,
-
-
- βp = - 1 ⁄ v (∂ v ⁄ ∂ T)p,
-
-
- where
- v is the specific volume,
- T is the temperature and
- p is the pressure.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ October 17, 2014, by Michael Wetter:
+ Corrected error that led the total and opaque sky cover to be ten times
+ too low if its value was obtained from the parameter or the input connector.
+ For the standard configuration in which the sky cover is obtained from
+ the weather data file, the model was correct. This error only affected
+ the other two possible configurations.
-
-
-
- This function returns the isothermal compressibility coefficient,
- which is zero as this medium is incompressible.
- The isothermal compressibility is defined as
-
-
- κT = - 1 ⁄ v (∂ v ⁄ ∂ p)T,
-
-
- where
- v is the specific volume,
- T is the temperature and
- p is the pressure.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ September 12, 2014, by Michael Wetter:
+ Removed redundant connection connect(conHorRad.HOut, cheHorRad.HIn);.
-
-
-
- This function returns the partial derivative of density
- with respect to pressure at constant temperature,
- which is zero as the medium is incompressible.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ May 30, 2014, by Michael Wetter:
+ Removed undesirable annotation Evaluate=true.
-
-
-
- This function computes the derivative of density with respect to temperature
- at constant pressure.
-
-
-
-
- August 17, 2015, by Michael Wetter:
- Removed dublicate entry of smooth and smoothOrder.
- This is for
- issue 303.
+ May 5, 2013, by Thierry S. Nouidui:
+ Added the option to use a constant, an input signal or the weather file as the source
+ for the ceiling height, the total sky cover, the opaque sky cover, the dew point temperature,
+ and the infrared horizontal radiation HInfHor.
-
- December 18, 2013, by Michael Wetter:
- First implementation, based on the IDA implementation in therpro.nmf,
- but converted from Celsius to Kelvin.
+ October 8, 2013, by Michael Wetter:
+ Improved the algorithm that determines the absolute path of the file.
+ Now weather files are searched in the path specified, and if not found, the urls
+ file://, modelica:// and modelica://AixLib
+ are added in this order to search for the weather file.
+ This allows using the data reader without having to specify an absolute path,
+ as long as the AixLib library
+ is on the MODELICAPATH.
+ This change was implemented in
+
+ AixLib.BoundaryConditions.WeatherData.BaseClasses.getAbsolutePath
+ and improves this weather data reader.
-
-
-
- This function returns the partial derivative of density
- with respect to mass fraction,
- which is zero as the medium is a single substance.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ May 2, 2013, by Michael Wetter:
+ Added function call to getAbsolutePath.
-
-
-
- This function returns the specific heat capacity at constant pressure.
-
-
-
-
- December 11, 2013, by Michael Wetter:
- First implementation.
+ October 16, 2012, by Michael Wetter:
+ Added computation of the wet bulb temperature.
+ Computing the wet bulb temperature introduces a nonlinear
+ equation. As we have not observed an increase in computing time
+ because of computing the wet bulb temperature, it is computed
+ by default. By setting the parameter
+ computeWetBulbTemperature=false, the computation of the
+ wet bulb temperature can be removed.
+ Revised documentation.
-
-
-
- This function computes the specific heat capacity at constant volume.
-
-
-
-
- December 11, 2013, by Michael Wetter:
- First implementation.
+ August 11, 2012, by Wangda Zuo:
+ Renamed radHor to radHorIR and
+ improved the optional inputs for radiation data.
-
-
-
- This function returns the thermal conductivity.
- The expression is obtained from Ramires et al. (1995).
-
- References
-
- Ramires, Maria L. V. and Nieto de Castro, Carlos A. and Nagasaka, Yuchi
- and Nagashima, Akira and Assael, Marc J. and Wakeham, William A.
- Standard Reference Data for the Thermal Conductivity of Water.
- Journal of Physical and Chemical Reference Data, 24, p. 1377-1381, 1995.
- DOI:10.1063/1.555963.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ July 24, 2012, by Wangda Zuo:
+ Corrected the notes of SI unit requirements for input files.
-
-
-
- This function returns the pressure.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ July 13, 2012, by Michael Wetter:
+ Removed assignment of HGloHor_in in its declaration,
+ because this gives an overdetermined system if the input connector
+ is used.
+ Removed non-required assignments of attribute displayUnit.
-
-
-
- This function returns the temperature.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ February 25, 2012, by Michael Wetter:
+ Added subbus for solar position, which is needed by irradition and
+ shading model.
-
-
-
- This function returns the molar mass,
- which is assumed to be constant.
-
-
-
-
- December 18, 2013, by Michael Wetter:
- First implementation.
+ November 29, 2011, by Michael Wetter:
+ Fixed wrong display unit for pAtm_in_internal and
+ made propagation of parameter final.
+
+ -
+ October 27, 2011, by Wangda Zuo:
+
+ -
+ Added optional connectors for dry bulb temperature, relative humidity, wind speed, wind direction, global horizontal radiation, diffuse horizontal radiation.
-
-
-
- This function returns the thermodynamic state for a given pressure,
- specific enthalpy and composition.
-
-
-
-
- December 11, 2013, by Michael Wetter:
- First implementation.
+ Separate the unit conversion for TMY3 data and data validity check.
+
+
-
-
-
- This function returns the thermodynamic state for a given pressure,
- temperature and composition.
-
-
-
-
- December 11, 2013, by Michael Wetter:
- First implementation.
+ October 3, 2011, by Michael Wetter:
+ Propagated value for sky temperature calculation to make it accessible as a parameter.
-
-
-
- This function returns the thermodynamic state based on pressure,
- specific entropy and mass fraction.
-
-
- The state is computed by symbolically solving
-
- AixLib.Media.Specialized.Water.TemperatureDependentDensity.specificEntropy
- for temperature.
-
-
-
-
- April 11, 2016 by Michael Wetter:
- Corrected wrong hyperlink in documentation for
- issue 450.
+ July 20, 2011, by Michael Wetter:
+ Added the option to use a constant, an input signal or the weather file as the source
+ for the atmospheric pressure.
+ -
+ March 15, 2011, by Wangda Zuo:
+ Delete the wet bulb temperature since it may cause numerical problem.
-
- December 11, 2013, by Michael Wetter:
- First implementation.
+ March 7, 2011, by Wangda Zuo:
+ Added wet bulb temperature. Changed reader to read only needed columns.
+ Added explanation for 30 minutes shift for radiation data.
-
-
-
- This function computes the derivative of the specific heat capacity
- at constant pressure with respect to the state.
-
-
-
-
- December 11, 2013, by Michael Wetter:
- First implementation.
+ March 5, 2011, by Michael Wetter:
+ Changed implementation to obtain longitude and time zone directly
+ from weather file.
-
-
-
- This function computes the temperature derivative of the enthalpy of liquid water
- per unit mass.
-
-
-
-
- December 11, 2013, by Michael Wetter:
+ June 25, 2010, by Wangda Zuo:
First implementation.
-
- This function computes the kinematic viscosity as a function of temperature.
-
- Implementation
-
- The function is based on the IDA implementation in therpro.nmf.
- The original equation is
-
-
- kinVis :=1E-6*Modelica.Math.exp(0.577449 - 3.253945e-2*T_degC + 2.17369e-4*
- T_degC^2 - 7.22111e-7*T_degC^3);
-
-
- This has been converted to Kelvin, which resulted in the above expression.
- In addition, at 5 °C the kinematic viscosity is linearly extrapolated
- to avoid a large gradient at very low temperatures.
- We selected the same point for the linearization as we used for the density,
- as the density and the kinematic viscosity are combined in
-
- AixLib.Media.Specialized.Water.TemperatureDependentDensity.dynamicViscosity.
-
-
+-------- Corrected Code --------
+
+ Block to output the latitude of the location. This block is added so
+ that the latitude is displayed with a comment in the GUI of the
+ weather bus connector.
+
+
+ Implementation
+
+
+ If Modelica.Blocks.Sources.Constant
+ where used, then the comment for the latitude would be \"Connector of
+ Real output signal\". As this documentation string cannot be
+ overwritten, a new block was implemented.
+
+
+ - January 4, 2016, by Michael Wetter:
+ First implementation.
+
+
+
+ Block to output the longitude of the location. This block is added so
+ that the longitude is displayed with a comment in the GUI of the
+ weather bus connector.
+
+
+ Implementation
+
+
+ If Modelica.Blocks.Sources.Constant
+ where used, then the comment for the longitude would be \"Connector of
+ Real output signal\". As this documentation string cannot be
+ overwritten, a new block was implemented.
+
+
+ - January 4, 2016, by Michael Wetter:
+ First implementation.
+
+
+
+ Block to output the altitude of the location. This block is added so
+ that the altitude is displayed with a comment in the GUI of the
+ weather bus connector.
+
+
+ Implementation
+
+
+ If Modelica.Blocks.Sources.Constant
+ where used, then the comment for the Altitude would be \"Connector of
+ Real output signal\". As this documentation string cannot be
+ overwritten, a new block was implemented.
+
+
+ - May 2, 2021, by Ettore Zanetti:
+ First implementation.
+
+
+
+ This component reads TMY3 weather data (Wilcox and Marion, 2008) or
+ user specified weather data. The Modelica built-in variable
+ time determines what row of the weather file is read.
+ The value of time is the number of seconds that have
+ passed since January 1st at midnight (00:00) in the local time zone.
+ The local time zone value, longitude and latitute are also read from
+ the weather data, such that the solar position computations are
+ consistent with the weather data.
+
+
+ The weather data format is the Typical Meteorological Year (TMY3) as
+ obtained from the EnergyPlus web site at http://energyplus.net/weather.
+ These data, which are in the EnergyPlus format, need to be converted
+ as described below.
+
+
+ Output to weaBus
+
+
+ The following variables serve as output and are accessible via
+ weaBus:
+
+
+
+
+ |
+ Name
+ |
+
+ Unit
+ |
+
+ Description
+ |
+
+
+
+ HDifHor
+ |
+
+ W/m2
+ |
+
+ Horizontal diffuse solar radiation.
+ |
+
+
+
+ HDifNor
+ |
+
+ W/m2
+ |
+
+ Direct normal radiation.
+ |
+
+
+
+ HGloHor
+ |
+
+ W/m2
+ |
+
+ Horizontal global radiation.
+ |
+
+
+
+ HHorIR
+ |
+
+ W/m2
+ |
+
+ Horizontal infrared irradiation.
+ |
+
+
+
+ TBlaSky
+ |
+
+ K
+ |
+
+ Output temperature.
+ |
+
+
+
+ TDewPoi
+ |
+
+ K
+ |
+
+ Dew point temperature.
+ |
+
+
+
+ TDryBul
+ |
+
+ K
+ |
+
+ Dry bulb temperature at ground level.
+ |
+
+
+
+ TWetBul
+ |
+
+ K
+ |
+
+ Wet bulb temperature.
+ |
+
+
+
+ celHei
+ |
+
+ m
+ |
+
+ Ceiling height.
+ |
+
+
+
+ cloTim
+ |
+
+ s
+ |
+
+ One-based day number in seconds.
+ |
+
+
+
+ lat
+ |
+
+ rad
+ |
+
+ Latitude of the location.
+ |
+
+
+
+ lon
+ |
+
+ rad
+ |
+
+ Longitude of the location.
+ |
+
+
+
+ nOpa
+ |
+
+ 1
+ |
+
+ Opaque sky cover [0, 1].
+ |
+
+
+
+ nTot
+ |
+
+ 1
+ |
+
+ Total sky Cover [0, 1].
+ |
+
+
+
+ pAtm
+ |
+
+ Pa
+ |
+
+ Atmospheric pressure.
+ |
+
+
+
+ relHum
+ |
+
+ 1
+ |
+
+ Relative humidity.
+ |
+
+
+
+ solAlt
+ |
+
+ rad
+ |
+
+ Altitude angle.
+ |
+
+
+
+ solDec
+ |
+
+ rad
+ |
+
+ Declination angle.
+ |
+
+
+
+ solHouAng
+ |
+
+ rad
+ |
+
+ Solar hour angle.
+ |
+
+
+
+ solTim
+ |
+
+ s
+ |
+
+ Solar time.
+ |
+
+
+
+ solZen
+ |
+
+ rad
+ |
+
+ Zenith angle.
+ |
+
+
+
+ winDir
+ |
+
+ rad
+ |
+
+ Wind direction.
+ |
+
+
+
+ winSpe
+ |
+
+ m/s
+ |
+
+ Wind speed.
+ |
+
+
+
+ Adding new weather data
+
+
+ To add new weather data, proceed as follows:
+
+
+ - Download the weather data file with the
epw
+ extension from http://energyplus.net/weather.
+
+ - Add the file to
AixLib/Resources/weatherdata (or to
+ any directory for which you have write permission).
+
+ - On a console window, type
+
+ cd AixLib/Resources/weatherdata
+ java -jar ../bin/ConvertWeatherData.jar inputFile.epw
+ if inputFile contains space in the name:
+
+ java -jar ../bin/ConvertWeatherData.jar \"inputFile .epw\"
+ This will generate the weather data file
+inputFile.mos, which can be read by the model AixLib.BoundaryConditions.WeatherData.ReaderTMY3.
+
+
+
+ Location data that are read automatically from the weather data file
+
+
+ The following location data are automatically read from the weather
+ file:
+
+
+ - The latitude of the weather station,
lat,
+
+ - the longitude of the weather station,
lon, and
+
+ - the time zone relative to Greenwich Mean Time,
+
timZone.
+
+
+
+ Wet bulb temperature
+
+
+ By default, the data bus contains the wet bulb temperature. This
+ introduces a nonlinear equation. However, we have not observed an
+ increase in computing time because of this equation. To disable the
+ computation of the wet bulb temperature, set
+ computeWetBulbTemperature=false.
+
+
+ Using constant or user-defined input signals for weather data
+
+
+ This model has the option of using a constant value, using the data
+ from the weather file, or using data from an input connector for the
+ following variables:
+
+
+ - The atmospheric pressure,
+
+ - the ceiling height,
+
+ - the total sky cover,
+
+ - the opaque sky cover,
+
+ - the dry bulb temperature,
+
+ - the dew point temperature,
+
+ - the sky black body temperature,
+
+ - the relative humidity,
+
+ - the wind direction,
+
+ - the wind speed,
+
+ - the global horizontal radiation, direct normal and diffuse
+ horizontal radiation, and
+
+ - the infrared horizontal radiation.
+
+
+
+ By default, all data are obtained from the weather data file, except
+ for the atmospheric pressure, which is set to the parameter
+ pAtm=101325 Pascals.
+
+
+ The parameter *Sou configures the source of the data.
+ For the atmospheric pressure, temperatures, relative humidity, wind
+ speed and wind direction, the enumeration AixLib.BoundaryConditions.Types.DataSource
+ is used as follows:
+
+
+
+
+
+ Parameter *Sou
+ |
+
+ Data used to compute weather data.
+ |
+
+
+ |
+ File
+ |
+
+ Use data from file.
+ |
+
+
+ |
+ Parameter
+ |
+
+ Use value specified by the parameter.
+ |
+
+
+ |
+ Input
+ |
+
+ Use value from the input connector.
+ |
+
+
+
+ Because global, diffuse and direct radiation are related to each
+ other, the parameter HSou is treated differently. It is
+ set to a value of the enumeration AixLib.BoundaryConditions.Types.RadiationDataSource,
+ and allows the following configurations:
+
+
+
+
+
+ Parameter HSou
+ |
+
+ Data used to compute weather data.
+ |
+
+
+ |
+ File
+ |
+
+ Use data from file.
+ |
+
+
+ |
+ Input_HGloHor_HDifHor
+ |
+
+ Use global horizontal and diffuse horizontal radiation from input
+ connector.
+ |
+
+
+ |
+ Input_HDirNor_HDifHor
+ |
+
+ Use direct normal and diffuse horizontal radiation from input
+ connector.
+ |
+
+
+ |
+ Input_HDirNor_HGloHor
+ |
+
+ Use direct normal and global horizontal radiation from input
+ connector.
+ |
+
+
+
+ Length of weather data and simulation period
+
+
+ If weather data span a year, which is the default for TMY3 data, or
+ multiple years, then this model can be used for simulations that span
+ multiple years. The simulation start time needs to be set to the
+ clock time of the respective start time. For example, to start at
+ January 2 at 10am, set start time to t=(24+10)*3600
+ seconds. For this computation, the used date and time (here January
+ 2, 10 am) must be expressed in the same time zone as the one that is
+ used to define the TMY3 file. This is usually the local (winter) time
+ zone. The parameter `timZon` represents the TMY3 file time zone,
+ expressed in seconds compared to UTC.
+
+
+ Moreover, weather data need not span a whole year, or it can span
+ across New Year. In this case, the simulation cannot exceed the time
+ of the weather data file. Otherwise, the simulation stops with an
+ error.
+
+
+ As weather data have one entry at the start of the time interval, the
+ end time of the weather data file is computed as the last time entry
+ plus the average time increment of the file. For example, an hourly
+ weather data file has 8760 entries, starting on January 1 at 0:00.
+ The last entry in the file will be for December 31 at 23:00. As the
+ time increment is 1 hour, the model assumes the weather file to end
+ at December 31 at 23:00 plus 1 hour, e.g., at January 1 at 0:00.
+
+
+ Notes
+
+
+ -
+
+ In HVAC systems, when the fan is off, changes in atmospheric
+ pressure can cause small air flow rates in the duct system due to
+ change in pressure and hence in the mass of air that is stored in
+ air volumes (such as in fluid junctions or in the room model).
+ This may increase computing time. Therefore, the default value
+ for the atmospheric pressure is set to a constant. Furthermore,
+ if the initial pressure of air volumes are different from the
+ atmospheric pressure, then fast pressure transients can happen in
+ the first few seconds of the simulation. This can cause numerical
+ problems for the solver. To avoid this problem, set the
+ atmospheric pressure to the same value as the medium default
+ pressure, which is typically set to the parameter
+ Medium.p_default. For medium models for moist air
+ and dry air, the default is Medium.p_default=101325
+ Pascals.
+
+
+ -
+
+ Different units apply depending on whether data are obtained from
+ a file, or from a parameter or an input connector:
+
+
+ - When using TMY3 data from a file (e.g.
+
USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.mos), the
+ units must be the same as the original TMY3 file used by
+ EnergyPlus (e.g.
+ USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.epw). The
+ TMY3 data used by EnergyPlus are in both SI units and non-SI
+ units. If Resources/bin/ConvertWeatherData.jar is
+ used to convert the .epw file to an
+ .mos file, the units of the TMY3 data are preserved
+ and the file can be directly used by this data reader. The data
+ reader will automatically convert units to the SI units used by
+ Modelica. For example, the dry bulb temperature
+ TDryBul in TMY3 is in degree Celsius. The data
+ reader will automatically convert the data to Kelvin. The wind
+ direction winDir in TMY3 is degrees and will be
+ automatically converted to radians.
+
+ - When using data from a parameter or from an input connector,
+ the data must be in the SI units used by Modelica. For instance,
+ the unit must be
Pa for pressure, K for
+ temperature, W/m2 for solar radiations and
+ rad for wind direction.
+
+
+
+ -
+
+ Hourly and subhourly timestamp are handled in a different way in
+ .epw files. From the EnergyPlus Auxiliary Programs
+ Document (v9.3.0, p. 63): In hourly data the minute field can be
+ 00 or 60. In this case as mentioned in
+ the previous section, the weather data is reported at the hourly
+ value and the minute field has to be ignored, writing 1,
+ 60 or 1, 00 is equivalent. If the minute
+ field is between 00 and 60, the file
+ becomes subhourly, in this case the timestamp corresponds to the
+ minute field in the considered hour. For example: 1,
+ 30 is equivalent to 00:30 and 3, 45 is
+ equivalent to 02:45.
+ (Note the offset in the hour digit.)
+
+
+ - The ReaderTMY3 should only be used with TMY3 data. It contains a
+ time shift for solar radiation data that is explained below. This
+ time shift needs to be removed if the user may want to use the
+ ReaderTMY3 for other weather data types.
+
+
+
+ Implementation
+
+
+ Start and end data for annual weather data files
+
+
+ The TMY3 weather data, as well as the EnergyPlus weather data, start
+ at 1:00 AM on January 1, and provide hourly data until midnight on
+ December 31. Thus, the first entry for temperatures, humidity, wind
+ speed etc. are values at 1:00 AM and not at midnight. Furthermore,
+ the TMY3 weather data files can have values at midnight of December
+ 31 that may be significantly different from the values at 1:00 AM on
+ January 1. Since annual simulations require weather data that start
+ at 0:00 on January 1, data need to be provided for this hour. Due to
+ the possibly large change in weatherdata between 1:00 AM on January 1
+ and midnight at December 31, the weather data files in the AixLib
+ library do not use the data entry from midnight at December 31 as the
+ value for t=0. Rather, the value from 1:00 AM on January 1 is
+ duplicated and used for 0:00 on January 1. To maintain a data record
+ with 8760 hours, the weather data record from midnight at
+ December 31 is deleted. These changes in the weather data file are
+ done in the Java program
+ AixLib/Resources/bin/ConvertWeatherData.jar that
+ converts EnergyPlus weather data file to Modelica weather data files,
+ and which is described above. The length of the weather data is
+ calculated as the end time stamp minus start time stamp plus average
+ increment, where the average increment is equal to the end time stamp
+ minus start time stamp divided by the number of rows minus 1. This
+ only works correctly for weather files with equidistant time stamps.
+
+
+ Time shift for solar radiation data
+
+
+ To read weather data from the TMY3 weather data file, there are two
+ data readers in this model. One data reader obtains all data except
+ solar radiation, and the other data reader reads only the solar
+ radiation data, shifted by 30 minutes. The reason for this
+ time shift is as follows: The TMY3 weather data file contains for
+ solar radiation the \"...radiation received on a horizontal surface
+ during the 60-minute period ending at the timestamp.\" Thus, as the
+ figure below shows, a more accurate interpolation is obtained if time
+ is shifted by 30 minutes prior to reading the weather data.
+
+
+
+
+
+ References
+
+
+ - Wilcox S. and W. Marion. Users Manual for TMY3 Data Sets.
+ Technical Report, NREL/TP-581-43156, revised May 2008.
+
+
+
+ - September 6, 2021, by Ettore Zanetti:
+ Changed alt and lat to real inputs.
+ This is for IBPSA,
+ #1477.
+
+ - May 2, 2021, by Ettore Zanetti:
+ Added altitude to parameters.
+ This is for IBPSA,
+ #1477.
+
+ - October 4, 2020, by Ettore Zanetti:
+ Updated documentation for Java weather file generator.
+ This is for #1396.
+
+ - August 20, 2019, by Filip Jorissen:
+ Better clarified the meaning of time in the
+ documentation.
+ This is for #1192.
+
+ - March 5, 2019, by Michael Wetter:
+ Updated documentation.
+ This is for #842.
+
+ - September 20, 2018, by Michael Wetter:
+ Corrected documentation.
+ This is for #1022.
+
+ - December 4, 2017, by Michael Wetter:
+ Removed function call to getAbsolutePath, as this
+ causes in Dymola 2018FD01 the error \"A call of loadResource with a
+ non-literal string remains in the generated code; it will not work
+ for an URI.\" when exporting
+ AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZone as
+ an FMU. Instead, if the weather file is specified as a Modelica,
+ URI, syntax such as
+ Modelica.Utilities.Files.loadResource(\"modelica://AixLib/Resources/weatherdata/USA_IL_Chicago-OHare.Intl.AP.725300_TMY3.mos\")
+ should be used.
+ This is for #867.
+
+ - February 18, 2017, by Filip Jorissen:
+ Infrared radiation on horizontal surface is now delayed by 30
+ minutes such that the results in
+ TBlaSky are consistent. This is for #648.
+
+ - December 06, 2016, by Thierry S. Nouidui:
+ Constrained the direct normal radiation to not be bigger than the
+ solar constant when using global and diffuse solar radiation data
+ provided via the inputs connectors. This is for #608.
+
+ - April 21, 2016, by Michael Wetter:
+ Introduced absFilNam to avoid multiple calls to
+
+ AixLib.BoundaryConditions.WeatherData.BaseClasses.getAbsolutePath.
+ This is for Buildings,
+ #506.
+
+ - January 6, 2016, by Moritz Lauster:
+ Changed output radHorIR to HHorIR. This
+ is for #376.
+
+ - January 4, 2016, by Moritz Lauster:
+ Added a table in documentation with output variables accessible via
+ weaBus. This is for #376.
+
+ - December 15, 2015, by Michael Wetter:
+ Added the block cheTemBlaSky. This also allows to
+ graphically connect the black body sky temperature to the weather
+ bus, which is required in Dymola 2016 for the variable
+ weaBus.TBlaSky to appear in the graphical editor. This
+ is for #377.
+
+ - September 24, 2015, by Marcus Fuchs:
+ Replace Dymola specific annotation by loadSelector for
+ MSL compliancy as reported by @tbeu at RWTH-EBC/AixLib#107
+
+ - June 6, 2015, by Michael Wetter:
+ Removed redundant but consistent connect(TBlaSkyCom.TBlaSky,
+ weaBus.TBlaSky) statement. This avoids a warning if
+ AixLib.BoundaryConditions.SolarIrradiation.BaseClasses.Examples.SkyClearness
+ is translated in pedantic mode in Dymola 2016. This is for #266.
+
+ - March 26, 2015, by Michael Wetter:
+ Added option to obtain the black body sky temperature from a
+ parameter or an input signal.
+
+ - October 17, 2014, by Michael Wetter:
+ Corrected error that led the total and opaque sky cover to be ten
+ times too low if its value was obtained from the parameter or the
+ input connector. For the standard configuration in which the sky
+ cover is obtained from the weather data file, the model was
+ correct. This error only affected the other two possible
+ configurations.
+
+ - September 12, 2014, by Michael Wetter:
+ Removed redundant connection connect(conHorRad.HOut,
+ cheHorRad.HIn);.
+
+ - May 30, 2014, by Michael Wetter:
+ Removed undesirable annotation Evaluate=true.
+
+ - May 5, 2013, by Thierry S. Nouidui:
+ Added the option to use a constant, an input signal or the weather
+ file as the source for the ceiling height, the total sky cover, the
+ opaque sky cover, the dew point temperature, and the infrared
+ horizontal radiation HInfHor.
+
+ - October 8, 2013, by Michael Wetter:
+ Improved the algorithm that determines the absolute path of the
+ file. Now weather files are searched in the path specified, and if
+ not found, the urls file://, modelica://
+ and modelica://AixLib are added in this order to
+ search for the weather file. This allows using the data reader
+ without having to specify an absolute path, as long as the
+ AixLib library is on the MODELICAPATH.
+ This change was implemented in
+ AixLib.BoundaryConditions.WeatherData.BaseClasses.getAbsolutePath
+ and improves this weather data reader.
+
+ - May 2, 2013, by Michael Wetter:
+ Added function call to getAbsolutePath.
+
+ - October 16, 2012, by Michael Wetter:
+ Added computation of the wet bulb temperature. Computing the wet
+ bulb temperature introduces a nonlinear equation. As we have not
+ observed an increase in computing time because of computing the wet
+ bulb temperature, it is computed by default. By setting the
+ parameter computeWetBulbTemperature=false, the
+ computation of the wet bulb temperature can be removed. Revised
+ documentation.
+
+ - August 11, 2012, by Wangda Zuo:
+ Renamed radHor to radHorIR and improved
+ the optional inputs for radiation data.
+
+ - July 24, 2012, by Wangda Zuo:
+ Corrected the notes of SI unit requirements for input files.
+
+ - July 13, 2012, by Michael Wetter:
+ Removed assignment of HGloHor_in in its declaration,
+ because this gives an overdetermined system if the input connector
+ is used. Removed non-required assignments of attribute
+ displayUnit.
+
+ - February 25, 2012, by Michael Wetter:
+ Added subbus for solar position, which is needed by irradition and
+ shading model.
+
+ - November 29, 2011, by Michael Wetter:
+ Fixed wrong display unit for pAtm_in_internal and made
+ propagation of parameter final.
+
+ - October 27, 2011, by Wangda Zuo:
+
+ - Added optional connectors for dry bulb temperature, relative
+ humidity, wind speed, wind direction, global horizontal
+ radiation, diffuse horizontal radiation.
+
+ - Separate the unit conversion for TMY3 data and data validity
+ check.
+
+
+
+ - October 3, 2011, by Michael Wetter:
+ Propagated value for sky temperature calculation to make it
+ accessible as a parameter.
+
+ - July 20, 2011, by Michael Wetter:
+ Added the option to use a constant, an input signal or the weather
+ file as the source for the atmospheric pressure.
+
+ - March 15, 2011, by Wangda Zuo:
+ Delete the wet bulb temperature since it may cause numerical
+ problem.
+
+ - March 7, 2011, by Wangda Zuo:
+ Added wet bulb temperature. Changed reader to read only needed
+ columns. Added explanation for 30 minutes shift for radiation data.
+
+ - March 5, 2011, by Michael Wetter:
+ Changed implementation to obtain longitude and time zone directly
+ from weather file.
+
+ - June 25, 2010, by Wangda Zuo:
+ First implementation.
+
+
+
+-------- Errors --------
+line 24 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 425 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 469 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 640 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Movers/UsersGuide.mo ----
+-------- HTML Code --------
+
+
+This package contains models for fans and pumps. The same models
+are used for fans or pumps.
+
+
+Model description
+A detailed description of the fan and pump models can be
+found in
+Wetter (2013).
+The models are implemented as described in this paper, except
+that equation (20) is no longer used. The reason is that
+the transition (24) caused the derivative
+
+
+ d Δp(r(t), V(t)) ⁄ d r(t)
+
+
+to have an inflection point in the regularization region
+r(t) ∈ (δ/2, δ).
+This caused some models to not converge.
+To correct this, for r(t) < δ,
+the term V(t) ⁄ r(t) in (16)
+has been modified so that (16) can be used for any
+value of r(t).
+
+
+Below, the models are briefly described.
+
+Performance data
+
+The models use
+performance curves that compute pressure rise,
+electrical power draw and efficiency as a function
+of the volume flow rate and the speed.
+The following performance curves are implemented:
+
+
+*Note: This record should not be used
+(i.e. use_powerCharacteristic should be false)
+for the movers that take as a control signal
+the mass flow rate or the head,
+unless also values for the record pressure are provided.
+The reason is that for these movers the record pressure
+is required to be able to compute the mover speed,
+which is required to be able to compute the electrical power
+correctly using similarity laws.
+If a Pressure record is not provided,
+the model will internally override use_powerCharacteristic=false.
+In this case the efficiency records will be used.
+Note that in this case an error is still introduced,
+but it is smaller than when using the power records.
+Compare
+
+AixLib.Fluid.Movers.Validation.PowerSimplified
+with
+
+AixLib.Fluid.Movers.Validation.PowerExact
+for an illustration of this error.
+
+
+These performance curves are implemented in
+
+AixLib.Fluid.Movers.BaseClasses.Characteristics,
+and are used in the performance records in the package
+
+AixLib.Fluid.Movers.Data.
+The package
+
+AixLib.Fluid.Movers.Data
+contains different data records.
+
+Models that use performance curves for pressure rise
+
+The models
+
+AixLib.Fluid.Movers.SpeedControlled_y and
+
+AixLib.Fluid.Movers.SpeedControlled_Nrpm
+take as an input either a control signal between 0 and 1, or the
+rotational speed in units of [1/min]. From this input and the current flow rate,
+they compute the pressure rise.
+This pressure rise is computed using a user-provided list of operating points that
+defines the fan or pump curve at full speed.
+For other speeds, similarity laws are used to scale the performance curves, as
+described in
+
+AixLib.Fluid.Movers.BaseClasses.Characteristics.pressure.
+
+
+
+For example, suppose a pump needs to be modeled whose pressure versus flow relation crosses, at
+full speed, the points shown in the table below.
+
+
+
+ | Volume flow rate [m3⁄s] |
+ Head [Pa] |
+
+
+ | 0.0003 |
+ 45000 |
+
+
+ | 0.0006 |
+ 35000 |
+
+
+ | 0.0008 |
+ 15000 |
+
+
+
+Then, a declaration would be
+
+
+ AixLib.Fluid.Movers.SpeedControlled_y pum(
+ redeclare package Medium = Medium,
+ per.pressure(V_flow={0.0003,0.0006,0.0008},
+ dp ={45,35,15}*1000))
+ \"Circulation pump\";
+
+
+
+This will model the following pump curve for the pump input signal y=1.
+
+
+
+
+
+Models that directly control the head or the mass flow rate
+
+The models
+AixLib.Fluid.Movers.FlowControlled_dp and
+
+AixLib.Fluid.Movers.FlowControlled_m_flow
+take as an input the pressure difference or the mass flow rate.
+This pressure difference or mass flow rate will be provided by the fan or pump,
+i.e., the fan or pump has idealized perfect control and infinite capacity.
+Using these models that take as an input the head or the mass flow rate often leads
+to smaller system of equations compared to using the models that take
+as an input the speed.
+
+
+These models can be configured for three different control inputs.
+For
+
+AixLib.Fluid.Movers.FlowControlled_dp,
+the head is as follows:
+
+
+-
+
+If the parameter inputType==AixLib.Fluid.Types.InputType.Continuous,
+the head is dp=dp_in, where dp_in is an input connector.
+
+
+-
+
+If the parameter inputType==AixLib.Fluid.Types.InputType.Constant,
+the head is dp=constantHead, where constantHead is a parameter.
+
+
+-
+
+If the parameter inputType==AixLib.Fluid.Types.InputType.Stages,
+the head is dp=heads, where heads is a
+vectorized parameter. For example, if a mover has
+two stages and the head of the first stage should be 60% of the nominal head
+and the second stage equal to dp_nominal, set
+heads={0.6, 1}*dp_nominal.
+Then, the mover will have the following heads:
+
+
+
+ input signal stage |
+ Head [Pa] |
+
+
+ | 0 |
+ 0 |
+
+
+ | 1 |
+ 0.6*dp_nominal |
+
+
+ | 2 |
+ dp_nominal |
+
+
+
+
+
+Similarly, for
+
+AixLib.Fluid.Movers.FlowControlled_m_flow,
+the mass flow rate is as follows:
+
+
+-
+
+If the parameter inputType==AixLib.Fluid.Types.InputType.Continuous,
+the mass flow rate is m_flow=m_flow_in, where m_flow_in is an input connector.
+
+
+-
+
+If the parameter inputType==AixLib.Fluid.Types.InputType.Constant,
+the mass flow rate is m_flow=constantMassFlowRate, where constantMassFlowRate is a parameter.
+
+
+-
+
+If the parameter inputType==AixLib.Fluid.Types.InputType.Stages,
+the mass flow rate is m_flow=massFlowRates, where massFlowRates is a
+vectorized parameter. For example, if a mover has
+two stages and the mass flow rate of the first stage should be 60% of the nominal mass flow rate
+and the second stage equal to m_flow_nominal, set
+massFlowRates={0.6, 1}*m_flow_nominal.
+Then, the mover will have the following mass flow rates:
+
+
+
+ input signal stage |
+ Mass flow rates [kg/s] |
+
+
+ | 0 |
+ 0 |
+
+
+ | 1 |
+ 0.6*m_flow_nominal |
+
+
+ | 2 |
+ m_flow_nominal |
+
+
+
+
+
+These two models do not need to use a performance curve for the flow
+characteristics.
+The reason is that
+
+-
+for given pressure rise (or mass flow rate), the mass flow rate (or pressure rise)
+is computed from the flow resistance of the duct or piping network, and
+
+-
+at zero pressure difference, solving for the flow rate and the revolution leads to a singularity.
+
+
+
+However, the computation of the electrical power consumption
+requires the mover speed to be known
+and the computation of the mover speed requires the performance
+curves for the flow and efficiency/power characteristics.
+Therefore these performance curves do need to be provided
+if the user desires a correct electrical power computation.
+If the curves are not provided, a simplified computation is used,
+where the efficiency curve is used and assumed to be correct for all speeds.
+This loss of accuracy has the advantage that it allows to use the
+mover models without requiring flow and efficiency/power characteristics.
+
+
+The model
+AixLib.Fluid.Movers.FlowControlled_dp
+has an option to control the mover such
+that the pressure difference set point is obtained
+across two remote points in the system.
+To use this functionality
+parameter prescribeSystemPressure has
+to be enabled and a differential pressure measurement
+must be connected to
+the pump input dpMea.
+This functionality is demonstrated in
+
+AixLib.Fluid.Movers.Validation.FlowControlled_dpSystem.
+
+
+The models
+AixLib.Fluid.Movers.FlowControlled_dp and
+
+AixLib.Fluid.Movers.FlowControlled_m_flow
+both have a parameter m_flow_nominal. For
+
+AixLib.Fluid.Movers.FlowControlled_m_flow, this parameter
+is used for convenience to set a default value for the parameters
+constantMassFlowRate and
+massFlowRates.
+For both models, the value is also used for the following:
+
+
+
+-
+To compute the
+size of the fluid volume that can be used to approximate the
+inertia of the mover if the energy dynamics is selected to be dynamic.
+
+-
+To compute a default pressure curve if no pressure curve has been specified
+in the record
per.pressure.
+The default pressure curve is the line that intersects
+(dp, V_flow) = (dp_nominal, 0) and
+(dp, V_flow) = (m_flow_nominal/rho_default, 0).
+
+-
+To regularize the equations near zero flow rate to ensure a numerically
+robust model.
+
+
+
+However, otherwise m_flow_nominal does not affect the mass flow rate of the mover as
+the mass flow rate is determined by the input signal or the above explained parameters.
+
+Start-up and shut-down transients
+
+All models have a parameter use_inputFilter. This
+parameter affects the fan output as follows:
+
+
+-
+If
use_inputFilter=false, then the input signal y (or
+Nrpm, m_flow_in, or dp_in)
+is equal to the fan speed (or the mass flow rate or pressure rise).
+Thus, a step change in the input signal causes a step change in the fan speed (or mass flow rate or pressure rise).
+
+-
+If
use_inputFilter=true, which is the default,
+then the fan speed (or the mass flow rate or the pressure rise)
+is equal to the output of a filter. This filter is implemented
+as a 2nd order differential equation and can be thought of as
+approximating the inertia of the rotor and the fluid.
+Thus, a step change in the fan input signal will cause a gradual change
+in the fan speed.
+The filter has a parameter riseTime, which by default is set to
+30 seconds.
+The rise time is the time required to reach 99.6% of the full speed, or,
+if the fan is switched off, to reach a fan speed of 0.4%.
+
+
+
+The figure below shows for a fan with use_inputFilter=true
+and riseTime=30 seconds the
+speed input signal and the actual speed.
+
+
+
+
+
+Although many simulations do not require such a detailed model
+that approximates the transients of fans or pumps, it turns
+out that using this filter can reduce computing time and
+can lead to fewer convergence problems in large system models.
+With a filter, any sudden change in control signal, such as when
+a fan switches on, is damped before it affects the air flow rate.
+This continuous change in flow rate turns out to be easier, and in
+some cases faster, to simulate compared to a step change.
+For most simulations, we therefore recommend to use the default settings
+of use_inputFilter=true and riseTime=30 seconds.
+An exception are situations in which the fan or pump is operated at a fixed speed during
+the whole simulation. In this case, set use_inputFilter=false.
+
+
+Note that if the fan is part of a closed loop control, then the filter affects
+the transient response of the control.
+When changing the value of use_inputFilter, the control gains
+may need to be retuned.
+We now present values control parameters that seem to work in most cases.
+Suppose there is a closed loop control with a PI-controller
+
+AixLib.Controls.Continuous.LimPID
+and a fan or pump, configured with use_inputFilter=true and riseTime=30 seconds.
+Assume that the transient response of the other dynamic elements in the control loop is fast
+compared to the rise time of the filter.
+Then, a proportional gain of k=0.5 and an integrator time constant of
+Ti=15 seconds often yields satisfactory closed loop control performance.
+These values may need to be changed for different applications as they are also a function
+of the loop gain.
+If the control loop shows oscillatory behavior, then reduce k and/or increase Ti.
+If the control loop reacts too slow, do the opposite.
+
+
+Efficiency and electrical power consumption
+
+All models compute the motor power draw Pele,
+the hydraulic power input Whyd, the flow work
+Wflo and the heat dissipated into the medium
+Q. Based on the first law, the flow work is
+
+
+ Wflo = | V̇ Δp |,
+
+
+where V̇ is the volume flow rate and
+Δp is the pressure rise.
+The heat dissipated into the medium is as follows:
+If the motor is cooled by the fluid, as indicated by
+per.motorCooledByFluid=true, then the heat dissipated into the medium is
+
+
+ Q = Pele - Wflo.
+
+
+
+If per.motorCooledByFluid=false, then the motor is outside the fluid stream,
+and only the shaft, or hydraulic, work Whyd enters the thermodynamic
+control volume. Hence,
+
+
+ Q = Whyd - Wflo.
+
+The efficiencies are computed as
+
+ η = Wflo ⁄ Pele = ηhyd ηmot
+ ηhyd = Wflo ⁄ Whyd
+ ηmot = Whyd ⁄ Pele
+
+where
+ηhyd is the hydraulic efficiency,
+ηmot is the motor efficiency and
+Q is the heat released by the motor.
+
+
+If per.use_powerCharacteristic=true,
+then a set of data points for the power Pele for different
+volume flow rates at full speed needs to be provided by the user.
+Using the flow work Wflo and the electrical power input
+Pele, the total efficiency is computed as
+
+
+ η = Wflo ⁄ Pele,
+
+
+and the two efficiencies
+ηhyd
+and ηmot are computed as
+
+
+ ηhyd = 1,
+ ηmot = η.
+
+
+However, if per.use_powerCharacteristic=false, then
+performance data for
+ηhyd and
+ ηmot need to be provided by the user, and hence
+the model computes
+
+
+ η = ηhyd ηmot
+ Pele = Wflo ⁄ η.
+
+
+
+The efficiency data for the motor are a list of points
+V̇ and ηmot.
+
+
+Fluid volume of the component
+
+All models can be configured to have a fluid volume at the low-pressure side.
+Adding such a volume sometimes helps the solver to find a solution during
+initialization and time integration of large models.
+
+
+Enthalpy change of the component
+
+If per.motorCooledByFluid=true, then
+the enthalpy change between the inlet and outlet fluid port is equal
+to the electrical power Pele that is consumed by the component.
+Otherwise, it is equal to the hydraulic work Whyd.
+The parameter addPowerToMedium, which is by default set to
+true, can be used to simplify the equations.
+If addPowerToMedium = false, then no enthalpy change occurs between
+inlet and outlet.
+This can lead to simpler equations, but the temperature rise across the component
+will be zero. In particular for fans, this simplification may not be permissible.
+
+
+Differences to models in Modelica.Fluid.Machines
+
+The models in this package differ from
+Modelica.Fluid.Machines
+primarily in the following points:
+
+
+-
+They use a different base class, which allows to have zero mass flow rate.
+The models in
Modelica.Fluid restrict the number of revolutions, and hence the flow
+rate, to be non-zero.
+
+-
+For the model with prescribed pressure, the input signal is the
+pressure difference between the two ports, and not the absolute
+pressure at
port_b.
+
+-
+The pressure calculations are based on total pressure in Pascals instead of the pump head in meters.
+This change was done to avoid ambiguities in the parameterization if the models are used as a fan
+with air as the medium. The original formulation in
+Modelica.Fluid.Machines converts head
+to pressure using the density
medium.d. Therefore, for fans,
+head would be converted to pressure using the density of air. However, for pumps,
+manufacturers typically publish the head in millimeters water (mmH2O).
+Therefore, to avoid confusion when using these models with media other than water,
+we changed the models to use total pressure in Pascals instead of head in meters.
+
+-
+The performance data are interpolated using cubic hermite splines instead of polynomials.
+These functions are implemented in
+
+AixLib.Fluid.Movers.BaseClasses.Characteristics.
+
+
+References
+
+Michael Wetter.
+
+Fan and pump model that has a unique solution for any pressure
+boundary condition and control signal.
+Proc. of the 13th Conference of the International Building Performance
+Simulation Association, p. 3505-3512. Chambery, France. August 2013.
+
+
+-------- Corrected Code --------
+
+ This package contains models for fans and pumps. The same models are
+ used for fans or pumps.
+
+
+ Model description
+
+
+ A detailed description of the fan and pump models can be found in
+
+ Wetter (2013). The models are implemented as described in this
+ paper, except that equation (20) is no longer used. The reason is
+ that the transition (24) caused the derivative
+
+
+ d Δp(r(t), V(t)) ⁄ d r(t)
+
+
+ to have an inflection point in the regularization region r(t) ∈
+ (δ/2, δ). This caused some models to not converge. To correct
+ this, for r(t) < δ, the term V(t) ⁄ r(t) in (16) has
+ been modified so that (16) can be used for any value of r(t).
+
+
+ Below, the models are briefly described.
+
+
+ Performance data
+
+
+ The models use performance curves that compute pressure rise,
+ electrical power draw and efficiency as a function of the volume flow
+ rate and the speed. The following performance curves are implemented:
+
+
+
+ *Note: This record should not be used (i.e.
+ use_powerCharacteristic should be false)
+ for the movers that take as a control signal the mass flow rate or
+ the head, unless also values for the record pressure are
+ provided. The reason is that for these movers the record
+ pressure is required to be able to compute the mover
+ speed, which is required to be able to compute the electrical power
+ correctly using similarity laws. If a Pressure record is
+ not provided, the model will internally override
+ use_powerCharacteristic=false. In this case the
+ efficiency records will be used. Note that in this case an error is
+ still introduced, but it is smaller than when using the power
+ records. Compare AixLib.Fluid.Movers.Validation.PowerSimplified
+ with AixLib.Fluid.Movers.Validation.PowerExact
+ for an illustration of this error.
+
+
+ These performance curves are implemented in AixLib.Fluid.Movers.BaseClasses.Characteristics,
+ and are used in the performance records in the package AixLib.Fluid.Movers.Data.
+ The package AixLib.Fluid.Movers.Data
+ contains different data records.
+
+
+ Models that use performance curves for pressure rise
+
+
+ The models AixLib.Fluid.Movers.SpeedControlled_y
+ and AixLib.Fluid.Movers.SpeedControlled_Nrpm
+ take as an input either a control signal between 0 and
+ 1, or the rotational speed in units of [1/min]. From
+ this input and the current flow rate, they compute the pressure rise.
+ This pressure rise is computed using a user-provided list of
+ operating points that defines the fan or pump curve at full speed.
+ For other speeds, similarity laws are used to scale the performance
+ curves, as described in
+ AixLib.Fluid.Movers.BaseClasses.Characteristics.pressure.
+
+
+ For example, suppose a pump needs to be modeled whose pressure versus
+ flow relation crosses, at full speed, the points shown in the table
+ below.
+
+
+
+ |
+ Volume flow rate [m3⁄s]
+ |
+
+ Head [Pa]
+ |
+
+
+ |
+ 0.0003
+ |
+
+ 45000
+ |
+
+
+ |
+ 0.0006
+ |
+
+ 35000
+ |
+
+
+ |
+ 0.0008
+ |
+
+ 15000
+ |
+
+
+
+ Then, a declaration would be
+
+
+ AixLib.Fluid.Movers.SpeedControlled_y pum(
+ redeclare package Medium = Medium,
+ per.pressure(V_flow={0.0003,0.0006,0.0008},
+ dp ={45,35,15}*1000))
+ \"Circulation pump\";
+
+
+ This will model the following pump curve for the pump input signal
+ y=1.
+
+
+
+
+
+ Models that directly control the head or the mass flow rate
+
+
+ The models AixLib.Fluid.Movers.FlowControlled_dp
+ and AixLib.Fluid.Movers.FlowControlled_m_flow
+ take as an input the pressure difference or the mass flow rate. This
+ pressure difference or mass flow rate will be provided by the fan or
+ pump, i.e., the fan or pump has idealized perfect control and
+ infinite capacity. Using these models that take as an input the head
+ or the mass flow rate often leads to smaller system of equations
+ compared to using the models that take as an input the speed.
+
+
+ These models can be configured for three different control inputs.
+ For AixLib.Fluid.Movers.FlowControlled_dp,
+ the head is as follows:
+
+
+ -
+
+ If the parameter
+ inputType==AixLib.Fluid.Types.InputType.Continuous,
+ the head is dp=dp_in, where dp_in is an
+ input connector.
+
+
+ -
+
+ If the parameter
+ inputType==AixLib.Fluid.Types.InputType.Constant,
+ the head is dp=constantHead, where
+ constantHead is a parameter.
+
+
+ -
+
+ If the parameter
+ inputType==AixLib.Fluid.Types.InputType.Stages, the
+ head is dp=heads, where heads is a
+ vectorized parameter. For example, if a mover has two stages and
+ the head of the first stage should be 60% of the nominal
+ head and the second stage equal to dp_nominal, set
+ heads={0.6, 1}*dp_nominal. Then, the mover will have
+ the following heads:
+
+
+
+
+ input signal stage
+ |
+
+ Head [Pa]
+ |
+
+
+ |
+ 0
+ |
+
+ 0
+ |
+
+
+ |
+ 1
+ |
+
+ 0.6*dp_nominal
+ |
+
+
+ |
+ 2
+ |
+
+ dp_nominal
+ |
+
+
+
+
+
+ Similarly, for AixLib.Fluid.Movers.FlowControlled_m_flow,
+ the mass flow rate is as follows:
+
+
+ -
+
+ If the parameter
+ inputType==AixLib.Fluid.Types.InputType.Continuous,
+ the mass flow rate is m_flow=m_flow_in, where
+ m_flow_in is an input connector.
+
+
+ -
+
+ If the parameter
+ inputType==AixLib.Fluid.Types.InputType.Constant,
+ the mass flow rate is m_flow=constantMassFlowRate,
+ where constantMassFlowRate is a parameter.
+
+
+ -
+
+ If the parameter
+ inputType==AixLib.Fluid.Types.InputType.Stages, the
+ mass flow rate is m_flow=massFlowRates, where
+ massFlowRates is a vectorized parameter. For
+ example, if a mover has two stages and the mass flow rate of the
+ first stage should be 60% of the nominal mass flow rate
+ and the second stage equal to m_flow_nominal, set
+ massFlowRates={0.6, 1}*m_flow_nominal. Then, the
+ mover will have the following mass flow rates:
+
+
+
+
+ input signal stage
+ |
+
+ Mass flow rates [kg/s]
+ |
+
+
+ |
+ 0
+ |
+
+ 0
+ |
+
+
+ |
+ 1
+ |
+
+ 0.6*m_flow_nominal
+ |
+
+
+ |
+ 2
+ |
+
+ m_flow_nominal
+ |
+
+
+
+
+
+ These two models do not need to use a performance curve for the flow
+ characteristics. The reason is that
+
+
+ - for given pressure rise (or mass flow rate), the mass flow rate
+ (or pressure rise) is computed from the flow resistance of the duct
+ or piping network, and
+
+ - at zero pressure difference, solving for the flow rate and the
+ revolution leads to a singularity.
+
+
+
+ However, the computation of the electrical power consumption requires
+ the mover speed to be known and the computation of the mover speed
+ requires the performance curves for the flow and efficiency/power
+ characteristics. Therefore these performance curves do need to be
+ provided if the user desires a correct electrical power computation.
+ If the curves are not provided, a simplified computation is used,
+ where the efficiency curve is used and assumed to be correct for all
+ speeds. This loss of accuracy has the advantage that it allows to use
+ the mover models without requiring flow and efficiency/power
+ characteristics.
+
+
+ The model AixLib.Fluid.Movers.FlowControlled_dp
+ has an option to control the mover such that the pressure difference
+ set point is obtained across two remote points in the system. To use
+ this functionality parameter prescribeSystemPressure has
+ to be enabled and a differential pressure measurement must be
+ connected to the pump input dpMea. This functionality is
+ demonstrated in AixLib.Fluid.Movers.Validation.FlowControlled_dpSystem.
+
+
+ The models AixLib.Fluid.Movers.FlowControlled_dp
+ and AixLib.Fluid.Movers.FlowControlled_m_flow
+ both have a parameter m_flow_nominal. For AixLib.Fluid.Movers.FlowControlled_m_flow,
+ this parameter is used for convenience to set a default value for the
+ parameters constantMassFlowRate and
+ massFlowRates. For both models, the value is also used
+ for the following:
+
+
+ - To compute the size of the fluid volume that can be used to
+ approximate the inertia of the mover if the energy dynamics is
+ selected to be dynamic.
+
+ - To compute a default pressure curve if no pressure curve has been
+ specified in the record
per.pressure. The default
+ pressure curve is the line that intersects (dp, V_flow) =
+ (dp_nominal, 0) and (dp, V_flow) =
+ (m_flow_nominal/rho_default, 0).
+
+ - To regularize the equations near zero flow rate to ensure a
+ numerically robust model.
+
+
+
+ However, otherwise m_flow_nominal does not affect the
+ mass flow rate of the mover as the mass flow rate is determined by
+ the input signal or the above explained parameters.
+
+
+ Start-up and shut-down transients
+
+
+ All models have a parameter use_inputFilter. This
+ parameter affects the fan output as follows:
+
+
+ - If
use_inputFilter=false, then the input signal
+ y (or Nrpm, m_flow_in, or
+ dp_in) is equal to the fan speed (or the mass flow rate
+ or pressure rise). Thus, a step change in the input signal causes a
+ step change in the fan speed (or mass flow rate or pressure rise).
+
+ - If
use_inputFilter=true, which is the default, then
+ the fan speed (or the mass flow rate or the pressure rise) is equal
+ to the output of a filter. This filter is implemented as a 2nd order
+ differential equation and can be thought of as approximating the
+ inertia of the rotor and the fluid. Thus, a step change in the fan
+ input signal will cause a gradual change in the fan speed. The filter
+ has a parameter riseTime, which by default is set to
+ 30 seconds. The rise time is the time required to reach
+ 99.6% of the full speed, or, if the fan is switched off, to
+ reach a fan speed of 0.4%.
+
+
+
+ The figure below shows for a fan with
+ use_inputFilter=true and riseTime=30
+ seconds the speed input signal and the actual speed.
+
+
+
+
+
+ Although many simulations do not require such a detailed model that
+ approximates the transients of fans or pumps, it turns out that using
+ this filter can reduce computing time and can lead to fewer
+ convergence problems in large system models. With a filter, any
+ sudden change in control signal, such as when a fan switches on, is
+ damped before it affects the air flow rate. This continuous change in
+ flow rate turns out to be easier, and in some cases faster, to
+ simulate compared to a step change. For most simulations, we
+ therefore recommend to use the default settings of
+ use_inputFilter=true and riseTime=30
+ seconds. An exception are situations in which the fan or pump is
+ operated at a fixed speed during the whole simulation. In this case,
+ set use_inputFilter=false.
+
+
+ Note that if the fan is part of a closed loop control, then the
+ filter affects the transient response of the control. When changing
+ the value of use_inputFilter, the control gains may need
+ to be retuned. We now present values control parameters that seem to
+ work in most cases. Suppose there is a closed loop control with a
+ PI-controller AixLib.Controls.Continuous.LimPID
+ and a fan or pump, configured with use_inputFilter=true
+ and riseTime=30 seconds. Assume that the transient
+ response of the other dynamic elements in the control loop is fast
+ compared to the rise time of the filter. Then, a proportional gain of
+ k=0.5 and an integrator time constant of
+ Ti=15 seconds often yields satisfactory closed loop
+ control performance. These values may need to be changed for
+ different applications as they are also a function of the loop gain.
+ If the control loop shows oscillatory behavior, then reduce
+ k and/or increase Ti. If the control loop
+ reacts too slow, do the opposite.
+
+
+ Efficiency and electrical power consumption
+
+
+ All models compute the motor power draw Pele, the
+ hydraulic power input Whyd, the flow work
+ Wflo and the heat dissipated into the medium
+ Q. Based on the first law, the flow work is
+
+
+ Wflo = | V̇ Δp |,
+
+
+ where V̇ is the volume flow rate and Δp is the pressure
+ rise. The heat dissipated into the medium is as follows: If the motor
+ is cooled by the fluid, as indicated by
+ per.motorCooledByFluid=true, then the heat dissipated
+ into the medium is
+
+
+ Q = Pele - Wflo.
+
+
+ If per.motorCooledByFluid=false, then the motor is
+ outside the fluid stream, and only the shaft, or hydraulic, work
+ Whyd enters the thermodynamic control volume.
+ Hence,
+
+
+ Q = Whyd - Wflo.
+
+
+ The efficiencies are computed as
+
+
+ η = Wflo ⁄ Pele = ηhyd
+ ηmot
+ ηhyd = Wflo ⁄ Whyd
+ ηmot = Whyd ⁄ Pele
+
+
+ where ηhyd is the hydraulic efficiency,
+ ηmot is the motor efficiency and Q is the
+ heat released by the motor.
+
+
+ If per.use_powerCharacteristic=true, then a set of data
+ points for the power Pele for different volume flow
+ rates at full speed needs to be provided by the user. Using the flow
+ work Wflo and the electrical power input
+ Pele, the total efficiency is computed as
+
+
+ η = Wflo ⁄ Pele,
+
+
+ and the two efficiencies ηhyd and
+ ηmot are computed as
+
+
+ ηhyd = 1,
+ ηmot = η.
+
+
+ However, if per.use_powerCharacteristic=false, then
+ performance data for ηhyd and
+ ηmot need to be provided by the user, and hence the
+ model computes
+
+
+ η = ηhyd ηmot
+ Pele = Wflo ⁄ η.
+
+
+ The efficiency data for the motor are a list of points V̇ and
+ ηmot.
+
+
+ Fluid volume of the component
+
+
+ All models can be configured to have a fluid volume at the
+ low-pressure side. Adding such a volume sometimes helps the solver to
+ find a solution during initialization and time integration of large
+ models.
+
+
+ Enthalpy change of the component
+
+
+ If per.motorCooledByFluid=true, then the enthalpy change
+ between the inlet and outlet fluid port is equal to the electrical
+ power Pele that is consumed by the component.
+ Otherwise, it is equal to the hydraulic work Whyd.
+ The parameter addPowerToMedium, which is by default set
+ to true, can be used to simplify the equations. If
+ addPowerToMedium = false, then no enthalpy change occurs
+ between inlet and outlet. This can lead to simpler equations, but the
+ temperature rise across the component will be zero. In particular for
+ fans, this simplification may not be permissible.
+
+
+ Differences to models in Modelica.Fluid.Machines
+
+
+ The models in this package differ from Modelica.Fluid.Machines primarily in
+ the following points:
+
+
+ - They use a different base class, which allows to have zero mass
+ flow rate. The models in
Modelica.Fluid restrict the
+ number of revolutions, and hence the flow rate, to be non-zero.
+
+ - For the model with prescribed pressure, the input signal is the
+ pressure difference between the two ports, and not the absolute
+ pressure at
port_b.
+
+ - The pressure calculations are based on total pressure in Pascals
+ instead of the pump head in meters. This change was done to avoid
+ ambiguities in the parameterization if the models are used as a fan
+ with air as the medium. The original formulation in Modelica.Fluid.Machines converts head
+ to pressure using the density
medium.d. Therefore, for
+ fans, head would be converted to pressure using the density of air.
+ However, for pumps, manufacturers typically publish the head in
+ millimeters water (mmH2O). Therefore, to avoid confusion
+ when using these models with media other than water, we changed the
+ models to use total pressure in Pascals instead of head in meters.
+
+ - The performance data are interpolated using cubic hermite splines
+ instead of polynomials. These functions are implemented in AixLib.Fluid.Movers.BaseClasses.Characteristics.
+
+
+
+ References
+
+
+ Michael Wetter.
+ Fan and pump model that has a unique solution for any pressure
+ boundary condition and control signal. Proc. of the 13th
+ Conference of the International Building Performance Simulation
+ Association, p. 3505-3512. Chambery, France. August 2013.
+
+
+-------- Errors --------
+line 38 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+line 126 column 3 - Warning: The summary attribute on the element is obsolete in HTML5
+line 205 column 3 - Warning: The summary attribute on the element is obsolete in HTML5
+line 254 column 3 - Warning: The summary attribute on the element is obsolete in HTML5
+line 15 column 1 - Warning: attribute "align" not allowed for HTML5
+line 158 column 1 - Warning: attribute "align" not allowed for HTML5
+line 380 column 1 - Warning: attribute "align" not allowed for HTML5
+line 425 column 1 - Warning: attribute "align" not allowed for HTML5
+line 435 column 1 - Warning: attribute "align" not allowed for HTML5
+line 444 column 1 - Warning: attribute "align" not allowed for HTML5
+line 448 column 1 - Warning: attribute "align" not allowed for HTML5
+line 465 column 1 - Warning: attribute "align" not allowed for HTML5
+line 473 column 1 - Warning: attribute "align" not allowed for HTML5
+line 484 column 1 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Controls/Continuous/Examples/NumberOfRequests.mo ----
+-------- HTML Code --------
+
-
- April 11, 2016 by Michael Wetter:
- Corrected wrong hyperlink in documentation for
- issue 450.
-
- -
- December 18, 2013, by Michael Wetter:
- First implementation, based on the IDA implementation in therpro.nmf,
- but converted from Celsius to Kelvin.
-
-
-
-
- This medium package models liquid water.
-
-
- The mass density is computed using a 3rd order polynomial, which yields the
- density as a function of temperature as shown in the figure below. Note, however,
- that computing density as a function of temperature can lead to considerably
- slower computing time compared to using
-
- AixLib.Media.Water
- in which the density is a constant. We therefore recommend to use
-
- AixLib.Media.Water
- for typical building energy simulations.
-
-
-
-
-
- For the specific heat capacities at constant pressure and at constant volume,
- a constant value of 4184 J/(kg K), which corresponds to 20°C
- is used.
- The figure below shows the relative error of the specific heat capacity that
- is introduced by this simplification.
- Using a constant value for the specific heat capacity allows to compute
- temperature from enthalpy without having to solve an implicit equation,
- and therefore leads to faster simulation.
-
-
-
-
-
-
-
- Thermal conductivity is calculated as a function of temperature as shown in the figure below.
- The correlation used to calculate the thermal conductivity is
-
+ January 12, 2017, by Thierry S. Nouidui:
+ Modified example to prevent simultaneous events
+ This is for
+ #646.
+
+ -
+ November 21, 2011, by Michael Wetter:
+ Added documentation.
+
+
-
- λ(T) = λ(298.15 K) ⋅ (-1.48445+4.12292⋅(T/298.15)-1.63866⋅(T/298.15)2),
-
- where λ(298.15 K) = 0.6065 W/(m ⋅ K) is the adopted standard value
- of the thermal conductivity of water at 298.15 K and 0.1 MPa.
+ Example that demonstrates the use of the block
+
+ AixLib.Controls.Continuous.NumberOfRequests.
+ The parameters of the block are such that the output is incremented
+ for each input signal that is strictly larger than 0.
+ The figure below shows the inputs and the output of the block.
-
+ ![\"Simulation](\"modelica://AixLib/Resources/Images/Controls/Continuous/Examples/NumberOfRequests.png\")
+-------- Corrected Code --------
+
+ - January 12, 2017, by Thierry S. Nouidui:
+ Modified example to prevent simultaneous events This is for
+ #646.
+
+ - November 21, 2011, by Michael Wetter:
+ Added documentation.
+
+
+
+ Example that demonstrates the use of the block AixLib.Controls.Continuous.NumberOfRequests.
+ The parameters of the block are such that the output is incremented
+ for each input signal that is strictly larger than 0. The
+ figure below shows the inputs and the output of the block.
+
+
+
+
+
+-------- Errors --------
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Movers/BaseClasses/Characteristics/power.mo ----
+-------- HTML Code --------
+
- Dynamic viscosity is calculated as the product of density and kinematic viscosity,
- both temperature dependent. However, the kinematic viscosity
- has its own temperature dependent correlation, implemented at
-
- AixLib.Media.Specialized.Water.TemperatureDependentDensity.kinematicViscosity.
- Results of the kinematic viscosity as a function of temperature are shown in the figure below.
+ This function computes the fan power consumption for given volume flow rate,
+ speed and performance data. The power consumption is
-
-
+
+ P = rN3 s(V̇/rN, d),
-
- The enthalpy is computed using the convention that h=0
- if T=0 °C.
+ where
+ P is the power consumption,
+ rN is the normalized fan speed,
+ V̇ is the volume flow rate and
+ d are performance data for fan or pump power consumption at rN=1.
- Limitations
+ Implementation
- Phase changes are not modeled.
+ The function s(·, ·) is a cubic hermite spline.
+ If the data d define a monotone decreasing sequence, then
+ s(·, d) is a monotone decreasing function.
-
- April 5, 2022, by Michael Wetter:
- Corrected assignment of R_s in BaseProperties to avoid a unit error.
- This is for
- #1603.
-
- -
- July 7, 2016, by Carles Ribas Tugores:
- Correct Documentation. This is for
- #487.
-
- -
- June 6, 2015, by Michael Wetter:
- Set AbsolutePressure(start=p_default)
- and Temperature(start=T_default)
- to have to have conistent start values.
- See also revision notes of
-
- AixLib.Media.Water.
- This is for
- #266.
-
- -
- May 1, 2015, by Michael Wetter:
- Added Inline=true for
-
- issue 227.
-
- -
- February 25, 2015, by Michael Wetter:
- Removed stateSelect attribute on pressure as this caused
-
- AixLib.Examples.Tutorial.SpaceCooling.System3
- to fail with the error message
- \"differentiated if-then-else was not continuous\".
-
- -
- February 3, 2015, by Michael Wetter:
- Removed stateSelect.prefer for temperature.
- This is for
- #160.
-
- -
- October 15, 2014, by Michael Wetter:
- Renamed from AixLib.Media.Water to
- AixLib.Media.Water.Detailed to allow addition of
- AixLib.Media.Water.Simple.
-
- -
- September 12, 2014, by Michael Wetter:
- Set T(start=T_default) and p(start=p_default) in the
- ThermodynamicState record. Setting the start value for
- T is required to avoid an error due to conflicting start values
- when checking
- AixLib.Examples.VAVReheat.ClosedLoop in pedantic mode.
+ February 26, 2014, by Filip Jorissen:
+ Changed polynomial to be evaluated at V_flow/r_N
+ instead of V_flow to properly account for the
+ scaling law. See
+ #202
+ for a discussion and validation.
-
- December 18, 2013, by Michael Wetter:
+ September 28, 2011, by Michael Wetter:
First implementation.
-------- Corrected Code --------
- Base properties of the medium.
+ This function computes the fan power consumption for given volume
+ flow rate, speed and performance data. The power consumption is
+
+
+ P = rN3 s(V̇/rN, d),
- This function computes the density as a function of temperature.
+ where P is the power consumption, rN is the
+ normalized fan speed, V̇ is the volume flow rate and d
+ are performance data for fan or pump power consumption at
+ rN=1.
Implementation
- The function is based on the IDA implementation in
- therpro.nmf, which implements
-
-
- d := 1000.12 + 1.43711e-2*T_degC -
- 5.83576e-3*T_degC^2 + 1.5009e-5*T_degC^3;
-
-
- This has been converted to Kelvin, which resulted in the above
- expression. In addition, below 5 °C and above 100 °C, the density is
- replaced by a linear function to avoid inflection points. This linear
- extension is such that the density is once continuously
- differentiable.
-
-
- - December 18, 2013, by Michael Wetter:
- First implementation, based on the IDA implementation in
- therpro.nmf, but converted from Celsius to Kelvin and
- linearly extended.
-
-
-
- This function computes the dynamic viscosity.
+ The function s(·, ·) is a cubic hermite spline. If the data
+ d define a monotone decreasing sequence, then s(·, d)
+ is a monotone decreasing function.
- - December 2, 2013, by Michael Wetter:
- First implementation.
+ - February 26, 2014, by Filip Jorissen:
+ Changed polynomial to be evaluated at V_flow/r_N
+ instead of V_flow to properly account for the scaling
+ law. See #202
+ for a discussion and validation.
-
-
- This function computes the specific enthalpy.
-
-
- - December 11, 2013, by Michael Wetter:
+ - September 28, 2011, by Michael Wetter:
First implementation.
+
+-------- Errors --------
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/BaseClasses/FlowModels/basicFlowFunction_m_flow.mo ----
+-------- HTML Code --------
+
+
+ Function that computes the pressure drop of flow elements as
+
+
+ Δp = sign(m) (m ⁄ k)2
+
+
+ with regularization near the origin.
+ Therefore, the flow coefficient is
+
+
+ k = m ⁄ √ Δp
+
+
+ The input m_flow_turbulent determines the location of the regularization.
+
+
+
+ -
+ December 9, 2019, by Michael Wetter:
+ Added smooth(2, . ), similar to
+
+ AixLib.Fluid.BaseClasses.FlowModels.basicFlowFunction_dp.
+ See #1240.
+
+ -
+ January 4, 2019, by Michael Wetter:
+ Set `Inline=false`.
+ See #1070.
+
+ -
+ May 1, 2017, by Filip Jorissen:
+ Revised implementation such that
+
+ AixLib.Fluid.BaseClasses.FlowModels.basicFlowFunction_m_flow
+ is C2 continuous.
+ See #725.
+
+ -
+ January 22, 2016, by Michael Wetter:
+ Corrected type declaration of pressure difference.
+ This is
+ for #404.
+
+ -
+ July 28, 2015, by Michael Wetter:
+ Removed double declaration of smooth(..) and smoothOrder
+ and changed Inline=true to LateInline=true.
+ This is for
+ issue 301.
+
+ -
+ July 15, 2015, by Filip Jorissen:
+ New, more efficient implementation based on regularisation using simple polynomial.
+ Expanded common subexpressions for function inlining to be possible.
+ Set Inline=true for inlining to occur.
+ This is for
+ #279.
+
+ -
+ August 10, 2011, by Michael Wetter:
+ Removed if-then optimization that set dp=0 if m_flow=0,
+ as this causes the derivative to be discontinuous at m_flow=0.
+
+ -
+ August 4, 2011, by Michael Wetter:
+ Removed option to use a linear function. The linear implementation is now done
+ in models that call this function. With the previous implementation,
+ the symbolic processor may not rearrange the equations, which can lead
+ to coupled equations instead of an explicit solution.
+
+ -
+ April 13, 2009, by Michael Wetter:
+ First implementation.
+
+
+
+-------- Corrected Code --------
- This function computes the specific enthalpy of liquid water.
+ Function that computes the pressure drop of flow elements as
-
- - December 2, 2013, by Michael Wetter:
- First implementation.
-
-
-
- This function computes the specific internal energy.
+
+ Δp = sign(m) (m ⁄ k)2
-
- - December 11, 2013, by Michael Wetter:
- First implementation.
-
-
- This function computes the specific entropy.
+ with regularization near the origin. Therefore, the flow coefficient
+ is
-
- To obtain the state for a given pressure, entropy and mass fraction,
- use AixLib.Media.Air.setState_psX.
+
+ k = m ⁄ √ Δp
+
-
- - December 18, 2013, by Michael Wetter:
- First implementation.
-
-
- This function computes the specific Gibbs energy.
+ The input m_flow_turbulent determines the location of
+ the regularization.
-
- This function computes the specific Helmholtz energy.
-
-
- - December 2, 2013, by Michael Wetter:
- First implementation.
+ - January 4, 2019, by Michael Wetter:
+ Set `Inline=false`.
+ See #1070.
-
-
- This function computes the specific enthalpy for an isentropic state
- change from the temperature that corresponds to the state
- refState to reference_T.
-
-
-
- This function returns the isobaric expansion coefficient,
-
-
- βp = - 1 ⁄ v (∂ v ⁄ ∂ T)p,
-
-
- where v is the specific volume, T is the temperature
- and p is the pressure.
-
-
- - December 18, 2013, by Michael Wetter:
- First implementation.
+ - January 22, 2016, by Michael Wetter:
+ Corrected type declaration of pressure difference. This is for
+ #404.
-
-
- This function returns the isothermal compressibility coefficient,
- which is zero as this medium is incompressible. The isothermal
- compressibility is defined as
-
-
- κT = - 1 ⁄ v (∂ v ⁄ ∂ p)T,
-
-
- where v is the specific volume, T is the temperature
- and p is the pressure.
-
-
- - December 18, 2013, by Michael Wetter:
- First implementation.
+ - July 28, 2015, by Michael Wetter:
+ Removed double declaration of smooth(..) and
+ smoothOrder and changed Inline=true to
+ LateInline=true. This is for issue 301.
-
-
- This function returns the partial derivative of density with respect
- to pressure at constant temperature, which is zero as the medium is
- incompressible.
-
-
- - December 18, 2013, by Michael Wetter:
- First implementation.
+ - July 15, 2015, by Filip Jorissen:
+ New, more efficient implementation based on regularisation using
+ simple polynomial. Expanded common subexpressions for function
+ inlining to be possible. Set Inline=true for inlining
+ to occur. This is for #279.
-
-
- This function computes the derivative of density with respect to
- temperature at constant pressure.
-
-
- - August 17, 2015, by Michael Wetter:
- Removed dublicate entry of smooth and
- smoothOrder. This is for issue 303.
+ - August 10, 2011, by Michael Wetter:
+ Removed if-then optimization that set
+ dp=0 if m_flow=0, as this causes the
+ derivative to be discontinuous at m_flow=0.
- - December 18, 2013, by Michael Wetter:
- First implementation, based on the IDA implementation in
- therpro.nmf, but converted from Celsius to Kelvin.
+ - August 4, 2011, by Michael Wetter:
+ Removed option to use a linear function. The linear implementation
+ is now done in models that call this function. With the previous
+ implementation, the symbolic processor may not rearrange the
+ equations, which can lead to coupled equations instead of an
+ explicit solution.
-
-
- This function returns the partial derivative of density with respect
- to mass fraction, which is zero as the medium is a single substance.
-
-
- - December 18, 2013, by Michael Wetter:
+ - April 13, 2009, by Michael Wetter:
First implementation.
-
- This function returns the specific heat capacity at constant
- pressure.
+
+-------- Errors --------
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Utilities/Math/Functions/quadraticLinear.mo ----
+-------- HTML Code --------
+
+ This function computes
+
+ y = a1 + a2 x1
+ + a3 x12
+ + (a4 + a5 x1
+ + a6 x12) x2
+
+
+
+ -
+ February 29, 2009 by Michael Wetter:
+ First implementation.
+
+
+
+-------- Corrected Code --------
+This function computes
+
+ y = a1 + a2 x1 + a3
+ x12 + (a4 + a5
+ x1 + a6 x12)
+ x2
- - December 11, 2013, by Michael Wetter:
+ - February 29, 2009 by Michael Wetter:
First implementation.
+
+-------- Errors --------
+line 3 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Storage/UsersGuide.mo ----
+-------- HTML Code --------
+
- This function computes the specific heat capacity at constant volume.
+This user's guide describes the storage tank models.
+There are three storage tank models in the this package.
-
- - December 11, 2013, by Michael Wetter:
- First implementation.
-
-
+
+| Model name | Description |
|---|
+
+|
+
+AixLib.Fluid.Storage.Stratified
+ |
+
- This function returns the thermal conductivity. The expression is
- obtained from Ramires et al. (1995).
+This is a model of a stratified storage tank as shown in the figure below.
+
+
+![\"Image]()
-
- References
-
- Ramires, Maria L. V. and Nieto de Castro, Carlos A. and Nagasaka,
- Yuchi and Nagashima, Akira and Assael, Marc J. and Wakeham, William
- A. Standard Reference Data for the Thermal Conductivity of Water.
- Journal of Physical and Chemical Reference Data, 24, p.
- 1377-1381, 1995. DOI:10.1063/1.555963.
+The tank uses several volumes to model the stratification.
+Heat conduction is modeled between the volumes through the fluid,
+and between the volumes and the ambient.
-
- - December 18, 2013, by Michael Wetter:
- First implementation.
-
-
- This function returns the pressure.
+The heat port heaPorVol may be used to connect a temperature sensor
+that measures the fluid temperature of an individual volume. It may also
+be used to add heat to individual volumes, for example if the tank contains
+an electrical resistance heater.
-
- - December 18, 2013, by Michael Wetter:
- First implementation.
-
-
- This function returns the temperature.
+Similarly, the fluid port fluPorVol may be used to connect a fluid pipe
+to an individual volume. This allows for example to draw water from that volume whose temperature
+is close to the temperature required by the consumer.
+Conversely, water could be added to that tank volume whose temperature is close to the
+inlet water temperature.
+If you don't use such a pipe, simply leave the ports unconnected.
-
- - December 18, 2013, by Michael Wetter:
- First implementation.
-
-
- This function returns the molar mass, which is assumed to be
- constant.
+The tank has nSeg fluid volumes. The top segment has the index 1.
+Thus, to add a heating element to the bottom element, connect a heat input to
+heaPorVol[nSeg].
-
- - December 18, 2013, by Michael Wetter:
- First implementation.
-
-
- This function returns the thermodynamic state for a given pressure,
- specific enthalpy and composition.
+The heat ports outside the tank insulation can be
+used to specify an ambient temperature.
+Leave these ports unconnected to force adiabatic boundary conditions.
+Note, however, that all heat conduction elements through the tank wall (but not the top and bottom) are connected to the
+heat port heaPorSid. Thus, not connecting
+heaPorSid means an adiabatic boundary condition in the sense
+that heaPorSid.Q_flow = 0. This, however, still allows heat to flow
+through the tank walls, modeled by conWal, from one fluid volume
+to another one.
-
- - December 11, 2013, by Michael Wetter:
- First implementation.
-
-
+ |
+
+
+|
+
+AixLib.Fluid.Storage.StratifiedEnhanced
+ |
+
- This function returns the thermodynamic state for a given pressure,
- temperature and composition.
+The model is identical to
+
+AixLib.Fluid.Storage.Stratified,
+except for the following:
- - December 11, 2013, by Michael Wetter:
- First implementation.
-
+-
+It adds a correction that reduces the numerical dissipation.
+
+-
+It does not contain the fluid ports
fluPorVol that
+connect from the outside to the individual volumes.
+
- This function returns the thermodynamic state based on pressure,
- specific entropy and mass fraction.
+The correction uses a third order upwind scheme to compute the
+outlet temperatures of the segments in the tank. This model
+is implemented in
+
+AixLib.Fluid.Storage.BaseClasses.ThirdOrderStratifier.
+ |
+
+
+|
+
+AixLib.Fluid.Storage.StratifiedEnhancedInternalHex
+ |
+
- The state is computed by symbolically solving
- AixLib.Media.Specialized.Water.TemperatureDependentDensity.specificEntropy
- for temperature.
+This model is identical to
+
+AixLib.Fluid.Storage.StratifiedEnhanced
+except that it adds a heat exchanger to the tank.
-
- - April 11, 2016 by Michael Wetter:
- Corrected wrong hyperlink in documentation for issue 450.
-
- - December 11, 2013, by Michael Wetter:
- First implementation.
-
-
- This function computes the derivative of the specific heat capacity
- at constant pressure with respect to the state.
+The modifications consist of adding a heat exchanger
+and fluid ports to connect to the heat exchanger.
+The modifications allow to run a fluid through the tank causing heat transfer to the stored fluid.
+A typical example is a storage tank in a solar hot water system.
-
- - December 11, 2013, by Michael Wetter:
- First implementation.
-
-
- This function computes the temperature derivative of the enthalpy of
- liquid water per unit mass.
+The heat exchanger model assumes flow through the inside of a helical coil heat exchanger,
+and stagnant fluid on the outside. Parameters are used to describe the
+heat transfer on the inside of the heat exchanger at nominal conditions, and
+geometry of the outside of the heat exchanger. This information is used to compute
+an hA-value for each side of the coil.
+Convection calculations are then performed to identify heat transfer
+between the heat transfer fluid and the fluid in the tank.
-
- - December 11, 2013, by Michael Wetter:
- First implementation.
-
-
- This function computes the kinematic viscosity as a function of
- temperature.
+The location of the heat exchanger can be parameterized as follows:
+The parameters hHex_a and hHex_b are the heights
+of the heat exchanger ports portHex_a and portHex_b,
+measured from the bottom of the tank.
+For example, to place the port portHex_b at the bottom of the tank,
+set hHexB_b=0.
+The parameters hHex_a and hHex_b are then used to provide
+a default value for the parameters
+segHex_a and segHex_b, which are the numbers of the tank
+segments to which the heat exchanger ports portHex_a and portHex_b
+are connected.
-
- Implementation
-
-
- The function is based on the IDA implementation in
- therpro.nmf. The original equation is
+
+![\"Image]()
-
- kinVis :=1E-6*Modelica.Math.exp(0.577449 - 3.253945e-2*T_degC + 2.17369e-4*
- T_degC^2 - 7.22111e-7*T_degC^3);
-
- This has been converted to Kelvin, which resulted in the above
- expression. In addition, at 5 °C the kinematic viscosity is linearly
- extrapolated to avoid a large gradient at very low temperatures. We
- selected the same point for the linearization as we used for the
- density, as the density and the kinematic viscosity are combined in
-
- AixLib.Media.Specialized.Water.TemperatureDependentDensity.dynamicViscosity.
+Optionally, this model computes a dynamic response of the heat exchanger.
+This can be configured using the parameters
+energyDynamicsHexSolid,
+energyDynamicsHex and
+massDynamicsHex.
+For this computation, the fluid volume inside the heat exchanger
+and the heat capacity of the heat
+exchanger wall CHex are approximated.
+Both depend on the length lHex
+of the heat exchanger.
+The model provides default values for these
+parameters, as well as for the heat exchanger material which is
+assumed to be steel. These default values can be overwritten by the user.
+The default values for the heat exchanger geometry are computed assuming
+that there is a cylindrical heat exchanger
+made of steel whose diameter is half the diameter of the tank, e.g.,
+rHex=rTan/2.
+Hence, the length of the heat exchanger is approximated as
+lHex = 2 rHex π h = 2 rTan/2 π h,
+where h is the distance between the heat exchanger inlet and outlet.
+The wall thickness is assumed to be 10% of the heat exchanger
+outer diameter.
+For typical applications, users do not need to change these values.
-
- - April 11, 2016 by Michael Wetter:
- Corrected wrong hyperlink in documentation for issue 450.
-
- - December 18, 2013, by Michael Wetter:
- First implementation, based on the IDA implementation in
- therpro.nmf, but converted from Celsius to Kelvin.
-
-
- This medium package models liquid water.
+Setting energyDynamicsHexSolid to a dynamic balance and
+energyDynamicsHex to a steady-state balance may be of interest
+to remove very fast dynamics of the fluid, while still modeling slower
+dynamics that arises from the metal of the heat exchanger.
+By default, energyDynamicsHexSolid is set
+to the same value as energyDynamicsHex
+as this seems to be the typical configuration.
- The mass density is computed using a 3rd order polynomial, which
- yields the density as a function of temperature as shown in the
- figure below. Note, however, that computing density as a function of
- temperature can lead to considerably slower computing time compared
- to using AixLib.Media.Water in which the
- density is a constant. We therefore recommend to use AixLib.Media.Water for typical
- building energy simulations.
+The heat exchanger is implemented in
+
+AixLib.Fluid.Storage.BaseClasses.IndirectTankHeatExchanger.
-
-
+ |
+
+
+
+-------- Corrected Code --------
+
+ This user's guide describes the storage tank models. There are three
+ storage tank models in the this package.
+
+
+ |
+ Model name
+ |
+
+ Description
+ |
+
+
+ |
+ AixLib.Fluid.Storage.Stratified
+ |
+
+
+ This is a model of a stratified storage tank as shown in the
+ figure below.
+
+
+
+
+
+ The tank uses several volumes to model the stratification. Heat
+ conduction is modeled between the volumes through the fluid,
+ and between the volumes and the ambient.
+
+
+ The heat port heaPorVol may be used to connect a
+ temperature sensor that measures the fluid temperature of an
+ individual volume. It may also be used to add heat to
+ individual volumes, for example if the tank contains an
+ electrical resistance heater.
+
+
+ Similarly, the fluid port fluPorVol may be used to
+ connect a fluid pipe to an individual volume. This allows for
+ example to draw water from that volume whose temperature is
+ close to the temperature required by the consumer. Conversely,
+ water could be added to that tank volume whose temperature is
+ close to the inlet water temperature. If you don't use such a
+ pipe, simply leave the ports unconnected.
+
+
+ The tank has nSeg fluid volumes. The top segment
+ has the index 1. Thus, to add a heating element to
+ the bottom element, connect a heat input to
+ heaPorVol[nSeg].
+
+
+ The heat ports outside the tank insulation can be used to
+ specify an ambient temperature. Leave these ports unconnected
+ to force adiabatic boundary conditions. Note, however, that all
+ heat conduction elements through the tank wall (but not the top
+ and bottom) are connected to the heat port
+ heaPorSid. Thus, not connecting
+ heaPorSid means an adiabatic boundary condition in
+ the sense that heaPorSid.Q_flow = 0. This,
+ however, still allows heat to flow through the tank walls,
+ modeled by conWal, from one fluid volume to
+ another one.
+
+ |
+
+
+ |
+ AixLib.Fluid.Storage.StratifiedEnhanced
+ |
+
+
+ The model is identical to AixLib.Fluid.Storage.Stratified,
+ except for the following:
+
+
+ - It adds a correction that reduces the numerical
+ dissipation.
+
+ - It does not contain the fluid ports
fluPorVol
+ that connect from the outside to the individual volumes.
+
+
+
+ The correction uses a third order upwind scheme to compute the
+ outlet temperatures of the segments in the tank. This model is
+ implemented in
+ AixLib.Fluid.Storage.BaseClasses.ThirdOrderStratifier.
+
+ |
+
+
+ |
+ AixLib.Fluid.Storage.StratifiedEnhancedInternalHex
+ |
+
+
+ This model is identical to AixLib.Fluid.Storage.StratifiedEnhanced
+ except that it adds a heat exchanger to the tank.
+
+
+ The modifications consist of adding a heat exchanger and fluid
+ ports to connect to the heat exchanger. The modifications allow
+ to run a fluid through the tank causing heat transfer to the
+ stored fluid. A typical example is a storage tank in a solar
+ hot water system.
+
+
+ The heat exchanger model assumes flow through the inside of a
+ helical coil heat exchanger, and stagnant fluid on the outside.
+ Parameters are used to describe the heat transfer on the inside
+ of the heat exchanger at nominal conditions, and geometry of
+ the outside of the heat exchanger. This information is used to
+ compute an hA-value for each side of the coil.
+ Convection calculations are then performed to identify heat
+ transfer between the heat transfer fluid and the fluid in the
+ tank.
+
+
+ The location of the heat exchanger can be parameterized as
+ follows: The parameters hHex_a and
+ hHex_b are the heights of the heat exchanger ports
+ portHex_a and portHex_b, measured
+ from the bottom of the tank. For example, to place the port
+ portHex_b at the bottom of the tank, set
+ hHexB_b=0. The parameters hHex_a and
+ hHex_b are then used to provide a default value
+ for the parameters segHex_a and
+ segHex_b, which are the numbers of the tank
+ segments to which the heat exchanger ports
+ portHex_a and portHex_b are
+ connected.
+
+
+
+
+
+ Optionally, this model computes a dynamic response of the heat
+ exchanger. This can be configured using the parameters
+ energyDynamicsHexSolid,
+ energyDynamicsHex and
+ massDynamicsHex. For this computation, the fluid
+ volume inside the heat exchanger and the heat capacity of the
+ heat exchanger wall CHex are approximated. Both
+ depend on the length lHex of the heat exchanger.
+ The model provides default values for these parameters, as well
+ as for the heat exchanger material which is assumed to be
+ steel. These default values can be overwritten by the user. The
+ default values for the heat exchanger geometry are computed
+ assuming that there is a cylindrical heat exchanger made of
+ steel whose diameter is half the diameter of the tank, e.g.,
+ rHex=rTan/2. Hence, the length of
+ the heat exchanger is approximated as lHex = 2
+ rHex π h = 2 rTan/2 π h, where
+ h is the distance between the heat exchanger inlet and
+ outlet. The wall thickness is assumed to be 10% of the
+ heat exchanger outer diameter. For typical applications, users
+ do not need to change these values.
+
+
+ Setting energyDynamicsHexSolid to a dynamic
+ balance and energyDynamicsHex to a steady-state
+ balance may be of interest to remove very fast dynamics of the
+ fluid, while still modeling slower dynamics that arises from
+ the metal of the heat exchanger. By default,
+ energyDynamicsHexSolid is set to the same value as
+ energyDynamicsHex as this seems to be the typical
+ configuration.
+
+
+ The heat exchanger is implemented in AixLib.Fluid.Storage.BaseClasses.IndirectTankHeatExchanger.
+
+ |
+
+
+
+-------- Errors --------
+line 6 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+line 17 column 1 - Warning: attribute "align" not allowed for HTML5
+line 129 column 1 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/FixedResistances/BaseClasses/PlugFlowHeatLoss.mo ----
+-------- HTML Code --------
+
+
+ Component that calculates the heat losses at the end of a plug flow pipe
+ when the flow goes in the design direction.
+
+ Main equations
+
+ The governing equations are
+
+
+ Tout = Tb + (Tin - Tb)
+ exp((tout - tin)/tauchar)
+
+
+ with
+
+
+ tauchar = R C
+
+ Assumptions and limitations
+
+ This model is based on the following assumptions:
+
+
+ - The water temperature is uniform in the cross section.
+ - There is no axial heat transfer in the water or surrounding.
+ - The boundary temperature along the pipe is uniform.
+ - Heat losses are steady-state.
+
+ Implementation
+
+ Heat losses are only considered in design flow direction.
+ For heat loss consideration in both directions, use one of these models at
+ both ends of a
+
+ AixLib.Fluid.FixedResistances.BaseClasses.PlugFlow model.
+ The outlet temperature is calculated as in the equation above,
+ using the inlet temperature at port_a and the instantaneous
+ time delay and boundary temperature.
+ The boundary temperature can be either the air temperature
+ or the undisturbed ground temperature, depending on the definition of the
+ thermal resistance R.
+
+
+ This component requires the delay time and the instantaneous ambient temperature
+ as an input.
+ This component is to be used in single pipes or in more advanced configurations
+ where no influence from other pipes is considered.
+
+
+ -
+ December 6, 2017, by Michael Wetter:
+ Reformulated call to medium function.
+ This is for
+
+ issue 869.
+
+ -
+ October 20, 2017, by Michael Wetter:
+ Revised implementation to avoid graphical and textual modeling.
+ Revised variable names and documentation to follow guidelines.
+
+ -
+ November 6, 2015 by Bram van der Heijde:
+ Make time delay input instead of calculation inside this model.
+
+ -
+ September, 2015 by Marcus Fuchs:
+ First implementation.
+
+
+-------- Corrected Code --------
- For the specific heat capacities at constant pressure and at constant
- volume, a constant value of 4184 J/(kg K), which corresponds
- to 20°C is used. The figure below shows the relative error of
- the specific heat capacity that is introduced by this simplification.
- Using a constant value for the specific heat capacity allows to
- compute temperature from enthalpy without having to solve an implicit
- equation, and therefore leads to faster simulation.
-
-
-
+ Component that calculates the heat losses at the end of a plug flow
+ pipe when the flow goes in the design direction.
+
+ Main equations
+
- Thermal conductivity is calculated as a function of temperature as
- shown in the figure below. The correlation used to calculate the
- thermal conductivity is
+ The governing equations are
- λ(T) = λ(298.15 K) ⋅
- (-1.48445+4.12292⋅(T/298.15)-1.63866⋅(T/298.15)2),
+ Tout = Tb + (Tin - Tb)
+ exp((tout - tin)/tauchar)
- where λ(298.15 K) = 0.6065 W/(m ⋅ K) is the adopted standard
- value of the thermal conductivity of water at 298.15 K and
- 0.1 MPa.
+ with
-
-
+
+ tauchar = R C
+
+ Assumptions and limitations
+
- Dynamic viscosity is calculated as the product of density and
- kinematic viscosity, both temperature dependent. However, the
- kinematic viscosity has its own temperature dependent correlation,
- implemented at
- AixLib.Media.Specialized.Water.TemperatureDependentDensity.kinematicViscosity.
- Results of the kinematic viscosity as a function of temperature are
- shown in the figure below.
+ This model is based on the following assumptions:
-
-
+
+ - The water temperature is uniform in the cross section.
+
+ - There is no axial heat transfer in the water or surrounding.
+
+ - The boundary temperature along the pipe is uniform.
+
+ - Heat losses are steady-state.
+
+
+
+ Implementation
+
+
+ Heat losses are only considered in design flow direction. For heat
+ loss consideration in both directions, use one of these models at
+ both ends of a AixLib.Fluid.FixedResistances.BaseClasses.PlugFlow
+ model. The outlet temperature is calculated as in the equation above,
+ using the inlet temperature at port_a and the
+ instantaneous time delay and boundary temperature. The boundary
+ temperature can be either the air temperature or the undisturbed
+ ground temperature, depending on the definition of the thermal
+ resistance R.
- The enthalpy is computed using the convention that h=0 if
- T=0 °C.
+ This component requires the delay time and the instantaneous ambient
+ temperature as an input. This component is to be used in single pipes
+ or in more advanced configurations where no influence from other
+ pipes is considered.
-
- Limitations
-
+
+ - December 6, 2017, by Michael Wetter:
+ Reformulated call to medium function.
+ This is for issue 869.
+
+ - October 20, 2017, by Michael Wetter:
+ Revised implementation to avoid graphical and textual modeling.
+ Revised variable names and documentation to follow guidelines.
+
+ - November 6, 2015 by Bram van der Heijde:
+ Make time delay input instead of calculation inside this model.
+
+ - September, 2015 by Marcus Fuchs:
+ First implementation.
+
+
+
+-------- Errors --------
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+line 17 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Utilities/IO/SignalExchange/SignalTypes/SignalsForKPIs.mo ----
+-------- HTML Code --------
+
+
+ This enumeration defines the signal types that are used by BOPTEST
+ to compute the key performance indices (KPI).
+
+
+ The following signal types are supported.
+
+
+ | Value |
+ Description |
+
|---|
+ None |
+ Not used for KPI |
+
+ AirZoneTemperature |
+ Air zone temperature |
+
+ RadiativeZoneTemperature |
+ Radiative zone temperature |
+
+ OperativeZoneTemperature |
+ Operative zone temperature |
+
+ RelativeHumidity |
+ Relative humidity |
+
+ CO2Concentration |
+ CO2 concentration |
+
+ ElectricPower |
+ Electric power from grid |
+
+ DistrictHeatingPower |
+ Thermal power from district heating |
+
+ GasPower |
+ Thermal power from natural gas |
+
+ BiomassPower |
+ Thermal power from biomass |
+
+ SolarThermalPower |
+ Thermal power from solar thermal |
+
+ FreshWaterFlowRate |
+ FreshWaterFlowRate |
+
+
+
+
+ -
+ July 17, 2019, by Michael Wetter:
+ Added documentation.
+
+ -
+ April 10, 2019, by Javier Arroyo:
+ First implementation.
+
+
+
+-------- Corrected Code --------
- Phase changes are not modeled.
+ This enumeration defines the signal types that are used by BOPTEST to
+ compute the key performance indices (KPI).
+
+
+ The following signal types are supported.
+
+
+ |
+ Value
+ |
+
+ Description
+ |
+
+
+
+ None
+ |
+
+ Not used for KPI
+ |
+
+
+
+ AirZoneTemperature
+ |
+
+ Air zone temperature
+ |
+
+
+
+ RadiativeZoneTemperature
+ |
+
+ Radiative zone temperature
+ |
+
+
+
+ OperativeZoneTemperature
+ |
+
+ Operative zone temperature
+ |
+
+
+
+ RelativeHumidity
+ |
+
+ Relative humidity
+ |
+
+
+
+ CO2Concentration
+ |
+
+ CO2 concentration
+ |
+
+
+
+ ElectricPower
+ |
+
+ Electric power from grid
+ |
+
+
+
+ DistrictHeatingPower
+ |
+
+ Thermal power from district heating
+ |
+
+
+
+ GasPower
+ |
+
+ Thermal power from natural gas
+ |
+
+
+
+ BiomassPower
+ |
+
+ Thermal power from biomass
+ |
+
+
+
+ SolarThermalPower
+ |
+
+ Thermal power from solar thermal
+ |
+
+
+
+ FreshWaterFlowRate
+ |
+
+ FreshWaterFlowRate
+ |
+
+
- - April 5, 2022, by Michael Wetter:
- Corrected assignment of R_s in
- BaseProperties to avoid a unit error.
- This is for #1603.
-
- - July 7, 2016, by Carles Ribas Tugores:
- Correct Documentation. This is for #487.
-
- - June 6, 2015, by Michael Wetter:
- Set AbsolutePressure(start=p_default) and
- Temperature(start=T_default) to have to have conistent
- start values. See also revision notes of AixLib.Media.Water. This is for
- #266.
-
- - May 1, 2015, by Michael Wetter:
- Added Inline=true for issue 227.
-
- - February 25, 2015, by Michael Wetter:
- Removed stateSelect attribute on pressure as this
- caused AixLib.Examples.Tutorial.SpaceCooling.System3
- to fail with the error message \"differentiated if-then-else was not
- continuous\".
-
- - February 3, 2015, by Michael Wetter:
- Removed stateSelect.prefer for temperature. This is
- for #160.
-
- - October 15, 2014, by Michael Wetter:
- Renamed from AixLib.Media.Water to
- AixLib.Media.Water.Detailed to allow addition of
- AixLib.Media.Water.Simple.
-
- - September 12, 2014, by Michael Wetter:
- Set T(start=T_default) and
- p(start=p_default) in the
- ThermodynamicState record. Setting the start value for
- T is required to avoid an error due to conflicting
- start values when checking AixLib.Examples.VAVReheat.ClosedLoop
- in pedantic mode.
+ - July 17, 2019, by Michael Wetter:
+ Added documentation.
- - December 18, 2013, by Michael Wetter:
+ - April 10, 2019, by Javier Arroyo:
First implementation.
-------- Errors --------
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
-line 7 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
-line 17 column 2 - Warning: attribute "align" not allowed for HTML5
-line 31 column 2 - Warning: attribute "align" not allowed for HTML5
-line 42 column 2 - Warning: attribute "align" not allowed for HTML5
-line 49 column 2 - Warning: attribute "align" not allowed for HTML5
-line 62 column 2 - Warning: attribute "align" not allowed for HTML5
+line 9 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/HeatPumps/Carnot_TCon.mo ----
+---- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/MSLAIT.mo ----
-------- HTML Code --------
- This is a model of a heat pump whose coefficient of performance COP changes
- with temperatures in the same way as the Carnot efficiency changes.
- The control input is the setpoint of the condenser leaving temperature, which
- is met exactly at steady state if the heat pump has sufficient capacity.
-
-
- The model allows to either specify the Carnot effectivness
- ηCarnot,0, or
- a COP0
- at the nominal conditions, together with
- the evaporator temperature Teva,0 and
- the condenser temperature Tcon,0, in which
- case the model computes the Carnot effectivness as
-
-
- ηCarnot,0 =
- COP0
- ⁄ (Tcon,0 ⁄ (Tcon,0-Teva,0)).
-
-
- The heat pump COP is computed as the product
-
-
- COP = ηCarnot,0 COPCarnot ηPL,
-
-
- where COPCarnot is the Carnot efficiency and
- ηPL is a polynomial in heating part load ratio yPL
- that can be used to take into account a change in COP at part load
- conditions.
- This polynomial has the form
-
-
- ηPL = a1 + a2 yPL + a3 yPL2 + ...
-
-
- where the coefficients ai
- are declared by the parameter a.
-
-
- On the Dynamics tag, the model can be parametrized to compute a transient
- or steady-state response.
- The transient response of the model is computed using a first
- order differential equation for the evaporator and condenser fluid volumes.
- The heat pump outlet temperatures are equal to the temperatures of these lumped volumes.
-
- Typical use and important parameters
-
- When using this component, make sure that the condenser has sufficient mass flow rate.
- Based on the evaporator mass flow rate, temperature difference and the efficiencies,
- the model computes how much heat will be removed by to the evaporator.
- If the mass flow rate is too small, very low outlet temperatures can result, possibly below freezing.
+ The example contains
+
+ experimental data from a real district heating network.
+ This data is used to validate this library's
+
+ AixLib.Fluid.FixedResistances.PlugFlowPipe in
+
+ AixLib.Fluid.FixedResistances.Validation.PlugFlowPipes.PlugFlowAIT.
+ This model compares its performance with the original Modelica Standard Library
+ pipes, using one discretization element per unit length of pipe.
+ For a coarser discretization, please refer to
+
+ MSLAIT2Nodes.
- The condenser heat flow rate QCon_flow_nominal is used to assign
- the default value for the mass flow rates, which are used for the pressure drop
- calculations.
- It is also used to compute the part load efficiency.
- Hence, make sure that QCon_flow_nominal is set to a reasonable value.
+ Note that these three models are identical, except for the pipe model that is used:
+
- The maximum heating capacity is set by the parameter QCon_flow_max,
- which is by default set to infinity.
+ This comparison between different discretization levels and pipe models is made
+ to check the influence of the discretization and pipe model on computation time
+ and simulation accuracy.
-
- The coefficient of performance depends on the
- evaporator and condenser leaving temperature
- since otherwise the second law of thermodynamics may be violated.
+ The pipes' temperatures are not initialized, thus results of outflow
+ temperature before approximately the first 10000 seconds should not be considered.
- Notes
+ Test bench schematic
+
+ Calibration
+ To calculate the length specific thermal resistance R of the
+ pipe, the thermal resistance of the surrounding ground is added.
+
+ R=1/(0.208)+1/(2 lambda_g Modelica.Constants.pi) log(1/0.18)
- For a similar model that can be used as a chiller, see
-
- AixLib.Fluid.Chillers.Examples.Carnot_TEva.
+ Where the thermal conductivity of the ground lambda_g = 2.4 W/(m K).
-
- January 3, 2017, by Michael Wetter:
- Removed parameters
- effInpEva and effInpCon
- and updated documentation.
+ March 7, 2020, by Michael Wetter:
+ Replaced measured data from specification in Modelica file to external table,
+ as this reduces the computing time.
This is for
-
- issue 497.
+ #1289.
-
- August 8, 2016, by Michael Wetter:
- Changed default temperature to compute COP to be the leaving temperature as
- use of the entering temperature can violate the 2nd law if the temperature
- lift is small.
- This is for
-
- Annex 60, issue 497.
+ May 15, 2019, by Jianjun Hu:
+ Replaced fluid source. This is for
+ #1072.
+
+ - November 28, 2016 by Bram van der Heijde:
Remove pipVol.
+
+ - August 24, 2016 by Bram van der Heijde:
+ Implement validation with MSL pipes for comparison, based on AIT validation.
-
- November 25, 2015 by Michael Wetter:
- First implementation.
+ July 4, 2016 by Bram van der Heijde:
Added parameters to test the
+ influence of allowFlowReversal and the presence of explicit volumes in the pipe.
+ - January 26, 2016 by Carles Ribas:
First implementation.
-------- Corrected Code --------
- This is a model of a heat pump whose coefficient of performance COP
- changes with temperatures in the same way as the Carnot efficiency
- changes. The control input is the setpoint of the condenser leaving
- temperature, which is met exactly at steady state if the heat pump
- has sufficient capacity.
-
-
- The model allows to either specify the Carnot effectivness
- ηCarnot,0, or a COP0 at the
- nominal conditions, together with the evaporator temperature
- Teva,0 and the condenser temperature
- Tcon,0, in which case the model computes the Carnot
- effectivness as
-
-
- ηCarnot,0 = COP0 ⁄ (Tcon,0 ⁄
- (Tcon,0-Teva,0)).
-
-
- The heat pump COP is computed as the product
-
-
- COP = ηCarnot,0 COPCarnot ηPL,
+ The example contains
+ experimental data from a real district heating network. This data
+ is used to validate this library's AixLib.Fluid.FixedResistances.PlugFlowPipe
+ in
+ AixLib.Fluid.FixedResistances.Validation.PlugFlowPipes.PlugFlowAIT.
+ This model compares its performance with the original Modelica
+ Standard Library pipes, using one discretization element per unit
+ length of pipe. For a coarser discretization, please refer to
+
+ MSLAIT2Nodes.
- where COPCarnot is the Carnot efficiency and
- ηPL is a polynomial in heating part load ratio
- yPL that can be used to take into account a change
- in COP at part load conditions. This polynomial has the form
-
-
- ηPL = a1 + a2 yPL +
- a3 yPL2 + ...
+ Note that these three models are identical, except for the pipe model
+ that is used:
+
- where the coefficients ai are declared by the
- parameter a.
+ This comparison between different discretization levels and pipe
+ models is made to check the influence of the discretization and pipe
+ model on computation time and simulation accuracy.
- On the Dynamics tag, the model can be parametrized to
- compute a transient or steady-state response. The transient response
- of the model is computed using a first order differential equation
- for the evaporator and condenser fluid volumes. The heat pump outlet
- temperatures are equal to the temperatures of these lumped volumes.
+ The pipes' temperatures are not initialized, thus results of outflow
+ temperature before approximately the first 10000 seconds should not
+ be considered.
- Typical use and important parameters
+ Test bench schematic
- When using this component, make sure that the condenser has
- sufficient mass flow rate. Based on the evaporator mass flow rate,
- temperature difference and the efficiencies, the model computes how
- much heat will be removed by to the evaporator. If the mass flow rate
- is too small, very low outlet temperatures can result, possibly below
- freezing.
-
-
- The condenser heat flow rate QCon_flow_nominal is used
- to assign the default value for the mass flow rates, which are used
- for the pressure drop calculations. It is also used to compute the
- part load efficiency. Hence, make sure that
- QCon_flow_nominal is set to a reasonable value.
+
+
+ Calibration
+
- The maximum heating capacity is set by the parameter
- QCon_flow_max, which is by default set to infinity.
+ To calculate the length specific thermal resistance R of
+ the pipe, the thermal resistance of the surrounding ground is added.
-
- The coefficient of performance depends on the evaporator and
- condenser leaving temperature since otherwise the second law of
- thermodynamics may be violated.
+
+ R=1/(0.208)+1/(2 lambda_g Modelica.Constants.pi)
+ log(1/0.18)
-
- Notes
-
- For a similar model that can be used as a chiller, see AixLib.Fluid.Chillers.Examples.Carnot_TEva.
+ Where the thermal conductivity of the ground lambda_g =
+ 2.4 W/(m K).
- - January 3, 2017, by Michael Wetter:
- Removed parameters effInpEva and
- effInpCon and updated documentation. This is for
- issue
- 497.
-
- - August 8, 2016, by Michael Wetter:
- Changed default temperature to compute COP to be the leaving
- temperature as use of the entering temperature can violate the 2nd
- law if the temperature lift is small.
+ - March 7, 2020, by Michael Wetter:
+ Replaced measured data from specification in Modelica file to
+ external table, as this reduces the computing time.
This is for Annex 60,
- issue 497.
+ \"https://github.com/ibpsa/modelica-ibpsa/issues/1289\">#1289.
- - November 25, 2015 by Michael Wetter:
+ - May 15, 2019, by Jianjun Hu:
+ Replaced fluid source. This is for #1072.
+
+ - November 28, 2016 by Bram van der Heijde:
+ Remove pipVol.
+
+ - August 24, 2016 by Bram van der Heijde:
+ Implement validation with MSL pipes for comparison, based on AIT
+ validation.
+
+ - July 4, 2016 by Bram van der Heijde:
+ Added parameters to test the influence of allowFlowReversal and the
+ presence of explicit volumes in the pipe.
+
+ - January 26, 2016 by Carles Ribas:
First implementation.
-------- Errors --------
-line 17 column 2 - Warning: attribute "align" not allowed for HTML5
-line 25 column 2 - Warning: attribute "align" not allowed for HTML5
-line 35 column 2 - Warning: attribute "align" not allowed for HTML5
+line 56 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Controls/Continuous/Examples/NumberOfRequests.mo ----
+---- AixLib/Fluid/HeatExchangers/PrescribedOutlet.mo ----
-------- HTML Code --------
-
- -
- January 12, 2017, by Thierry S. Nouidui:
- Modified example to prevent simultaneous events
- This is for
- #646.
-
- -
- November 21, 2011, by Michael Wetter:
- Added documentation.
-
-
-
- Example that demonstrates the use of the block
-
- AixLib.Controls.Continuous.NumberOfRequests.
- The parameters of the block are such that the output is incremented
- for each input signal that is strictly larger than 0.
- The figure below shows the inputs and the output of the block.
+ Model that allows specifying the temperature and mass fraction of the fluid
+ that leaves the model from port_b.
-
-
+
+ This model forces the outlet temperature at port_b to be equal to the temperature
+ of the input signal TSet, subject to optional limits on the
+ heating or cooling capacity QMax_flow ≥ 0 and QMin_flow ≤ 0.
+ Similarly than for the temperature,
+ this model also forces the outlet water mass fraction at port_b to be
+ no lower than the
+ input signal X_wSet, subject to optional limits on the
+ maximum water vapor mass flow rate that is added, as
+ described by the parameter mWatMax_flow.
+ By default, the model has unlimited capacity, but control of temperature
+ and humidity can be subject to capacity limits, or be disabled.
+
+
+ The output signal Q_flow is the heat added (for heating) or subtracted (for cooling)
+ to the medium if the flow rate is from port_a to port_b.
+ If the flow is reversed, then Q_flow=0.
+
+
+ The outlet conditions at port_a are not affected by this model.
+
+
+ If the parameter energyDynamics is not equal to
+ Modelica.Fluid.Types.Dynamics.SteadyState,
+ the component models the dynamic response using a first order differential equation.
+ The time constant of the component is equal to the parameter tau.
+ This time constant is adjusted based on the mass flow rate using
-
--------- Corrected Code --------
-
- - January 12, 2017, by Thierry S. Nouidui:
- Modified example to prevent simultaneous events This is for
- #646.
-
- - November 21, 2011, by Michael Wetter:
- Added documentation.
-
-
-
- Example that demonstrates the use of the block AixLib.Controls.Continuous.NumberOfRequests.
- The parameters of the block are such that the output is incremented
- for each input signal that is strictly larger than 0. The
- figure below shows the inputs and the output of the block.
-
-
-
-
-
--------- Errors --------
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Utilities/Math/Functions/polynomial.mo ----
--------- HTML Code --------
-
- This function computes a polynomial of arbitrary order.
- The polynomial has the form
- y = a1 + a2 x + a3 x2 + ...
+ τeff = τ |ṁ| ⁄ ṁnom
+
+
+ where
+ τeff is the effective time constant for the given mass flow rate
+ ṁ and
+ τ is the time constant at the nominal mass flow rate
+ ṁnom.
+ This type of dynamics is equal to the dynamics that a completely mixed
+ control volume would have.
+
+
+ Optionally, this model can have a flow resistance.
+ If no flow resistance is requested, set dp_nominal=0.
+
+
+ For a model that uses a control signal u ∈ [0, 1] and multiplies
+ this with the nominal heating or cooling power, use
+
+ AixLib.Fluid.HeatExchangers.HeaterCooler_u
+
+
+ Limitations
+
+ This model only adds or removes heat or water vapor for the flow from
+ port_a to port_b.
+ The enthalpy of the reverse flow is not affected by this model.
+
+
+ If this model is used to cool air below the dew point temperature, the water mass fraction
+ will not change.
+
+
+ Note that for use_TSet = false, the enthalpy of the leaving fluid
+ will not be changed, even if moisture is added. The enthalpy added (or removed)
+ by the change in humidity is neglected. To properly account for change in enthalpy
+ due to humidification, use instead
+
+ AixLib.Fluid.Humidifiers.SprayAirWasher_X.
+
+ Validation
+
+ The model has been validated against the analytical solution in
+ the examples
+
+ AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet
+ and
+
+ AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet_dynamic.
-
- December 14, 2016, by Michael Wetter:
- Removed derivative annotation.
+ March 3, 2022, by Michael Wetter:
+ Removed massDynamics.
This is for
- issue 602.
+ issue 1542.
-
- March 30, 2011, by Michael Wetter:
- Added zeroDerivative keyword.
+ May 3, 2017, by Michael Wetter:
+ Updated protected model for
+ #763.
-
- March 2, by Michael Wetter:
- Removed redundant smoothOrder annotation.
+ December 1, 2016, by Michael Wetter:
+ Updated model as use_dh is no longer a parameter in the pressure drop model.
+ This is for
+ #480.
-
- February 29, 2009 by Michael Wetter:
+ November 11, 2014, by Michael Wetter:
+ Revised implementation.
+
+ -
+ March 19, 2014, by Christoph Nytsch-Geusen:
First implementation.
-------- Corrected Code --------
-This function computes a polynomial of arbitrary order. The polynomial
-has the form
-
- y = a1 + a2 x + a3 x2 +
- ...
+
+ Model that allows specifying the temperature and mass fraction of the
+ fluid that leaves the model from port_b.
-
- - December 14, 2016, by Michael Wetter:
- Removed derivative annotation.
- This is for issue 602.
-
- - March 30, 2011, by Michael Wetter:
- Added zeroDerivative keyword.
-
- - March 2, by Michael Wetter:
- Removed redundant smoothOrder annotation.
-
- - February 29, 2009 by Michael Wetter:
- First implementation.
-
-
-
--------- Errors --------
-line 4 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/FMI/UsersGuide.mo ----
--------- HTML Code --------
-
-This user's guide describes the FMI package (Wetter et al., 2015).
-The FMI package has been implemented to facilitate the export
-of thermofluid flow models such as HVAC components, HVAC systems
-and thermal zones as Functional Mockup Units (FMUs).
-This allows to export thermofluid flow models as FMUs so that they can be
-imported in other simulators.
-To export thermofluid flow components, a Modelica block is needed
-in order for the model to only have input and output signals
-rather than fluid connectors, as fluid connectors do not impose any causality
-on the signal flow.
-This package implements such blocks and its connectors.
+ This model forces the outlet temperature at port_b to be
+ equal to the temperature of the input signal TSet,
+ subject to optional limits on the heating or cooling capacity
+ QMax_flow ≥ 0 and QMin_flow ≤ 0. Similarly
+ than for the temperature, this model also forces the outlet water
+ mass fraction at port_b to be no lower than the input
+ signal X_wSet, subject to optional limits on the maximum
+ water vapor mass flow rate that is added, as described by the
+ parameter mWatMax_flow. By default, the model has
+ unlimited capacity, but control of temperature and humidity can be
+ subject to capacity limits, or be disabled.
-The main packages are as follows:
+ The output signal Q_flow is the heat added (for heating)
+ or subtracted (for cooling) to the medium if the flow rate is from
+ port_a to port_b. If the flow is reversed,
+ then Q_flow=0.
-
-
- | Package | Description |
-
-
- |
-
- AixLib.Fluid.FMI.ExportContainers
- |
-
-
- Package with blocks to export thermofluid flow components and systems.
-
-
- To export an HVAC component or system with a single inlet and outlet port, instantiate
-
- AixLib.Fluid.FMI.ExportContainers.ReplaceableTwoPort
- with a replaceable model,
- or extend from
-
- AixLib.Fluid.FMI.ExportContainers.PartialTwoPort
- and add components.
- See
-
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.Fan
- and
-
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ResistanceVolume.
-
-
- To export an HVAC system that serves a single thermal zone, extend from
-
- AixLib.Fluid.FMI.ExportContainers.HVACZone
- and add the HVAC system.
- See
-
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZone.
-
-
- To export an HVAC system that serves multiple thermal zones, extend from
-
- AixLib.Fluid.FMI.ExportContainers.HVACZones
- and add the HVAC system.
- See
-
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZones.
-
-
- To export a single thermal zone, extend from
-
- AixLib.Fluid.FMI.ExportContainers.ThermalZone
- and add the thermal zone.
- See
-
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZone.
-
-
- To export multiple thermal zones, extend from
-
- AixLib.Fluid.FMI.ExportContainers.ThermalZones
- and add the thermal zone models.
- See
-
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZones.
-
- |
-
-
- |
-
- AixLib.Fluid.FMI.Adaptors
- |
-
-
- Package with adaptors to connect models with fluid ports to blocks that
- have input and output signals.
-
- |
-
-
-|
-
-
- AixLib.Fluid.FMI.Conversion
-
- |
-
-
- Package with blocks that convert between the signal connectors of
-
- AixLib.Fluid.FMI.Interfaces
- and the real input and output signal connectors of the Modelica Standard Library.
-
- |
-
-
-|
-
- AixLib.Fluid.FMI.Interfaces
- |
-
-
- Package with composite connectors that have different input and output
- signals. These connectors are used to export FMUs, and they contain
- quantities such as mass flow rate, temperature, optional pressure, etc.
-
- |
-
-
-The package
-
-AixLib.Fluid.FMI.ExportContainers.Examples.FMUs
-contains various examples in which HVAC components, HVAC systems
-and thermal zones are exported as an FMU.
+ The outlet conditions at port_a are not affected by this
+ model.
-Typical use
-Users who want to export a single thermofluid flow component, or a
-subsystem of thermofluid flow components, can use the block
-
-AixLib.Fluid.FMI.ExportContainers.ReplaceableTwoPort.
-This block has a fluid inlet, a fluid outlet, and a replaceable
-component that can be replaced with an HVAC component or system that
-has an inlet and outlet fluid port.
+ If the parameter energyDynamics is not equal to
+ Modelica.Fluid.Types.Dynamics.SteadyState, the component
+ models the dynamic response using a first order differential
+ equation. The time constant of the component is equal to the
+ parameter tau. This time constant is adjusted based on
+ the mass flow rate using
+
+
+ τeff = τ |ṁ| ⁄ ṁnom
-Users who want to export a whole HVAC system that serves a single thermal zone
-can do so by extending the partial block
-
-AixLib.Fluid.FMI.ExportContainers.HVACZone.
-The example
-
-AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZone
-illustrates how this can be accomplished.
-Similar export containers and examples are implemented for HVAC systems that serve multiple thermal zones.
+ where τeff is the effective time constant for the
+ given mass flow rate ṁ and τ is the time constant at
+ the nominal mass flow rate ṁnom. This type of
+ dynamics is equal to the dynamics that a completely mixed control
+ volume would have.
-Conversely, to export a thermal zone, users can extend the partial block
-
-AixLib.Fluid.FMI.ExportContainers.ThermalZone.
-The example
-
-AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZone
-illustrates how this can be accomplished.
-Similar export containers and examples are implemented for models of multiple thermal zones.
+ Optionally, this model can have a flow resistance. If no flow
+ resistance is requested, set dp_nominal=0.
-Each example and validation model has a Dymola script that
-either simulates the model, or exports the model as an FMU.
-The script can be invoked from the pull
-down menu Commands -> Export FMU.
+ For a model that uses a control signal u ∈ [0, 1] and
+ multiplies this with the nominal heating or cooling power, use
+ AixLib.Fluid.HeatExchangers.HeaterCooler_u
+
+
+ Limitations
+
+
+ This model only adds or removes heat or water vapor for the flow from
+ port_a to port_b. The enthalpy of the
+ reverse flow is not affected by this model.
-Options
-In the
-AixLib.Fluid package,
-most models have a boolean parameter called allowFlowReversal.
-If set to true, then the flow can be in either direction,
-otherwise it needs to be from the inlet to the outlet port.
-This parameter is also used in the
-AixLib.Fluid.FMI package.
-The package was designed in such a way that an FMU,
-if exported with allowFlowReversal=false
-has as input the mass flow rate,
-pressure and fluid properties of the inflowing fluid. The outputs
-are the outlet mass flow rate, outlet pressure and the fluid
-properties of the outflowing medium. This allows simulators
-such as Ptolemy II
-to evaluate the FMUs in the direction of the mass flow by first
-setting all inputs, then evaluating the model equations,
-and finally retrieving the
-outputs before proceeding the simulation with the next downstream
-component.
-If allowFlowReversal=true, then the connectors have additional
-signals for the properties of the fluid if it flows backwards.
+ If this model is used to cool air below the dew point temperature,
+ the water mass fraction will not change.
-Most components have a boolean parameter use_p_in.
-If use_p_in=true, then the pressure is used from the
-connector, and based on the mass flow rate, the outlet pressure
-is computed and assigned to the outlet connectors.
-If use_p_in=false, then the pressure as declared
-by the constant p_default of the medium model is
-used, and the component computes no pressure drop.
-Setting use_p_in=false therefore leads to fewer
-equations, but it requires a component that specifies the mass
-flow rate, such as
-
-AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.IdealSource_m_flow.
+ Note that for use_TSet = false, the enthalpy of the
+ leaving fluid will not be changed, even if moisture is added. The
+ enthalpy added (or removed) by the change in humidity is neglected.
+ To properly account for change in enthalpy due to humidification, use
+ instead AixLib.Fluid.Humidifiers.SprayAirWasher_X.
-Notes
+
+ Validation
+
-Note the following when exporting HVAC component models as an FMU:
+ The model has been validated against the analytical solution in the
+ examples AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet
+ and
+ AixLib.Fluid.HeatExchangers.Validation.PrescribedOutlet_dynamic.
-
--
+
+ - March 3, 2022, by Michael Wetter:
+ Removed massDynamics.
+ This is for issue
+ 1542.
+
+ - May 3, 2017, by Michael Wetter:
+ Updated protected model for #763.
+
+ - December 1, 2016, by Michael Wetter:
+ Updated model as use_dh is no longer a parameter in
+ the pressure drop model.
+ This is for #480.
+
+ - November 11, 2014, by Michael Wetter:
+ Revised implementation.
+
+ - March 19, 2014, by Christoph Nytsch-Geusen:
+ First implementation.
+
+
+
+-------- Errors --------
+line 34 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Actuators/BaseClasses/PartialDamperExponential.mo ----
+-------- HTML Code --------
+
+
+ Partial model for air dampers with exponential opening characteristics.
+ This is the base model for air dampers.
+ The model implements the functions that relate the opening signal and the
+ flow coefficient.
+ The model also defines parameters that are used by different air damper
+ models.
+
+
+ The model is as in ASHRAE 825-RP except that a control signal of
+ y=0 means the damper is closed, and y=1 means
+ the damper is open.
+ This is opposite of the implementation of ASHRAE 825-RP, but used here
+ for consistency within this library.
+
+
+ For yL < y < yU, the damper characteristics is:
+
+
+ kd(y) = exp(a+b (1-y))
+
+
+ where kd is the loss coefficient (total pressure drop divided
+ by dynamic pressure) and y is the fractional opening.
+
+
+ Outside this range, the damper characteristics is defined by a quadratic polynomial that
+ matches the damper resistance at y=0 and y=yL or
+ y=yU and y=1, respectively.
+ In addition, the polynomials are such that kd(y) is differentiable in
+ y and the derivative is continuous.
+
+
+ The damper characteristics is then used to compute the flow coefficient k(y) as:
+
+
+ k(y) = (2 ρ ⁄ kd(y))1/2 A
+
+
+ where A is the face area, which is computed using the nominal
+ mass flow rate m_flow_nominal, the nominal velocity
+ v_nominal and the density of the medium.
+
+
+ ASHRAE 825-RP lists the following parameter values as typical (note that the
+ default values in the model correspond to opposed blades).
+
+
+
+
+ | opposed blades | single blades |
+
+
+ | yL | 15/90 | 15/90 |
+
+
+ | yU | 55/90 | 65/90 |
+
+
+ | k1 | 0.2 to 0.5 | 0.2 to 0.5 |
+
+
+ | a | -1.51 | -1.51 |
+
+
+ | b | 0.105*90 | 0.0842*90 |
+
+
+
+ (The loss coefficient in fully closed position k0 is computed based on the leakage coefficient
+ and the coefficient in fully open position.)
+
+ References
+
+ P. Haves, L. K. Norford, M. DeSimone and L. Mei,
+ A Standard Simulation Testbed for the Evaluation of Control Algorithms & Strategies,
+ ASHRAE Final Report 825-RP, Atlanta, GA.
+
+
+
+ -
+ September 21, 2021, by Michael Wetter:
+ Corrected typo in comments.
+ This is for
+ #1525.
+
+ -
+ December 23, 2019, by Antoine Gautier:
+ Removed the equations involving m_flow and dp that now need
+ to be added in each derived damper model.
+ Added the declaration of dpDamper_nominal and dpFixed_nominal.
+ Replaced k0 by leakage coefficient.
+ Modified the limiting values for k0 and k1.
+ This is for
+ #1188.
+
+ -
+ March 22, 2017, by Michael Wetter:
+ Added back v_nominal, but set the assignment of A
+ to be final. This allows scaling the model with m_flow_nominal,
+ which is generally known in the flow leg,
+ and v_nominal, for which a default value can be specified.
+ This is for
+ #544.
+
+ -
+ October 12, 2016 by David Blum:
+ Removed parameter v_nominal and variable area,
+ to simplify parameterization of the model.
+ Also added assertion statements upon initialization
+ for parameters k0 and k1 so that they fall within
+ suggested ranges found in ASHRAE 825-RP. This is for
+ #544.
+
+ -
+ January 27, 2015 by Michael Wetter:
+ Set Evaluate=true for use_constant_density.
+ This is a structural parameter. Adding this annotation leads to fewer
+ numerical Jacobians for
+ Buildings.Examples.VAVReheat.ClosedLoop
+ with
+ Buildings.Media.PerfectGases.MoistAirUnsaturated.
+
+ -
+ December 14, 2012 by Michael Wetter:
+ Renamed protected parameters for consistency with the naming conventions.
+
+ -
+ January 16, 2012 by Michael Wetter:
+ To simplify object inheritance tree, revised base classes
+ AixLib.Fluid.BaseClasses.PartialResistance,
+ AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve,
+ AixLib.Fluid.Actuators.BaseClasses.PartialDamperExponential,
+ AixLib.Fluid.Actuators.BaseClasses.PartialActuator
+ and model
+ AixLib.Fluid.FixedResistances.PressureDrop.
+
+ -
+ August 5, 2011, by Michael Wetter:
+ Moved linearized pressure drop equation from the function body to the equation
+ section. With the previous implementation,
+ the symbolic processor may not rearrange the equations, which can lead
+ to coupled equations instead of an explicit solution.
+
+ -
+ June 22, 2008 by Michael Wetter:
+ Extended range of control signal from 0 to 1 by implementing the function
+
+ exponentialDamper.
+
+ -
+ June 10, 2008 by Michael Wetter:
+ First implementation.
+
+
+
+-------- Corrected Code --------
-For models with control volumes,
-the mass balance must be configured using
-massDynamics=Modelica.Fluid.Types.Dynamics.SteadyState
-when used with the media
-
-AixLib.Media.Air.
-Otherwise, the translation stops with the error
+ Partial model for air dampers with exponential opening
+ characteristics. This is the base model for air dampers. The model
+ implements the functions that relate the opening signal and the flow
+ coefficient. The model also defines parameters that are used by
+ different air damper models.
-
-The model requires derivatives of some inputs as listed below:
-1 inlet.p
-
-The reason is that for
-
-AixLib.Media.Air,
-mass is proportional to pressure and pressure is proportional
-to density. Hence, dm/dt requires dp/dt,
-but the time derivative of the pressure is not an input to the model.
+ The model is as in ASHRAE 825-RP except that a control signal of
+ y=0 means the damper is closed, and y=1
+ means the damper is open. This is opposite of the implementation of
+ ASHRAE 825-RP, but used here for consistency within this library.
-For
-AixLib.Media.Water, this setting is not needed
-as the mass is independent of pressure.
+ For yL < y < yU, the damper characteristics is:
+
+
+ kd(y) = exp(a+b (1-y))
-
--
-The model
-
-AixLib.Fluid.Movers.FlowControlled_m_flow
-cannot be exported as an FMU.
-This is because it assignes the mass flow rate.
-However, the input connector
-
-AixLib.Fluid.FMI.Interfaces.Inlet
-already declares the mass flow rate as an input.
-Therefore, the mass flow rate is overdetermined.
-As a fall back, if a user needs to set the mass flow rate, he/she can
-do so by using
-
-AixLib.Fluid.FMI.Source_T,
-which takes as an input signal the mass flow rate.
+ where kd is the loss coefficient (total pressure drop divided
+ by dynamic pressure) and y is the fractional opening.
-
-
-When connecting fluid flow components in a loop,
-be careful to avoid circular assignments for example for the temperature,
-as these can of course not be simulated.
-An example of such an ill-posed problem is to connect the outlet of
-
-AixLib.Fluid.FixedResistances.PressureDrop
-to its inlet. In this situation, neither pressure, nor mass flow rate or temperature
-can be computed. To model such loops, a control volume with a dynamic energy
-balance must be presented, and the medium needs to be compressible.
+ Outside this range, the damper characteristics is defined by a
+ quadratic polynomial that matches the damper resistance at
+ y=0 and y=yL or y=yU and
+ y=1, respectively. In addition, the polynomials are such
+ that kd(y) is differentiable in y and the
+ derivative is continuous.
-References
-Michael Wetter, Marcus Fuchs and Thierry Stephane Nouidui.
-
-Design choices for thermofluid flow components and systems that are exported as Functional Mockup Units.
-Proc. of the 11th International Modelica Conference,
- p. 31-41,
- Versailles, France, September 2015.
+ The damper characteristics is then used to compute the flow
+ coefficient k(y) as:
+
+
+ k(y) = (2 ρ ⁄ kd(y))1/2 A
-
--------- Corrected Code --------
- This user's guide describes the FMI package (Wetter et al., 2015).
- The FMI package has been implemented to facilitate the export of
- thermofluid flow models such as HVAC components, HVAC systems and
- thermal zones as Functional Mockup Units (FMUs). This allows to
- export thermofluid flow models as FMUs so that they can be imported
- in other simulators. To export thermofluid flow components, a
- Modelica block is needed in order for the model to only have input
- and output signals rather than fluid connectors, as fluid connectors
- do not impose any causality on the signal flow. This package
- implements such blocks and its connectors.
+ where A is the face area, which is computed using the nominal
+ mass flow rate m_flow_nominal, the nominal velocity
+ v_nominal and the density of the medium.
- The main packages are as follows:
+ ASHRAE 825-RP lists the following parameter values as typical (note
+ that the default values in the model correspond to opposed
+ blades).
+ |
- Package
+ opposed blades
|
- Description
+ single blades
|
|
- AixLib.Fluid.FMI.ExportContainers
+ yL
|
-
- Package with blocks to export thermofluid flow components and
- systems.
-
-
- To export an HVAC component or system with a single inlet and
- outlet port, instantiate
- AixLib.Fluid.FMI.ExportContainers.ReplaceableTwoPort with a
- replaceable model, or extend from AixLib.Fluid.FMI.ExportContainers.PartialTwoPort
- and add components.
- See
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.Fan and
-
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ResistanceVolume.
-
-
- To export an HVAC system that serves a single thermal zone,
- extend from AixLib.Fluid.FMI.ExportContainers.HVACZone
- and add the HVAC system.
- See
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZone.
-
-
- To export an HVAC system that serves multiple thermal zones,
- extend from AixLib.Fluid.FMI.ExportContainers.HVACZones
- and add the HVAC system.
- See
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZones.
-
-
- To export a single thermal zone, extend from AixLib.Fluid.FMI.ExportContainers.ThermalZone
- and add the thermal zone.
- See
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZone.
-
-
- To export multiple thermal zones, extend from AixLib.Fluid.FMI.ExportContainers.ThermalZones
- and add the thermal zone models.
- See
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZones.
-
+ 15/90
+ |
+
+ 15/90
|
|
- AixLib.Fluid.FMI.Adaptors
+ yU
|
-
- Package with adaptors to connect models with fluid ports to
- blocks that have input and output signals.
-
+ 55/90
+ |
+
+ 65/90
|
|
-
- AixLib.Fluid.FMI.Conversion
-
+ k1
|
-
- Package with blocks that convert between the signal connectors
- of AixLib.Fluid.FMI.Interfaces
- and the real input and output signal connectors of the Modelica
- Standard Library.
-
+ 0.2 to 0.5
+ |
+
+ 0.2 to 0.5
|
|
- AixLib.Fluid.FMI.Interfaces
+ a
|
-
- Package with composite connectors that have different input and
- output signals. These connectors are used to export FMUs, and
- they contain quantities such as mass flow rate, temperature,
- optional pressure, etc.
-
+ -1.51
+ |
+
+ -1.51
+ |
+
+
+ |
+ b
+ |
+
+ 0.105*90
+ |
+
+ 0.0842*90
|
- The package AixLib.Fluid.FMI.ExportContainers.Examples.FMUs
- contains various examples in which HVAC components, HVAC systems and
- thermal zones are exported as an FMU.
+ (The loss coefficient in fully closed position k0 is
+ computed based on the leakage coefficient and the coefficient in
+ fully open position.)
+
+
+ References
+
+
+ P. Haves, L. K. Norford, M. DeSimone and L. Mei, A Standard
+ Simulation Testbed for the Evaluation of Control Algorithms &
+ Strategies, ASHRAE Final Report 825-RP, Atlanta, GA.
+
+
+ - September 21, 2021, by Michael Wetter:
+ Corrected typo in comments.
+ This is for #1525.
+
+ - December 23, 2019, by Antoine Gautier:
+ Removed the equations involving m_flow and
+ dp that now need to be added in each derived damper
+ model.
+ Added the declaration of dpDamper_nominal and
+ dpFixed_nominal.
+ Replaced k0 by leakage coefficient.
+ Modified the limiting values for k0 and
+ k1.
+ This is for #1188.
+
+ - March 22, 2017, by Michael Wetter:
+ Added back v_nominal, but set the assignment of
+ A to be final. This allows scaling the model with
+ m_flow_nominal, which is generally known in the flow
+ leg, and v_nominal, for which a default value can be
+ specified.
+ This is for #544.
+
+ - October 12, 2016 by David Blum:
+ Removed parameter v_nominal and variable
+ area, to simplify parameterization of the model. Also
+ added assertion statements upon initialization for parameters
+ k0 and k1 so that they fall within
+ suggested ranges found in ASHRAE 825-RP. This is for #544.
+
+ - January 27, 2015 by Michael Wetter:
+ Set Evaluate=true for
+ use_constant_density. This is a structural parameter.
+ Adding this annotation leads to fewer numerical Jacobians for
+ Buildings.Examples.VAVReheat.ClosedLoop with
+ Buildings.Media.PerfectGases.MoistAirUnsaturated.
+
+ - December 14, 2012 by Michael Wetter:
+ Renamed protected parameters for consistency with the naming
+ conventions.
+
+ - January 16, 2012 by Michael Wetter:
+ To simplify object inheritance tree, revised base classes
+ AixLib.Fluid.BaseClasses.PartialResistance,
+ AixLib.Fluid.Actuators.BaseClasses.PartialTwoWayValve,
+ AixLib.Fluid.Actuators.BaseClasses.PartialDamperExponential,
+ AixLib.Fluid.Actuators.BaseClasses.PartialActuator and
+ model AixLib.Fluid.FixedResistances.PressureDrop.
+
+ - August 5, 2011, by Michael Wetter:
+ Moved linearized pressure drop equation from the function body to
+ the equation section. With the previous implementation, the
+ symbolic processor may not rearrange the equations, which can lead
+ to coupled equations instead of an explicit solution.
+
+ - June 22, 2008 by Michael Wetter:
+ Extended range of control signal from 0 to 1 by implementing the
+ function exponentialDamper.
+
+ - June 10, 2008 by Michael Wetter:
+ First implementation.
+
+
+
+-------- Errors --------
+line 50 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+
+
+---- AixLib/Media/Antifreeze/EthyleneGlycolWater.mo ----
+-------- HTML Code --------
+
+
+ This base properties model is identical to
+
+ Modelica.Media.Water.ConstantPropertyLiquidWater,
+ except that the equation
+ u = cv_const*(T - reference_T)
+ has been replaced by u=h because
+ cp_const=cv_const.
+ Also, the model checks if the mass fraction of the mixture is within the
+ allowed limits.
+
+
+
+ Density of propylene antifreeze-water mixture at specified mass fraction
+ and temperature, based on Melinder (2010).
+
+ References
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
+ Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
+ IIR/IIF.
+
+
+
+
+
+ Dynamic viscosity of antifreeze-water mixture at specified mass fraction and
+ temperature, based on Melinder (2010).
+
+ References
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
+ Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
+ IIR/IIF.
+
+
+
+
+
+ Fusion temperature of antifreeze-water mixture at specified mass fraction and
+ temperature, based on Melinder (2010).
+
+ References
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
+ Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
+ IIR/IIF.
+
+
+
+
+
+ Evaluates a thermophysical property of a mixture, based on correlations proposed
+ by Melinder (2010).
+
+
+ The polynomial has the form
+
+
+ f = a1 (x-xm)0(y-ym)0
+ + a2 (x-xm)0(y-ym)1
+ + ... +
+ any[1] (x-xm)0(y-ym)ny[1]-1
+ + ... +
+ any[1])+1 (x-xm)1(y-ym)0
+ + ... +
+ any[1]+ny[2] (x-xm)1(y-ym)ny[2]-1
+ + ...
+
+ References
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
+ Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
+ IIR/IIF.
+
+
+
+ -
+ March 16, 2018 by Massimo Cimmino:
+ First implementation.
+ This function is used models in
+
+ AixLib.Media.Antifreeze.
+
+
+
+
+ Specific heat capacity of antifreeze-water mixture at specified mass fraction
+ and temperature, based on Melinder (2010).
+
+ References
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
+ Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
+ IIR/IIF.
+
+
+
+
+
+ Thermal conductivity of antifreeze-water mixture at specified mass fraction and
+ temperature, based on Melinder (2010).
+
+ References
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids (Secondary
+ Refrigerants or Coolants, Heat Transfer Fluids) for Indirect Systems. Paris:
+ IIR/IIF.
+
+
+
+
+
+ This medium package models ethylene glycol - water mixtures.
+
+
+ The mass density, specific heat capacity, thermal conductivity and viscosity
+ are assumed constant and evaluated at a set temperature and mass fraction of
+ ethylene glycol within the mixture. The dependence of the four properties
+ are shown on the figure below.
+
+
+
+
+
+ The accuracy of the thermophysical properties is dependent on the temperature
+ variations encountered during simulations.
+ The figure below shows the relative error of the the four properties over a
+ 10 °C range around the temperature used to evaluate the constant
+ properties. The maximum errors are 0.8 % for mass density, 2.7 %
+ for specific heat capacity, 3.2 % for thermal conductivity and 160
+ % for dynamic viscosity.
+
+
+
+
+
+ The figure below shows the relative error of the the four properties over a
+ 20 °C range around the temperature used to evaluate the constant
+ proepties. The maximum errors are 1.5 % for mass density, 5.3 %
+ for specific heat capacity, 5.9 % for thermal conductivity and 500
+ % for dynamic viscosity.
+
+
+
+
+
+ The enthalpy is computed using the convention that h=0
+ if T=0 °C.
+
+ Limitations
+
+ Density, specific heat capacity, thermal conductivity and viscosity are constant.
+ The ethylene glycol/water mixture is modeled as an incompressible liquid.
+ There are no phase changes. The medium is limited to temperatures below
+ 100 °C and mass fractions below 0.60.
+ As is the case for AixLib.Media.Water,
+ this medium package should not be used if
+ the simulation relies on the dynamic viscosity.
+
+ Typical use and important parameters
+
+ The temperature and mass fraction must be specified for the evaluation of the
+ constant thermophysical properties. A typical use of the package is (e.g. for
+ a temperature of 20 °C and a mass fraction of 0.40):
+
+
+ Medium = AixLib.Media.Antifreeze.EthyleneGlycolWater(property_T=293.15, X_a=0.40)
+
+
+
+ -
+ August 05, 2020, by Wen HU:
+ First implementation.
+
+
+
+-------- Corrected Code --------
+
+ This base properties model is identical to Modelica.Media.Water.ConstantPropertyLiquidWater,
+ except that the equation u = cv_const*(T - reference_T)
+ has been replaced by u=h because
+ cp_const=cv_const. Also, the model checks if the mass
+ fraction of the mixture is within the allowed limits.
+
+
+ Density of propylene antifreeze-water mixture at specified mass
+ fraction and temperature, based on Melinder (2010).
- Typical use
+ References
- Users who want to export a single thermofluid flow component, or a
- subsystem of thermofluid flow components, can use the block AixLib.Fluid.FMI.ExportContainers.ReplaceableTwoPort.
- This block has a fluid inlet, a fluid outlet, and a replaceable
- component that can be replaced with an HVAC component or system that
- has an inlet and outlet fluid port.
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids
+ (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
+ Indirect Systems. Paris: IIR/IIF.
+
- Users who want to export a whole HVAC system that serves a single
- thermal zone can do so by extending the partial block AixLib.Fluid.FMI.ExportContainers.HVACZone.
- The example
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.HVACZone
- illustrates how this can be accomplished.
- Similar export containers and examples are implemented for HVAC
- systems that serve multiple thermal zones.
+ Dynamic viscosity of antifreeze-water mixture at specified mass
+ fraction and temperature, based on Melinder (2010).
+
+ References
+
- Conversely, to export a thermal zone, users can extend the partial
- block AixLib.Fluid.FMI.ExportContainers.ThermalZone.
- The example
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.ThermalZone
- illustrates how this can be accomplished.
- Similar export containers and examples are implemented for models of
- multiple thermal zones.
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids
+ (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
+ Indirect Systems. Paris: IIR/IIF.
+
- Each example and validation model has a Dymola script that either
- simulates the model, or exports the model as an FMU. The script can
- be invoked from the pull down menu Commands -> Export
- FMU.
+ Fusion temperature of antifreeze-water mixture at specified mass
+ fraction and temperature, based on Melinder (2010).
- Options
+ References
- In the AixLib.Fluid package,
- most models have a boolean parameter called
- allowFlowReversal. If set to true, then the
- flow can be in either direction, otherwise it needs to be from the
- inlet to the outlet port. This parameter is also used in the AixLib.Fluid.FMI package. The
- package was designed in such a way that an FMU, if exported with
- allowFlowReversal=false has as input the mass flow rate,
- pressure and fluid properties of the inflowing fluid. The outputs are
- the outlet mass flow rate, outlet pressure and the fluid properties
- of the outflowing medium. This allows simulators such as Ptolemy II
- to evaluate the FMUs in the direction of the mass flow by first
- setting all inputs, then evaluating the model equations, and finally
- retrieving the outputs before proceeding the simulation with the next
- downstream component. If allowFlowReversal=true, then
- the connectors have additional signals for the properties of the
- fluid if it flows backwards.
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids
+ (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
+ Indirect Systems. Paris: IIR/IIF.
+
- Most components have a boolean parameter use_p_in. If
- use_p_in=true, then the pressure is used from the
- connector, and based on the mass flow rate, the outlet pressure is
- computed and assigned to the outlet connectors. If
- use_p_in=false, then the pressure as declared by the
- constant p_default of the medium model is used, and the
- component computes no pressure drop. Setting
- use_p_in=false therefore leads to fewer equations, but
- it requires a component that specifies the mass flow rate, such as
-
- AixLib.Fluid.FMI.ExportContainers.Examples.FMUs.IdealSource_m_flow.
+ Evaluates a thermophysical property of a mixture, based on
+ correlations proposed by Melinder (2010).
+
+
+ The polynomial has the form
+
+
+ f = a1 (x-xm)0(y-ym)0 +
+ a2 (x-xm)0(y-ym)1 + ... +
+ any[1] (x-xm)0(y-ym)ny[1]-1 + ... +
+ any[1])+1 (x-xm)1(y-ym)0 + ... +
+ any[1]+ny[2] (x-xm)1(y-ym)ny[2]-1 +
+ ...
- Notes
+ References
- Note the following when exporting HVAC component models as an FMU:
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids
+ (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
+ Indirect Systems. Paris: IIR/IIF.
-
- -
-
- For models with control volumes, the mass balance must be
- configured using
- massDynamics=Modelica.Fluid.Types.Dynamics.SteadyState
- when used with the media AixLib.Media.Air. Otherwise,
- the translation stops with the error
-
-
-The model requires derivatives of some inputs as listed below:
-1 inlet.p
-
-
- The reason is that for AixLib.Media.Air, mass is
- proportional to pressure and pressure is proportional to density.
- Hence, dm/dt requires dp/dt, but the time
- derivative of the pressure is not an input to the model.
-
-
- For AixLib.Media.Water, this
- setting is not needed as the mass is independent of pressure.
-
+
+
+ Specific heat capacity of antifreeze-water mixture at specified mass
+ fraction and temperature, based on Melinder (2010).
+
+
+ References
+
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids
+ (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
+ Indirect Systems. Paris: IIR/IIF.
+
+
+
+
+ Thermal conductivity of antifreeze-water mixture at specified mass
+ fraction and temperature, based on Melinder (2010).
+
+
+ References
+
+
+ Melinder, Åke. 2010. Properties of Secondary Working Fluids
+ (Secondary Refrigerants or Coolants, Heat Transfer Fluids) for
+ Indirect Systems. Paris: IIR/IIF.
+
+
+
+ This medium package models ethylene glycol - water mixtures.
+
+
+ The mass density, specific heat capacity, thermal conductivity and
+ viscosity are assumed constant and evaluated at a set temperature and
+ mass fraction of ethylene glycol within the mixture. The dependence
+ of the four properties are shown on the figure below.
+
+
+
+
+
+ The accuracy of the thermophysical properties is dependent on the
+ temperature variations encountered during simulations. The figure
+ below shows the relative error of the the four properties over a
+ 10 °C range around the temperature used to evaluate the
+ constant properties. The maximum errors are 0.8 % for mass
+ density, 2.7 % for specific heat capacity, 3.2 % for
+ thermal conductivity and 160 % for dynamic viscosity.
+
+
+
+
+
+ The figure below shows the relative error of the the four properties
+ over a 20 °C range around the temperature used to evaluate the
+ constant proepties. The maximum errors are 1.5 % for mass
+ density, 5.3 % for specific heat capacity, 5.9 % for
+ thermal conductivity and 500 % for dynamic viscosity.
+
+
+
+
- When connecting fluid flow components in a loop, be careful to avoid
- circular assignments for example for the temperature, as these can of
- course not be simulated. An example of such an ill-posed problem is
- to connect the outlet of AixLib.Fluid.FixedResistances.PressureDrop
- to its inlet. In this situation, neither pressure, nor mass flow rate
- or temperature can be computed. To model such loops, a control volume
- with a dynamic energy balance must be presented, and the medium needs
- to be compressible.
+ The enthalpy is computed using the convention that h=0 if
+ T=0 °C.
- References
+ Limitations
- Michael Wetter, Marcus Fuchs and Thierry Stephane Nouidui.
-
- Design choices for thermofluid flow components and systems that are
- exported as Functional Mockup Units.
- Proc. of the 11th International Modelica Conference, p. 31-41,
- Versailles, France, September 2015.
+ Density, specific heat capacity, thermal conductivity and viscosity
+ are constant. The ethylene glycol/water mixture is modeled as an
+ incompressible liquid. There are no phase changes. The medium is
+ limited to temperatures below 100 °C and mass fractions below
+ 0.60. As is the case for AixLib.Media.Water, this medium
+ package should not be used if the simulation relies on the dynamic
+ viscosity.
+
+
+ Typical use and important parameters
+
+
+ The temperature and mass fraction must be specified for the
+ evaluation of the constant thermophysical properties. A typical use
+ of the package is (e.g. for a temperature of 20 °C and a mass
+ fraction of 0.40):
+
+
+ Medium =
+ AixLib.Media.Antifreeze.EthyleneGlycolWater(property_T=293.15,
+ X_a=0.40)
+
+ - August 05, 2020, by Wen HU:
+ First implementation.
+
+
-------- Errors --------
-line 18 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+line 9 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/infiniteLineSource.mo ----
+line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+line 24 column 2 - Warning: attribute "align" not allowed for HTML5
+line 35 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/BaseClasses/FlowModels/basicFlowFunction_dp.mo ----
-------- HTML Code --------
- This function evaluates the infinite line source solution. This solution gives
- the relation between the constant heat transfer rate (per unit length) injected
- by a line heat source of infinite length and the temperature raise in the
- medium. The infinite line source solution is defined by
-
-
-
+ Function that computes the pressure drop of flow elements as
-
- where ΔT(t,r) is the temperature raise after a time t of
- constant heat injection and at a distance r from the line source,
- Q' is the heat injection rate per unit length, ks is
- the soil thermal conductivity and hILS is the infinite line
- source solution.
+
+ m = sign(Δp) k √ Δp
- The infinite line source solution is given by the exponential integral
+ with regularization near the origin.
+ Therefore, the flow coefficient is
-
-
+
+ k = m ⁄ √ Δp
- where αs is the ground thermal diffusivity. The
- exponential integral is implemented in
- AixLib.Utilities.Math.Functions.exponentialIntegralE1.
+ The input m_flow_turbulent determines the location of the regularization.
-
- March 22, 2018 by Massimo Cimmino:
+ November 9, 2019, by Filip Jorissen:
+ Added smooth(2, . ) for avoiding
+ a warning in the check valve model.
+ See #1240.
+
+ -
+ January 4, 2019, by Michael Wetter:
+ Set `Inline=false`.
+ See #1070.
+
+ -
+ May 1, 2017, by Filip Jorissen:
+ Revised implementation such that
+ basicFlowFunction_dp
+ is C2 continuous.
+ See #725.
+
+ -
+ March 19, 2016, by Michael Wetter:
+ Added abs function for
+ AixLib.Fluid.FixedResistances.Validation.PressureDropsExplicit
+ to work in OpenModelica.
+ See
+ OpenModelica ticket 3778.
+
+ -
+ January 22, 2016, by Michael Wetter:
+ Corrected type declaration of pressure difference.
+ This is
+ for #404.
+
+ -
+ July 28, 2015, by Michael Wetter:
+ Removed double declaration of smooth(..) and smoothOrder
+ and changed Inline=true to LateInline=true.
+ This is for
+ issue 301.
+
+ -
+ July 15, 2015, by Filip Jorissen:
+ New, more efficient implementation based on regularisation using simple polynomial.
+ Expanded common subexpressions for function inlining to be possible.
+ Set Inline=true for inlining to occur.
+ This is for
+ #279.
+
+ -
+ January 9, 2014, by Michael Wetter:
+ Correct revision section, of which there were two.
+
+ -
+ August 10, 2011, by Michael Wetter:
+ Removed if-then optimization that set m_flow=0 if dp=0,
+ as this causes the derivative to be discontinuous at dp=0.
+
+ -
+ August 4, 2011, by Michael Wetter:
+ Removed option to use a linear function. The linear implementation is now done
+ in models that call this function. With the previous implementation,
+ the symbolic processor may not rearrange the equations, which can lead
+ to coupled equations instead of an explicit solution.
+
+ -
+ March 29, 2010 by Michael Wetter:
+ Changed implementation to allow k=0, which is
+ the case for a closed valve with no leakage
+
+ -
+ April 13, 2009, by Michael Wetter:
First implementation.
-------- Corrected Code --------
- This function evaluates the infinite line source solution. This
- solution gives the relation between the constant heat transfer rate
- (per unit length) injected by a line heat source of infinite length
- and the temperature raise in the medium. The infinite line source
- solution is defined by
-
-
-
+ Function that computes the pressure drop of flow elements as
-
- where ΔT(t,r) is the temperature raise after a time t
- of constant heat injection and at a distance r from the line
- source, Q' is the heat injection rate per unit length,
- ks is the soil thermal conductivity and
- hILS is the infinite line source solution.
+
+ m = sign(Δp) k √ Δp
+
- The infinite line source solution is given by the exponential
- integral
+ with regularization near the origin. Therefore, the flow coefficient
+ is
-
-
+
+ k = m ⁄ √ Δp
+
- where αs is the ground thermal diffusivity. The
- exponential integral is implemented in AixLib.Utilities.Math.Functions.exponentialIntegralE1.
+ The input m_flow_turbulent determines the location of
+ the regularization.
- - March 22, 2018 by Massimo Cimmino:
+ - November 9, 2019, by Filip Jorissen:
+ Added smooth(2, . ) for avoiding a warning in the
+ check valve model.
+ See #1240.
+
+ - January 4, 2019, by Michael Wetter:
+ Set `Inline=false`.
+ See #1070.
+
+ - May 1, 2017, by Filip Jorissen:
+ Revised implementation such that
+ basicFlowFunction_dp is C2 continuous. See #725.
+
+ - March 19, 2016, by Michael Wetter:
+ Added abs function for
+ AixLib.Fluid.FixedResistances.Validation.PressureDropsExplicit
+ to work in OpenModelica. See OpenModelica
+ ticket 3778.
+
+ - January 22, 2016, by Michael Wetter:
+ Corrected type declaration of pressure difference. This is for
+ #404.
+
+ - July 28, 2015, by Michael Wetter:
+ Removed double declaration of smooth(..) and
+ smoothOrder and changed Inline=true to
+ LateInline=true. This is for issue 301.
+
+ - July 15, 2015, by Filip Jorissen:
+ New, more efficient implementation based on regularisation using
+ simple polynomial. Expanded common subexpressions for function
+ inlining to be possible. Set Inline=true for inlining
+ to occur. This is for #279.
+
+ - January 9, 2014, by Michael Wetter:
+ Correct revision section, of which there were two.
+
+ - August 10, 2011, by Michael Wetter:
+ Removed if-then optimization that set
+ m_flow=0 if dp=0, as this causes the
+ derivative to be discontinuous at dp=0.
+
+ - August 4, 2011, by Michael Wetter:
+ Removed option to use a linear function. The linear implementation
+ is now done in models that call this function. With the previous
+ implementation, the symbolic processor may not rearrange the
+ equations, which can lead to coupled equations instead of an
+ explicit solution.
+
+ - March 29, 2010 by Michael Wetter:
+ Changed implementation to allow k=0, which is the case
+ for a closed valve with no leakage
+
+ - April 13, 2009, by Michael Wetter:
First implementation.
-------- Errors --------
-line 8 column 2 - Warning: attribute "align" not allowed for HTML5
-line 21 column 2 - Warning: attribute "align" not allowed for HTML5
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+line 12 column 2 - Warning: attribute "align" not allowed for HTML5
diff --git a/docs/ci_updates/syntax/HTML_error_log.txt b/docs/ci_updates/syntax/HTML_error_log.txt
index ddd8f0f243..69ad4a61f3 100644
--- a/docs/ci_updates/syntax/HTML_error_log.txt
+++ b/docs/ci_updates/syntax/HTML_error_log.txt
@@ -1,179 +1,193 @@
----- AixLib/Fluid/FixedResistances/BaseClasses/PlugFlow.mo ----
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/HeatPumps/Compressors/ScrollCompressor.mo ----
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/finiteLineSource_Erfint.mo ----
line 5 column 2 - Warning: attribute "align" not allowed for HTML5
-line 11 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/finiteLineSource_Erfint.mo ----
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/BoundaryConditions/Validation/BESTEST/WD500.mo ----
+line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/Movers/BaseClasses/Characteristics/pressure.mo ----
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/BoundaryConditions/UsersGuide.mo ----
+line 60 column 1 - Warning: attribute "align" not allowed for HTML5
+line 61 column 1 - Warning: attribute "align" not allowed for HTML5
+line 62 column 1 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FMI/ExportContainers/ThermalZones.mo ----
-line 78 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/finiteLineSource.mo ----
+line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+line 25 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Media/Water.mo ----
-line 17 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Media/Specialized/Air/PerfectGas.mo ----
+line 25 column 2 - Warning: attribute "align" not allowed for HTML5
-line 18 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatExchangers/SensibleCooler_T.mo ----
+line 29 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/BoundaryConditions/Validation/UsersGuide.mo ----
-line 14 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
-line 98 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Fluid/FMI/ExportContainers/HVACZone.mo ----
+line 47 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/Heater_T.mo ----
-line 29 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Chillers/Carnot_y.mo ----
+line 16 column 2 - Warning: attribute "align" not allowed for HTML5
+line 24 column 2 - Warning: attribute "align" not allowed for HTML5
+line 34 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/ThermalZones/ReducedOrder/RC/TwoElements.mo ----
-line 14 column 4 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Movers/Data/Pumps/Wilo/Stratos25slash1to6.mo ----
+line 27 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Utilities/Math/Functions/biquadratic.mo ----
+---- AixLib/Utilities/Math/Functions/bicubic.mo ----
line 3 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Utilities/Math/Polynomial.mo ----
-line 3 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/FixedResistances/HydraulicDiameter.mo ----
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+line 104 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Utilities/Math/QuadraticLinear.mo ----
-line 3 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatPumps/Carnot_y.mo ----
+line 16 column 2 - Warning: attribute "align" not allowed for HTML5
+line 24 column 2 - Warning: attribute "align" not allowed for HTML5
+line 34 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/BaseClasses/HANaturalCylinder.mo ----
-line 11 column 14 - Warning: attribute "align" not allowed for HTML5
-line 24 column 14 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/ThermalZones/ReducedOrder/RC/OneElement.mo ----
+line 16 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Utilities/IO/SignalExchange/SignalTypes/SignalsForKPIs.mo ----
-line 9 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Fluid/FixedResistances/CheckValve.mo ----
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+line 17 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/BoundaryConditions/UsersGuide.mo ----
-line 60 column 1 - Warning: attribute "align" not allowed for HTML5
-line 61 column 1 - Warning: attribute "align" not allowed for HTML5
-line 62 column 1 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/PlugFlowAIT.mo ----
+line 48 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/ThermalZones/ReducedOrder/RC/BaseClasses/InteriorWall.mo ----
-line 13 column 4 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Utilities/Math/Functions/Examples/CubicHermite.mo ----
+line 11 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/ActiveBeams/UsersGuide.mo ----
-line 7 column 1 - Warning: attribute "align" not allowed for HTML5
-line 59 column 1 - Warning: attribute "align" not allowed for HTML5
-line 72 column 1 - Warning: attribute "align" not allowed for HTML5
-line 87 column 1 - Warning: attribute "align" not allowed for HTML5
-line 115 column 1 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatExchangers/ConstantEffectiveness.mo ----
+line 8 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/HydraulicDiameter.mo ----
+---- AixLib/Fluid/HeatPumps/ReciprocatingWaterToWater.mo ----
line 6 column 2 - Warning: attribute "align" not allowed for HTML5
-line 104 column 2 - Warning: attribute "align" not allowed for HTML5
+line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+line 18 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/BaseClasses/PlugFlowHeatLoss.mo ----
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
-line 17 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Utilities/Math/Functions/biquadratic.mo ----
+line 3 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/SensibleCooler_T.mo ----
-line 29 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/FixedResistances/BaseClasses/PlugFlowTransportDelay.mo ----
+line 7 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/EvaporatorCondenser.mo ----
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/GroundTemperatureResponse.mo ----
+line 22 column 2 - Warning: attribute "align" not allowed for HTML5
+line 37 column 2 - Warning: attribute "align" not allowed for HTML5
+line 46 column 2 - Warning: attribute "align" not allowed for HTML5
+line 58 column 2 - Warning: attribute "align" not allowed for HTML5
+line 73 column 2 - Warning: attribute "align" not allowed for HTML5
+line 101 column 2 - Warning: attribute "align" not allowed for HTML5
+line 117 column 2 - Warning: attribute "align" not allowed for HTML5
+line 120 column 2 - Warning: attribute "align" not allowed for HTML5
+line 129 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/Junction.mo ----
-line 23 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Utilities/Math/Bicubic.mo ----
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Movers/Validation/PowerSimplified.mo ----
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/Cylindrical.mo ----
+line 9 column 2 - Warning: attribute "align" not allowed for HTML5
line 29 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/ActiveBeams/Data/BaseClasses/TemperatureDifference.mo ----
-line 8 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatExchangers/BaseClasses/PartialEffectivenessNTU.mo ----
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Controls/Discrete/BooleanDelay.mo ----
-line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatExchangers/ActiveBeams/BaseClasses/Convector.mo ----
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Utilities/Math/Functions/quadraticLinear.mo ----
-line 3 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/FixedResistances/Junction.mo ----
+line 23 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Media/Air.mo ----
-line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Media/Water.mo ----
+line 17 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 7 column 2 - Warning: attribute "align" not allowed for HTML5
+line 18 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Actuators/BaseClasses/exponentialDamper.mo ----
+line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Movers/BaseClasses/Characteristics/efficiency.mo ----
line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatExchangers/ActiveBeams/Data/BaseClasses/TemperatureDifference.mo ----
line 8 column 2 - Warning: attribute "align" not allowed for HTML5
-line 21 column 2 - Warning: attribute "align" not allowed for HTML5
-line 29 column 2 - Warning: attribute "align" not allowed for HTML5
-line 37 column 2 - Warning: attribute "align" not allowed for HTML5
-line 11 column 2 - Warning: attribute "align" not allowed for HTML5
-line 19 column 2 - Warning: attribute "align" not allowed for HTML5
-line 43 column 2 - Warning: attribute "align" not allowed for HTML5
-line 54 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/FixedResistances/BaseClasses/PlugFlow.mo ----
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/FMI/ExportContainers/HVACZones.mo ----
line 60 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/BaseClasses/WetCoilWetRegime.mo ----
-line 20 column 2 - Warning: attribute "align" not allowed for HTML5
-line 36 column 2 - Warning: attribute "align" not allowed for HTML5
-line 48 column 2 - Warning: attribute "align" not allowed for HTML5
-line 54 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatPumps/Carnot_TCon.mo ----
+line 17 column 2 - Warning: attribute "align" not allowed for HTML5
+line 25 column 2 - Warning: attribute "align" not allowed for HTML5
+line 35 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Humidifiers/Humidifier_u.mo ----
-line 9 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Sources/Outside_CpData.mo ----
+line 51 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 63 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 14 column 2 - Warning: attribute "align" not allowed for HTML5
+line 43 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Actuators/BaseClasses/exponentialDamper.mo ----
-line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/BoundaryConditions/Validation/BESTEST/WD100.mo ----
+line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/Actuators/BaseClasses/PartialDamperExponential.mo ----
-line 50 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Fluid/Types.mo ----
+line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/Boreholes/BaseClasses/Functions/convectionResistanceCircularPipe.mo ----
-line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/HeatPumps/Compressors/ReciprocatingCompressor.mo ----
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
-line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+line 13 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/Interfaces/PrescribedOutlet.mo ----
-line 18 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/PlugFlowULg.mo ----
+line 25 column 2 - Warning: attribute "align" not allowed for HTML5
+line 27 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/ThermalZones/ReducedOrder/RC/BaseClasses/ExteriorWall.mo ----
-line 14 column 4 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatExchangers/ActiveBeams/UsersGuide.mo ----
+line 7 column 1 - Warning: attribute "align" not allowed for HTML5
+line 59 column 1 - Warning: attribute "align" not allowed for HTML5
+line 72 column 1 - Warning: attribute "align" not allowed for HTML5
+line 87 column 1 - Warning: attribute "align" not allowed for HTML5
+line 115 column 1 - Warning: attribute "align" not allowed for HTML5
---- AixLib/Fluid/Chillers/BaseClasses/Carnot.mo ----
@@ -182,141 +196,174 @@ line 30 column 2 - Warning: attribute "align" not allowed for HTML5
line 39 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/UsersGuide.mo ----
-line 56 column 1 - Warning: attribute "align" not allowed for HTML5
-line 179 column 1 - Warning: attribute "align" not allowed for HTML5
-line 188 column 1 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Movers/Validation/PowerSimplified.mo ----
+line 29 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/Types.mo ----
-line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Fluid/Humidifiers/Humidifier_u.mo ----
+line 9 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/Radiators/RadiatorEN442_2.mo ----
-line 26 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatExchangers/Heater_T.mo ----
+line 29 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/ThermalZones/ReducedOrder/RC/FourElements.mo ----
-line 15 column 4 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/BoundaryConditions/Validation/BESTEST/WD600.mo ----
+line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/Humidifiers/SteamHumidifier_X.mo ----
-line 33 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Controls/Continuous/Examples/SignalRanker.mo ----
+line 8 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/LoadAggregation/Validation/ShiftAggregationCells.mo ----
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatExchangers/DryCoilEffectivenessNTU.mo ----
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Utilities/Math/Bicubic.mo ----
+---- AixLib/Fluid/Actuators/Valves/ThreeWayTable.mo ----
+line 21 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+
+
+---- AixLib/Controls/Continuous/LimPID.mo ----
line 5 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/BoundaryConditions/Validation/BESTEST/WD200.mo ----
-line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/ThermalZones/ReducedOrder/RC/BaseClasses/splitFacVal.mo ----
+line 15 column 4 - Warning: attribute "align" not allowed for HTML5
+line 27 column 4 - Warning: attribute "align" not allowed for HTML5
+line 35 column 4 - Warning: attribute "align" not allowed for HTML5
+line 43 column 4 - Warning: attribute "align" not allowed for HTML5
----- AixLib/BoundaryConditions/Validation/BESTEST/WD100.mo ----
-line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Fluid/HeatPumps/Compressors/ScrollCompressor.mo ----
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+line 11 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Sensors/SensibleEnthalpyFlowRate.mo ----
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/FMI/ExportContainers/ThermalZone.mo ----
+line 72 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/Cylindrical.mo ----
-line 9 column 2 - Warning: attribute "align" not allowed for HTML5
-line 29 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatExchangers/Radiators/RadiatorEN442_2.mo ----
+line 26 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Movers/BaseClasses/Characteristics/power.mo ----
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Geothermal/Borefields/Types.mo ----
+line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/finiteLineSource.mo ----
-line 12 column 2 - Warning: attribute "align" not allowed for HTML5
-line 25 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/ThermalZones/ReducedOrder/RC/ThreeElements.mo ----
+line 16 column 4 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatPumps/Carnot_y.mo ----
-line 16 column 2 - Warning: attribute "align" not allowed for HTML5
-line 24 column 2 - Warning: attribute "align" not allowed for HTML5
-line 34 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Sensors/UsersGuide.mo ----
+line 32 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+line 105 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+line 33 column 5 - Warning: | attribute "align" not allowed for HTML5
+line 38 column 5 - Warning: | attribute "align" not allowed for HTML5
+line 144 column 1 - Warning: attribute "align" not allowed for HTML5
+line 167 column 1 - Warning: attribute "align" not allowed for HTML5
+line 197 column 1 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Actuators/Valves/Examples/TwoWayValveTable.mo ----
-line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 24 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatPumps/ScrollWaterToWater.mo ----
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+line 18 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FMI/ExportContainers/ThermalZone.mo ----
-line 72 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatExchangers/BaseClasses/WetCoilDryWetRegime.mo ----
+line 20 column 2 - Warning: attribute "align" not allowed for HTML5
+line 23 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatPumps/ReciprocatingWaterToWater.mo ----
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Movers/Validation/PowerExact.mo ----
line 12 column 2 - Warning: attribute "align" not allowed for HTML5
-line 18 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FMI/ExportContainers/HVACZones.mo ----
-line 60 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/Boreholes/BaseClasses/Functions/convectionResistanceCircularPipe.mo ----
+line 11 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/ThermalZones/ReducedOrder/RC/ThreeElements.mo ----
-line 16 column 4 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Controls/SetPoints/Examples/OccupancySchedule.mo ----
+line 8 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Controls/SetPoints/Examples/SupplyReturnTemperatureReset.mo ----
-line 16 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/ThermalZones/ReducedOrder/RC/FourElements.mo ----
+line 15 column 4 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/gFunction.mo ----
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
-line 49 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Chillers/Carnot_TEva.mo ----
+line 17 column 2 - Warning: attribute "align" not allowed for HTML5
+line 29 column 2 - Warning: attribute "align" not allowed for HTML5
+line 39 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Movers/BaseClasses/Characteristics/efficiency.mo ----
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Utilities/Math/Functions/polynomial.mo ----
+line 4 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/PressureDrop.mo ----
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
-line 37 column 2 - Warning: attribute "align" not allowed for HTML5
-line 90 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/ThermalZones/ReducedOrder/RC/BaseClasses/InteriorWall.mo ----
+line 13 column 4 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Media/Antifreeze/EthyleneGlycolWater.mo ----
-line 9 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Utilities/Math/QuadraticLinear.mo ----
+line 3 column 2 - Warning: attribute "align" not allowed for HTML5
-line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/ThermalZones/ReducedOrder/RC/BaseClasses/ExteriorWall.mo ----
+line 14 column 4 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/BoundaryConditions/Validation/UsersGuide.mo ----
+line 14 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+line 98 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+
+
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/LoadAggregation/Validation/ShiftAggregationCells.mo ----
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Controls/Continuous/Examples/OffTimer.mo ----
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Sources/Outside_CpLowRise.mo ----
+line 28 column 2 - Warning: attribute "align" not allowed for HTML5
+line 61 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/FMI/Adaptors/HVAC.mo ----
+line 26 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Actuators/Valves/Examples/TwoWayValveTable.mo ----
+line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
line 24 column 2 - Warning: attribute "align" not allowed for HTML5
-line 35 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/ThermalZones/ReducedOrder/RC/OneElement.mo ----
-line 16 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/MSLAIT2Nodes.mo ----
+line 51 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/timeGeometric.mo ----
-line 9 column 2 - Warning: attribute "align" not allowed for HTML5
-line 18 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Media/Specialized/Water/TemperatureDependentDensity.mo ----
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Chillers/Carnot_TEva.mo ----
-line 17 column 2 - Warning: attribute "align" not allowed for HTML5
-line 29 column 2 - Warning: attribute "align" not allowed for HTML5
-line 39 column 2 - Warning: attribute "align" not allowed for HTML5
+line 7 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/CheckValve.mo ----
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
line 17 column 2 - Warning: attribute "align" not allowed for HTML5
+line 31 column 2 - Warning: attribute "align" not allowed for HTML5
+line 42 column 2 - Warning: attribute "align" not allowed for HTML5
+line 49 column 2 - Warning: attribute "align" not allowed for HTML5
+line 62 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/BaseClasses/PlugFlowTransportDelay.mo ----
-line 7 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/FixedResistances/PressureDrop.mo ----
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+line 37 column 2 - Warning: attribute "align" not allowed for HTML5
+line 90 column 2 - Warning: attribute "align" not allowed for HTML5
---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/cylindricalHeatSource.mo ----
@@ -324,50 +371,69 @@ line 8 column 2 - Warning: attribute "align" not allowed for HTML5
line 23 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Storage/UsersGuide.mo ----
-line 6 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
-line 17 column 1 - Warning: attribute "align" not allowed for HTML5
-line 129 column 1 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Media/Air.mo ----
+line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+
+
+line 7 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/BaseClasses/PartialEffectivenessNTU.mo ----
line 6 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/ConstantEffectiveness.mo ----
line 8 column 2 - Warning: attribute "align" not allowed for HTML5
+line 21 column 2 - Warning: attribute "align" not allowed for HTML5
+line 29 column 2 - Warning: attribute "align" not allowed for HTML5
+line 37 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Utilities/Math/Functions/Examples/CubicHermite.mo ----
line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+line 19 column 2 - Warning: attribute "align" not allowed for HTML5
+line 43 column 2 - Warning: attribute "align" not allowed for HTML5
+line 54 column 2 - Warning: attribute "align" not allowed for HTML5
+line 60 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Controls/Continuous/LimPID.mo ----
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/BoundaryConditions/Validation/BESTEST/WD400.mo ----
+line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/Sources/Outside_CpData.mo ----
-line 51 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 63 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 14 column 2 - Warning: attribute "align" not allowed for HTML5
-line 43 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Actuators/Valves/TwoWayTable.mo ----
+line 14 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/BaseClasses/FlowModels/basicFlowFunction_m_flow.mo ----
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
-line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/HeatExchangers/BaseClasses/HANaturalCylinder.mo ----
+line 11 column 14 - Warning: attribute "align" not allowed for HTML5
+line 24 column 14 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Controls/Continuous/Examples/SignalRanker.mo ----
-line 8 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Sensors/SensibleEnthalpyFlowRate.mo ----
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatExchangers/DryCoilEffectivenessNTU.mo ----
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Geothermal/Borefields/UsersGuide.mo ----
+line 56 column 1 - Warning: attribute "align" not allowed for HTML5
+line 179 column 1 - Warning: attribute "align" not allowed for HTML5
+line 188 column 1 - Warning: attribute "align" not allowed for HTML5
----- AixLib/BoundaryConditions/Validation/BESTEST/WD600.mo ----
-line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Fluid/HeatExchangers/BaseClasses/WetCoilWetRegime.mo ----
+line 20 column 2 - Warning: attribute "align" not allowed for HTML5
+line 36 column 2 - Warning: attribute "align" not allowed for HTML5
+line 48 column 2 - Warning: attribute "align" not allowed for HTML5
+line 54 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Controls/Discrete/BooleanDelay.mo ----
+line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Humidifiers/SteamHumidifier_X.mo ----
+line 33 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/HeatExchangers/EvaporatorCondenser.mo ----
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
---- AixLib/Media/Antifreeze/PropyleneGlycolWater.mo ----
@@ -379,78 +445,83 @@ line 24 column 2 - Warning: attribute "align" not allowed for HTML5
line 35 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/BoundaryConditions/Validation/BESTEST/WD400.mo ----
-line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-
-
----- AixLib/Controls/Continuous/Examples/OffTimer.mo ----
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/timeGeometric.mo ----
+line 9 column 2 - Warning: attribute "align" not allowed for HTML5
+line 18 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Chillers/Carnot_y.mo ----
+---- AixLib/Controls/SetPoints/Examples/SupplyReturnTemperatureReset.mo ----
line 16 column 2 - Warning: attribute "align" not allowed for HTML5
-line 24 column 2 - Warning: attribute "align" not allowed for HTML5
-line 34 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Media/Specialized/Air/PerfectGas.mo ----
-line 25 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Controls/Continuous/NumberOfRequests.mo ----
+line 7 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
---- AixLib/Utilities/Math/Biquadratic.mo ----
line 5 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Actuators/Valves/ThreeWayTable.mo ----
-line 21 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Fluid/FMI/UsersGuide.mo ----
+line 18 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/Sensors/LatentEnthalpyFlowRate.mo ----
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/FMI/ExportContainers/ThermalZones.mo ----
+line 78 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Sensors/UsersGuide.mo ----
-line 32 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
-line 105 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
-line 33 column 5 - Warning: | attribute "align" not allowed for HTML5
-line 38 column 5 - Warning: | attribute "align" not allowed for HTML5
-line 144 column 1 - Warning: attribute "align" not allowed for HTML5
-line 167 column 1 - Warning: attribute "align" not allowed for HTML5
-line 197 column 1 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/ThermalZones/ReducedOrder/RC/TwoElements.mo ----
+line 14 column 4 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/PlugFlowULg.mo ----
-line 25 column 2 - Warning: attribute "align" not allowed for HTML5
-line 27 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Utilities/Math/Polynomial.mo ----
+line 3 column 2 - Warning: attribute "align" not allowed for HTML5
---- AixLib/Fluid/Humidifiers/SprayAirWasher_X.mo ----
line 33 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/BoundaryConditions/Validation/BESTEST/WD500.mo ----
-line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Fluid/Movers/BaseClasses/Characteristics/pressure.mo ----
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Movers/Data/Pumps/Wilo/Stratos25slash1to6.mo ----
-line 27 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/BoundaryConditions/Validation/BESTEST/WD300.mo ----
+line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Fluid/HeatExchangers/BaseClasses/WetCoilDryWetRegime.mo ----
-line 20 column 2 - Warning: attribute "align" not allowed for HTML5
-line 23 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/gFunction.mo ----
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+line 49 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FMI/ExportContainers/HVACZone.mo ----
-line 47 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/BoundaryConditions/Validation/BESTEST/WD200.mo ----
+line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/Controls/Continuous/NumberOfRequests.mo ----
-line 7 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Fluid/HeatPumps/Compressors/ReciprocatingCompressor.mo ----
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+line 11 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Controls/SetPoints/Examples/OccupancySchedule.mo ----
+---- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/infiniteLineSource.mo ----
line 8 column 2 - Warning: attribute "align" not allowed for HTML5
+line 21 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Interfaces/PrescribedOutlet.mo ----
+line 18 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/Fluid/Sensors/LatentEnthalpyFlowRate.mo ----
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
+
+
+---- AixLib/BoundaryConditions/WeatherData/ReaderTMY3.mo ----
+line 24 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 425 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 469 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+line 640 column 2 - Warning: attribute "align" not allowed for HTML5
---- AixLib/Fluid/Movers/UsersGuide.mo ----
@@ -470,131 +541,60 @@ line 473 column 1 - Warning: attribute "align" not allowed for HTML5
line 484 column 1 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/MSLAIT.mo ----
-line 56 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/Sources/Outside_CpLowRise.mo ----
-line 28 column 2 - Warning: attribute "align" not allowed for HTML5
-line 61 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/FMI/Adaptors/HVAC.mo ----
-line 26 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/HeatExchangers/ActiveBeams/BaseClasses/Convector.mo ----
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Utilities/Math/Functions/bicubic.mo ----
-line 3 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/Actuators/Valves/TwoWayTable.mo ----
-line 14 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Controls/Continuous/Examples/NumberOfRequests.mo ----
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/BoundaryConditions/WeatherData/ReaderTMY3.mo ----
-line 24 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 425 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 469 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 640 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Movers/BaseClasses/Characteristics/power.mo ----
+line 6 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/BaseClasses/FlowModels/basicFlowFunction_dp.mo ----
+---- AixLib/Fluid/BaseClasses/FlowModels/basicFlowFunction_m_flow.mo ----
line 5 column 2 - Warning: attribute "align" not allowed for HTML5
line 12 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Types.mo ----
-line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-
-
-line 8 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-
-
-line 13 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-
-
----- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/PlugFlowAIT.mo ----
-line 48 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Utilities/Math/Functions/quadraticLinear.mo ----
+line 3 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/ThermalZones/ReducedOrder/RC/BaseClasses/splitFacVal.mo ----
-line 15 column 4 - Warning: attribute "align" not allowed for HTML5
-line 27 column 4 - Warning: attribute "align" not allowed for HTML5
-line 35 column 4 - Warning: attribute "align" not allowed for HTML5
-line 43 column 4 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Storage/UsersGuide.mo ----
+line 6 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
+line 17 column 1 - Warning: attribute "align" not allowed for HTML5
+line 129 column 1 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatPumps/ScrollWaterToWater.mo ----
-line 6 column 2 - Warning: attribute "align" not allowed for HTML5
-line 12 column 2 - Warning: attribute "align" not allowed for HTML5
-line 18 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/FixedResistances/BaseClasses/PlugFlowHeatLoss.mo ----
+line 10 column 2 - Warning: attribute "align" not allowed for HTML5
+line 17 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Movers/Validation/PowerExact.mo ----
-line 12 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Utilities/IO/SignalExchange/SignalTypes/SignalsForKPIs.mo ----
+line 9 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
----- AixLib/BoundaryConditions/Validation/BESTEST/WD300.mo ----
-line 5 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
+---- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/MSLAIT.mo ----
+line 56 column 2 - Warning: attribute "align" not allowed for HTML5
---- AixLib/Fluid/HeatExchangers/PrescribedOutlet.mo ----
line 34 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/GroundTemperatureResponse.mo ----
-line 22 column 2 - Warning: attribute "align" not allowed for HTML5
-line 37 column 2 - Warning: attribute "align" not allowed for HTML5
-line 46 column 2 - Warning: attribute "align" not allowed for HTML5
-line 58 column 2 - Warning: attribute "align" not allowed for HTML5
-line 73 column 2 - Warning: attribute "align" not allowed for HTML5
-line 101 column 2 - Warning: attribute "align" not allowed for HTML5
-line 117 column 2 - Warning: attribute "align" not allowed for HTML5
-line 120 column 2 - Warning: attribute "align" not allowed for HTML5
-line 129 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/FixedResistances/Validation/PlugFlowPipes/MSLAIT2Nodes.mo ----
-line 51 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Media/Specialized/Water/TemperatureDependentDensity.mo ----
-line 5 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
-line 7 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/Actuators/BaseClasses/PartialDamperExponential.mo ----
+line 50 column 2 - Warning: The summary attribute on the element is obsolete in HTML5
-line 17 column 2 - Warning: attribute "align" not allowed for HTML5
-line 31 column 2 - Warning: attribute "align" not allowed for HTML5
-line 42 column 2 - Warning: attribute "align" not allowed for HTML5
-line 49 column 2 - Warning: attribute "align" not allowed for HTML5
-line 62 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Media/Antifreeze/EthyleneGlycolWater.mo ----
+line 9 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Fluid/HeatPumps/Carnot_TCon.mo ----
-line 17 column 2 - Warning: attribute "align" not allowed for HTML5
-line 25 column 2 - Warning: attribute "align" not allowed for HTML5
+line 11 column 2 - Warning: attribute "align" not allowed for HTML5
+line 24 column 2 - Warning: attribute "align" not allowed for HTML5
line 35 column 2 - Warning: attribute "align" not allowed for HTML5
----- AixLib/Controls/Continuous/Examples/NumberOfRequests.mo ----
-line 10 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Utilities/Math/Functions/polynomial.mo ----
-line 4 column 2 - Warning: attribute "align" not allowed for HTML5
-
-
----- AixLib/Fluid/FMI/UsersGuide.mo ----
-line 18 column 1 - Warning: The summary attribute on the element is obsolete in HTML5
-
-
----- AixLib/Fluid/Geothermal/Borefields/BaseClasses/HeatTransfer/ThermalResponseFactors/infiniteLineSource.mo ----
-line 8 column 2 - Warning: attribute "align" not allowed for HTML5
-line 21 column 2 - Warning: attribute "align" not allowed for HTML5
+---- AixLib/Fluid/BaseClasses/FlowModels/basicFlowFunction_dp.mo ----
+line 5 column 2 - Warning: attribute "align" not allowed for HTML5
+line 12 column 2 - Warning: attribute "align" not allowed for HTML5
| | | |