This chapter presents the structure of the plant specification file (SIM file),
which is written to and read from by FrigoSim.
Reading this description will give you an overview of the modelling mechanisms of the program.
It will also describe how to generate a plant specification from a pre-processing program.

For each part there is a formal description of the specification file
initiated by the text "Formal input description:". Examples are supplied to illustrate the input.
The specification is sequenced in a number of data groups.
For the formal description (notation) we refer to the separate section
Formal input notation and Functions of this chapter.
The input also depends on the current model used, so you also need the individual
model descriptions.

The first line of all data sets contains a text that should briefly describe the plant.
The second line indicates the FrigoSim version that generated the file.
Example:

Air to Water Heat Pump with Two Aggregates Version 2 2 0

Formal input description:

TextTitle - Text describing the specified plant. (Max. 80 chars.) NameCommand, - Text "Version". iVersion, - Main version number. iRevision, - Version sub number. iPatch - Patch number (for error corrections between versions).

Prior to selecting models for a plant specification, the user must get acquainted
with the model range. The calculation results are only interpreted correctly
if you know the properties of the employed models.
The models carrying a Standard
tag are often the best initial choice,
as they balance between simplicity and accuracy.
Generally the user should employ the model that is most appropriate
for the accuracy required or the data basis at hand.
See the list of models.

There is one type of models that might be used where more specific
FrigoSim models are unsuitable. These are called Adapter component models.
The models only set a change of a specific variable type in
passage through the component, with no information about the size of this change.
The actual size must be specified by a boundary condition,
a difference control, or an enthalpy control.

When specifying basis components, it is often difficult to supply all necessary data.
This applies in particular to the data entered as functions.
If the data basis is insufficient, it is better to use a simple function type,
e.g. a constant value, in stead of some dubious dependency which at best is only qualitatively correct.
If a basis component handles one-dimensional heat conduction, this is indicated by HasHeat1D
.
In this case, data for a layered structure must be specified.

It is possible to attach a price tag to all basis components. The total plant cost
is then automatically calculated and put into the predefined derived quantities output "Cost
",
that is available through the plant component at the top of the screen.
Evidently this only includes the components' cost and only of the components
that are included in the plant description. However by setting the invariant costs "CostInv
"in Parameter control, also non-component costs could be given a dynamic value
through functions and modifiers.
Plant components refer to basis components for properties.
Similar to basis component price tags, it is also possible to specify a weight to
a basis component. All component weights will be summed up to a total plant weight.

Example of data for the three basis components with names M, C and P
(The T is for table function and K is for a constant):

M motNorm 1.000E+0004 T 4 0.000E+0000 5.000E-0001 8.000E-0001 1.000E+0000 0.000E+0000 6.000E-0001 7.500E-0001 8.000E-0001 C cndNorm 1.700E+0000 K 8.000E+0002 P pmpSec

Formal input description:

Input section header: '* Basis components *' =(NameBasis <> '$')= NameBasis, - Name of the basis component. NameModel, - Model name of the basis component. :cOption: - Basis component variant option: 'P': Price function specified. (Ref. weight mechanism) 'W': Weight function specified. (Ref. price mechanism) 'S': Using deviating component symbol. 'B': Using boundary. (Sets plant component variable HasBoundary) 'F': Basis component data fixed to specific fluid. (Any combination can be used.) (cOption = 'S') NameSymbol - Name of deviating symbol. "nDataR" DataR - Basis component constant data. =nData-nDataR= /Basis component function/ "nDataI DataI - Basis component integer data. (HasHeat1D) jShape, - Geometry selection: 1: Slab geometry. 2: Cylinder geometry. 3: Sphere geometry. dRInner, - Inner radius (coordinate of leftmost node). nLayer - Number of material layers. =nLayer= Size, - Layer size. ndR, - Number of node intervals of layer. dR1, - Size of leftmost node interval. If it is different from Size/ndX, a varying node interval size is employed. tLeft, - "Left" side layer temperature. tRight, - "Right" side layer temperature. dTime, - Initial time step required by layer. cBoundary, - Option for boundary connection: 'B': Layer has boundary at "left" side, otherwise adiabatic. NameMaterial - Name of layer material, referring to file "Material.ini". (cOption = 'P') /Price function/ (cOption = 'F') NameFluid - Name of fluid. (cOption = 'B') NameCoating, - Name of coating material, referring to properties in Coating.ini file: '?': No boundary coating. NameCoatingAlt - Name of alternative coating material replacing normal coating under special conditions: '?': No alternative boundary coating.

Fluids are of two kinds:

**Refrigerants** where all properties data are supplied by the refrigerant properties library
called RnLib.

**Secondary fluids** like air and water where required data of types specific heat capacity,
density, dynamic viscosity and thermal conductivity are supplied by the single phase
properties library FluidLib or through the input data.
The models used require what types of properties that need to be specified.
FrigoSim issues an error message if something is missing.

Example of fluid data for Air
, Sea water
and R22
,
showing the three different specification variants.
The first with reference to FluidLib,
the second with explicit properties data as functions for each necessary quantity,
and the final one with reference to RnLib.

Air Air -1 Air SeaW Sea water 1 Green C K 4.000E+0003 R22 CHF2Cl 0 Red 22

Formal input description:

Input section header: '* Fluids *' =(NameMed <> '$')= NameMed, - Fluid name. Text - Text describing the fluid. nTP, - Number of fluid properties to be specified or library option: -1: Properties from secondary fluid library used. 0: Properties from refrigerant library used. :NameColour: - Name of colour if using other than default for a library fluid. (nTP=-1) NameFluid - Name of fluid in secondary fluid library. (nTP=0) Refrig - Standard refrigerant number, ref. FrigoSim refrigerants. =nTP= cTP - Fluid property: 'C': Specific heat capacity. 'R': Density. 'M': Dynamic viscosity. 'L': Thermal conductivity. /Fluid property as a function of temperature/

A plant component is a basis component at fixed position in a plant
and supplied with a set of initial values. Each component is
connected to a set of connectors which are numbered in an arbitrary,
non-ambiguous manner. The connector references must follow a prescribed order
as defined for the current model.

The initial values are only used to generate the very first equation
system to produce the first solution. Hence the initial values are of
no significance to the final solution being written out, except if
they are controllable parameters. These parameters keep the initial
value throughout the simulation, unless modified by some control.

Normally it is not necessary to be very accurate in setting the
initial values if they are just reasonable. In particular cases where
the solution is unstable, a bad hit may create difficulties. Then a
hand calculation is recommended or just experimenting with different values
to see if a solution can be achieved.

Example of plant component data showing two plant components Evap and Comp.

Evap Evaporator E 2.300 4.500 1.5708 2.000 2.000 2 3 4 5 -1.0 7.0 5000.0 Comp Compressor Co 3.526 6.218 0.0000 1.000 1.000 15 6 11 -1.0 50.0 1.0

Formal input description:

Input section header: '* Plant components *' =(NameComp <> '$')= NameComp, - Name of the component. Text - Text describing the component. NameBasis - Name of corresponding basis component. X, - X-coordinate. Y, - Y-coordinate. Angle, - Rotation angle (radians). rSizeX, - X-size. rSizeY, - Y-size. :cMirror: - Option for mirroring: 'X': Mirroring around x axis. 'Y': Mirroring around y axis. "nConComp" ConComp - Connector number. "nQuaInit" rQuaInit - Initial value of variable or parameter. (Used in the first iteration.) (HasHeat1D) No, - Left side boundary number. cKind - Kind of left side boundary: Must be 'U':Unspecified "nX" T[iX] - Temperature of node number iX of heat conduction structure. =nLayer= No, - Layer boundary number. cKind - Kind of layer boundary: Must be 'U' = Unspecified No, - Right side boundary number. cKind - Kind of right side boundary: Must be 'U' = Unspecified (HasBoundary) No, - Boundary number. cKind - Kind of boundary: 'T': Temperature type boundary: Boundary temperature set to a specific, possibly time varying, temperature. 'C': Convective type boundary: Boundary temperature set through a heat transfer coefficient.

The components connect by reference to connector numbers with the same number.
The connector numbers are unique and refers to a connector object that can be
inspected like any other screen element. The position of the connectors
are specified in the Connectors part of the specification file. Example:

* Connectors * $ 2 4.500 2.121 3 0.900 2.121 3.300 1.560 4 0.885 2.721 0

We see the x and y coordinates of connector numbers 2, 3 and 4. Connector number 3 has an additional
corner to improve the plant appearence.

Formal input description:

Input section header: '* Connectors *' =(cOption <> '$') cOption - Connector options: 'W': Look for connector line width (HasWidth set). =(NoConnector <> 0)= NoConnector - Connector number <1,1000>. (HasWidth) Width - Width of lines adjacent to connector. "(eoln)" X, - X coordinate of connector or corner. Y, - Y coordinate of connector or corner. Comment: First X,Y-pair is the connector coordinates while the next are corners.

The circuits formed after connecting the components to a plant are fluid-"filled"
by attaching the proper fluid names to *one* connector per circuit.
Power circuits must also be specified.
In this case, "Power
" is used instead of a fluid name.

Example of circuit data showing circuits with R22, sea water, air and
finally a power circuit.

R22 4 SeaW 2 Air 9 Power 11

Formal input description:

Input section header: '* Circuits *' =(NameMed <> '$')= NameMed, - Name of the fluid in this circuit or 'Power' if it is a power circuit. ConCirc - Arbitrary connector number of the circuit.

A boundary condition is principally a description of an inlet
condition to the plant, e.g. the inlet water temperature as a
function of time (default).
It originates from some external condition influencing the plant,
but not itself being influenced. It is possible to split a plant into
a number of sections with an external boundary in between.
This way it is possible to control internal conditions explicitly.

In some cases, it is practical to refrain from defining some inlet condition and instead specify a corresponding outlet condition even though this is definitely influenced by the plant.
If a section of the plant is left out from the formulation, then the condition could be set according to the properties of the section not included.

A boundary conditions generates *one* plant equation, either contributing to the heat flow balance equation system or to one of the mass flow balance equation systems.

Below is an example showing two boundary condition data entries.

The first sets the entry temperature to the plant component "SWP
"of model type *Pump with preset mass flow rate*. The temperature
varies in time, starting at 12 °C, and ending at -5 °C after 12960000 seconds.
When specifying such a table, other time units can be used.
Internally and in the specification (sim
) file, however,
always *unprefixed SI units* are used.

The second example specifies a constant mass flow rate of 0.5 kg/s
through the component "Evap
" of type Standard evaporator
.

12 T Entry temperature T 6 0.000E+0000 2.592E+0006 5.184E+0006 7.776E+0006 1.037E+0007 1.296E+0007 1.200E+0001 1.000E+0001 6.000E+0000 2.000E+0000 -4.000E+0000 -5.000E+0000 9 M Evaporator mass flow rate K 0.5

Formal input description:

Input section header: '* Boundary conditions *' =(ConBound <> 0)= ConBound, - Connector number where boundary condition is imposed. KindVar, - Variable type controlled: 'T': Temperature. 'H': Enthalpy. 'W': Power/heat. 'P': Pressure. 'M': Mass flow rate. 'X': Fraction. Text - Text describing the condition. /Boundary variable value as a function of time/

Example of boundary condition data showing two conditions, one temperature
condition and one mass flow rate condition.

Control is a collective term for the part of the specification that
covers different types of internal plant conditions not appropriately
defined elsewhere. They can most often be considered as regulating
devices or groups of such. In this section there is a closer
description.

The specification of each control is initiated by the following
two-line input, not included later on the specific control types.

Formal input description:

Input section header: '* Controls *' =(NameCntrl <> '$')= NameCntrl, - Control name. Text - Text describing the control. Kind, - Kind of control: 'P': Parameter control. Specifies a parameter to be a function of time. 'R': Regulator control. A parameter is controlled to achieve a specified value of another component quantity. 'C': Component control. A component is turned off when some component quantity is exceeding a lower or upper level. (Must be combined with aggregate control to be effective.) 'A': Aggregate control. Coordination of a set of components. (Used with component control.) 'Q': Capacity control. Control of a set of components to give a specified capacity. (Only one such control!) 'D': Difference control. Definition of the difference between two variables. 'H': Enthalpy control. Definition of a certain superheat, subcooling or vapour fraction at a given connector. 'V': Valve control. The relative opening of exit port 1 of a three-way valve is controlled to obtain a certain temperature at a given secondary fluid connector or superheat, subcooling or vapour fraction at a refrigerant connector. 'B': Bypass control. Control of a bypass to avoid surging of turbo compressors. X, - X-coordinate of the control Y, - Y-coordinate of the control rSizeX, - Horizontal size of the control rSizeY, - Vertical size of the control cActive - Option for control being active or not: '-': Not active, i.e. not participating in the process. '+': Active, i.e. participating in the process.

As previously mentioned there are models with parameters called
controllable. Such a parameter is not influenced by other model quantities,
but *does* influence itself and often significantly.
A parameter control operates directly on a controllable parameter indicating
how it varies in time. Through modifiers the user may specify a variation
of this parameter being a function of any chosen quantity.

There is one quantity that may be specified through reference to a component
with the name ":
", representing a property of the entire plant: "CostInv
".
(See Derived quantities output).

Example of parameter control data:

mFan Fan mass flow rate P Fan m+ T 6 0.000E+0000 3.600E+0003 7.200E+0003 1.080E+0004 1.440E+0004 1.800E+0004 2.480E+0000 2.480E+0000 2.480E+0000 2.480E+0000 2.480E+0000 2.480E+0000

Formal input description:

(KindS = 'P') NameComp, - Component name. NamePar - Name of the component parameter to be controlled. This parameter must be controllable, ref. corresponding model annotation. /Parameter value as a function of time/

Regulator controls operate like parameter controls on controllable
parameters. A regulator control modifies the parameter to influence
a criterion stating that a certain plant quantity (called measured quantity)
has a preset value with a tolerance.
This value is by default a function of time,
however through modifiers there may be other dependencies.

The controllable parameter is first used with its initial value
(specified in plant components). Then a modified value is tried to
give FrigoSim information on the correlation between the parameter and
the measured value. The secant method is used in the search for a
parameter value satisfying the criterion. The user sets extreme
parameter values and maximum change per trial.

To make such a control work properly there must be a significant and
unambiguous dependence between the parameter and the measured quantity.
Otherwise, there may be no solution.

Example of regular control including the two-line general control entry:

RC Regulator control R Evap tTP 0.5 T 2 0. 86400. 4. 2.

Formal input description:

(KindS = 'R') NameCompU, - Name of component having measured quantity. NameQuaU - Name of measured quantity. :dUMax: - Maximum allowed deviation (dU) between measured and requested quantity. If not specified, the change in controlled parameter (dR) is used. If dR is very small a deviation of dU exceeding maximum is accepted. /Quantity as a function of time/ NameCompR, - Name of component having controlled parameter. NameParR, - Name of controlled parameter. RMin, - Minimum of parameter. RMax, - Maximum of parameter. dRMax - Maximum change of parameter per regulation.

The user defines the way the aggregates work together to produce a prescribed capacity.
This is specified through capacity control.
Only *one* control of this kind is possible.

Example of capacity control data:

Demand Heat Demand Q 5 8 T 2 1. 86400. 30000. 50000. Comp1 Comp2 Comp3 Boiler Pump1 Pump2 - - - - - - * - - - + - * < - - + - : 3 * - - + - * > - - + - - * * - + + * > > - + + ! > > > * + + $ 3

A capacity control is defined like the example above. First you set
the time variation of the enthalpy flow rate difference
between the connectors 5 and 8. Then the components to be controlled are specified.
These will be of type compressors, boilers and pumps.
Then you give a control strategy divided into capacity levels.

On each level you define how the different components are to operate.
The terms are '-' meaning turned off, '<' operating on minimum
capacity, '>' maximum capacity and '*' meaning the component are
step controlled so that capacity meets the demand. Pumps are set to
'+' meaning on, otherwise '-' (off). Capacity overlap between levels
is no problem. However, it reduces the efficiency of the simulation,
and should thus be avoided if possible.

A component taking part in the capacity control is divided into a
limited number of discrete steps. Hence the demand will not be met exactly.
The technique is to produce two solutions with a capacity on either side of the demand.
This may be interpreted as a plant changing in time between these two steps
with a time fraction on each of the two states in order to meet the demand.
These time fractions are applied to all variables,
parameters and function data for all components
to produce the final solution. (The time fraction value is given by predefined
derived quantities output "rTimeLow
".

If the demand exceeds the capacity at the lowest or highest step, the
plant continues on the extreme step with the capacity then deviating
from the demand. The time averaging will be turned off in this case.

The first search starts on the highest level, with all '*' components
at '>', unless another level is specified by a '!' at the end of the line.
The number 3 is the maximum step change between searches.
This way we may reduce stability problems, since each
search is based on the solution of the last one.

Formal input description:

(KindS = 'Q') Con1Q, - Connector number with the highest enthalpy flow rate. (Normally the sameas highest temperature or specific enthalpy.) Con2Q - Connector number with the lowest enthalpy flow rate. /Enthalpy flow rate difference as a function of time/ "(more in line)" NameAggr - Name of compressor, pump or boiler to be controlled with respect to capacity. (nAggr = Number of names in the line) =(Strategy <> '$')= "nAggr" Strategy, - Set condition of compressor, boiler or pump at a given level: '-': Component off. '<': Minimum capacity. '*': Regulated, which means that there will be a search for the component step giving the right capacity. ':': Component at a given step. '>': Maximum capacity. '+': Component without steps is on. (Strategy=':') Step - The given step. (One blank in head of number) :NameStart: - Indication of start level by an optional '!'. If not specified at any level, the highest level is used. dStepMax - Maximum change of steps between searches.

Comment on capacity control:

The levels are specified to give increasing capacity. However there may be
small decreases from the highest step of one level to the lowest step
of next level without this creating problems.
See also Strategy specification dialogue.

In a component control you define that a component is turned off if a
datum, variable or parameter exceeds an preset interval.
The component will only be "marked" as working under strained conditions.

In order for it really to be turned off, an aggregate control must be specified.
Using the following example of input to an aggregate control,
we will explain the way it works.

Example of combined component and aggregate control:

Comp1 tTP 30 50 Comp2 tTP -30 50 Comp3 tTP -30 50 Aggr1 Aggregate 1 A Comp1 Comp2 Comp3 Boiler

The components "Comp1
", "Comp2
" and "Comp3
" are "tied together" as an
aggregate. If one or more of these components asks to be turned off,
then all three are turned off. At the same time another component
"Boiler
" (auxiliary boiler) normally off, is turned on. "Boiler
" is
substituting the capacity of the turned off aggregate. "Boiler
" can not
be referred to in the capacity control. (See Capacity control.)
"Boiler
" is set to the same step as the turned off components.
A condition for this is that all aggregate components are equally regulated
and that they together with the "Boiler
" have the same number of capacity levels.
For "Boiler
" to be an appropriate substitute, it should have approximately
the same maximum capacity as the aggregate.

Formal input description:

(KindS = 'K') NameComp, - Component name. NameQua, - Name of the quantity (data, variable or parameter). StMin, - Minimal value. StMax - Maximum value. (KindS = 'A') "(more in line)" NameCompAggr - Name of component in the aggregate. NameCompSubst - Name of substitution component.

If a plant has a component that is impossible to represent properly
by one specific FrigoSim model, there is still one option. This is to
replace the component by one or several adapter components with an
equal number of difference controls. In this kind of control you
specify the difference between two variables of the same type as a
function of time or any other chosen quantity (by the use of modifiers).

Example of difference control where the suction line is represented by
a temperature adapter for refrigerant circuits plus this difference control
setting a constant pressure drop corresponding to 2 K in saturation temperature:

dtSuct Suction line D Evap tTP Comp tTPIn K 2.0Formal input description:

(KindS = 'D') NameK1, - Name of component having variable 1. NameV1, - Name of variable 1. NameK2, - Name of component having variable 2. NameV2, - Name of variable 2. /Variable difference as a function of time/

Superheat/subcooling/vapour fraction at outlet of plant components
is not always set by properties of the components the way these
have been modelled. Sometimes the states must be set by enthalpy control.
Normally there is *one* enthalpy control per pressure level.
This does *not* apply to intermediate pressure levels
with the use of flash chambers of different types. In an enthalpy
control the user specifies the connector where a prescribed
superheat, subcooling or vapour fraction is required.
These are by default functions of the saturation temperature.

Example of enthalpy control where the enthalpy is set to
a constant 5 K superheated gas at any pressure level.

SH Superheat evaporator H 2 O K 5.0

Formal input description:

(KindS = 'H') ConH - Connector number where enthalpy is measured. Kind - Selection of superheat, subcooling or vapour fraction: 'O': Superheat. 'U': Subcooling. 'X': Vapour fraction. /Superheat, subcooling or vapour fraction as a function of saturation temperature/

With parallel courses the mass flow rate distribution must somehow be defined.
The most efficient way is to use a three way valve with a fixed setting.
This is however often to static compared to real life.
A valve control improves this by using a technique similar to regulator control.
Applied to a refrigerant circuit the enthalpy out of one of the parallels
is measured and the mass flow distribution is regulated until the enthalpy
corresponds to a given superheat, subcooling or vapour fraction.
Often an enthalpy control is applied to the other parallel or to the flow after the header.
The latter position is preferable if the flow imbalances are significant.
Conditions for the valve control and the enthalpy control should normally be the same,
corresponding closely to real conditions.

Valve controls may also be applied to secondary fluid courses.
Then the mass flow distribution is controlled in order to have a
specific outlet temperature from one of the parallels.

Example of valve control where the enthalpy in connector number 12 is set to a constant
1 K subcooling at any pressure level, by controlling the three-way valve "3WValve
",
using 0.2 as the initial outlet 1 mass flow rate fraction:

VC Valve control V 12 3WValve 0.2 U K 1.0

Formal input description:

(KindS = 'V') ConExit, - Connector number where temperature or enthalpy is measured. NameVent3, - Name of controlling three-way valve. dRMax - Maximum change of mass flow rate through ConExit per adjustment. Kind - Selection of temperature, superheat, subcooling or vapour fraction: 'T': Temperature. (Requires use of model 'vlv3wSec' for three-way valve) 'O': Superheat. (Requires use of model 'vlv3wRfr' for three-way valve) 'U': Subcooling. (Requires use of model 'vlv3wRfr' for three-way valve) 'X': Vapour fraction. (Requires use of model 'vlv3wRfr' for three-way valve) (Kind = 'T') /Temperature as a function of time/ (Kind = 'O, 'U' or 'X') /Superheat, subcooling or vapour fraction as a function of saturation temperature/ Note! The three-way valve's exit connector 1 must lead to ConExit.

If a turbo compressor is used at high pressure ratios when capacity-controlled by prerotation,
surging often occurs. This may be avoided by bypass control,
ensuring high mass flow rate through the compressor,
even though this is not required by the plant.
Note that bypass controls are very demanding.
Convergence depends very much on correct and accurate use.

Example of a bypass control. "Comp
" is a turbo compressor and 3wvalve is a three-way valve
connected so that the bypass flow start from outlet 2:

BC Bypass control B Comp 3wvalve

Formal input description:

(KindS = 'B') NamecmpTurbo, - Name of turbo compressor controlling bypass. Namevlv3w - Name of three-way valve to be controlled.

By simulation conditions the user may influence simulation aspects,
setting start and stop time, time step (time step variation), maximum
number of time steps and maximum number of iterations per time step,
quantity type (temperature, enthalpy, density or mass flow rate) to
be used for the convergence criterion, termination criterions,
additional test output, relaxation of solution, time unit and
version check. Some or all of these parameters may be left
unchanged. Then FrigoSim uses default values as indicated in the formal
input description.

Example of simulation conditions data with time range from 0 to 24 hours,
3 hours time step, a maximum of 50 iterations allowed for each time step,
0.1 K convergence criterion:

S 8.640000E+0004 D 1.080E+0004 I 50 K 1.000E-0001

Formal input description:

Input section header: '* Simulation conditions *' =(KindSim <> '$')= KindSim, - Simulation condition option: 's': Start time 'S': Stop time. 'D': Initial time step. 'm': Minimum time step. 'M': Maximum time step. 'N': Maximum number of time steps. 'P': Sets specific simulation time points. (Overrules the settings by 's', 'S', 'D' etc.) '!': Choice of variable type for several conditions. 'K': Convergence criterion. 'i': Minimum number of iterations per time step (or search). 'I': Maximum number of iterations per time step (or search). 'v': Minimum variable value. 'V': Maximum variable value. 'w': Lowest maximum variable change per time step. 'W': Highest maximum variable change per time step. 'A': Stops simulation at given condition. 'T': Test output. 'G': Relaxation. 'X': Suppresses output of warnings. 'E': Time unit. '-': Version check. (KindSim = 's') TimeStart - Initial simulation time. (Default: 0) (KindSim = 'S') TimeStop - Terminal simulation time. (Default: TimeStart if ndTimeStop not specified otherwise TimeStart+ndTimeStop*dTimeStart) (KindSim = 'D') dTimeStart - Initial time step. (Default: TimeStop-TimeStart) (KindSim = 'm') dTimeMin - Minimum time step. (Default: 0) (KindSim = 'M') dTimeMax - Maximum time step. (Default: 1E20) (KindSim = 'N') ndTimeStop - Maximum number of time steps. (Default: 10000) (KindSim = 'P') nTimePnt - Number of simulation time points. "nTimePnt" TimePnt - Time point to be simulated at. (Must be increasing) (KindSim = '!') KindVar - Name of variable type used in controlling time step and checking convergence of solution at every time step: 'T': Temperature (Default). 'H': Specific enthalpy. 'P': Pressure. 'G': Mass flow rate. (KindSim = 'K') dVarKonv - Maximum variable change at convergence of time step or a capacity search. (Default: 0.01) (KindSim = 'i') nIterMin - Minimum number of iterations in one time step (or search). (Default: 2) (KindSim = 'I') nIterMax - Maximum number of iterations allowed in one time step (or search). (Default: 20) (Exceeding aborts simulation.) (KindSim = 'v') rVarMin - Minimum value of specified variable type. (Default: -50) (Exceeding aborts simulation.) (KindSim = 'V') rVarMax - Maximum value of specified variable type. (Default: 150) (Exceeding aborts simulation.) (KindSim = 'w') dVarMin - Minimum value of largest absolute change between two time step among all variables of selected variable type. Exceeding gives doubling of time step. (Default: 0) (KindSim = 'W') dVarMax - Maximum value of largest variable change. Exceeding gives halving of time step. (Default: 1E20) (KindSim = 'A') NameComp, - Component name. NameQua, - Name of quantity (data, variable or parameter). Oper, - Condition operator: '<': Stops if quantity is less than Verdi. '>': Stops if quantity is greater than Verdi. Verdi - Value not to be exceeded by quantity. Comment: There may be several of these conditions. (KindSim = 'T') cTest - Test output characters and integers for specification of more extensive output for test purposes. (See section "Test output" in the "FrigoSim Introduction".) (Default: No test output) (KindSim = 'G') (more on line) rRelax, - Weight of new solution. Previous solution is correspondingly given the weight 1 - rRelax. (Default: 0.55) nIterRelax - Iteration step where relaxation begins. (Default: 10) Comment: If you put just 'G' on the line, you get the default values. It is not recommended to have relaxation in the very first iterations, because of non-linearity. (KindSim = 'E') ScaleTime - Time unit in seconds. (Default: 1)

A selection of component quantities may be chosen for output. Some of these could be marked
for further processing in Derived quantities output.

Example of normal output data specifying output of evaporation temperature,
evaporator mass flow rate, evaporator capacity, condenser u value,
and condenser secondary fluid entry and exit temperatures.

Evap tTP Evap mRfr Evap q qEvap Cond u Cond tSecIn Cond tSecOut

Formal input description:

Input section header: '* Component quantities output *' =(NameComp <> '$')= NameComp, - Component name. NameQua, - Name of the quantity (data, variable or parameter) to be written out. :NameDeriv: - Name of this quantity if to be used in derived quantities output. This may and should be left out if the quantity is not be used later on. (Note that these marked quantities are counted in the number of derived quantities.)

Often a user is interested in quantities that can be derived from the plant process quantities,
especially in relation to economy. To free the user from calculating these by hand or
by a separate post-processor, FrigoSim offers derived quantities output.
The user may specify summation, subtraction, multiplication, division, minimum and maximum values,
time integration, derivation and averages. In addition new quantities like prices may be introduced.

There is a number of predefined derived quantities: Absolute time
, Simulated time
,
Conversion from
°C to K (273.15),
Time fraction for a capacity controlled aggregate at upper step
,
Weight
and
Total plant cost" along with "Component dependent plant cost
(see Basis components).

Example of derived quantities with calculation of the total heat "qTot
" produced by two condensers,
and the total power input with contributions from compressor 1, compressor 2, a fan and a pump (wTot).
Then a COP is calculated as the ratio of total capacity by total power input "COP
".
Finally a calculation of the total energy input over the total simulation period "eTot
".

qTot kW 1000 . Total capacity + qCond1 qCond2 wTot kW 1000 . Total power input + wComp1 wComp2 wFan wPump COP - 1 . Coefficient of performance / qTot wTot eTot kWh 3.6E6 E Total energy input I wTot

Formal input description:

```
Input section header: '* Derived quantities output *'
=(NameDeriv <> '$')=
NameDeriv, - Name of derived quantity.
(If you only want to perform an auxiliary calculation,
not to be output, no more is needed on this line.)
(more on line)
NameUnit, - Quantity unit.
Scale, - Quantity scaling factor. This is the unit as measured
in the corresponding un-prefixed SI-unit.
The scaling is only used for the output: If the quantity
is referred to by other derived quantities, it is used unscaled.
Note! If using a recognizable quantity unit, this scaling
factor will be disregarded. In stead the scaling will be
according to the current quantity unit selection
from
```

.
(Kind <> ' ')
Kind, - Option:
'.': Output with decimal point and two decimals.
'E': Output with power of ten. Scientific notation.
'$': Output as 'E', but only in the final output.
'X': No output (For intermediate quantities.)
(Quantities with '$' or intermediate quantities are not written
to the rsl-file.)
'P': The quantity represents the plant capacity.
Text - Text describing the quantity.
Opor, - Operator:
'+': Adding subsequent quantities. (Max. 5)
'-': Subtracting the two subsequent quantities.
'*': Multiplying subsequent quantities. (Max. 5)
'/': Dividing the two subsequent quantities.
'<': Minimum from simulation start of subsequent quantity.
'>': Maximum from simulation start of subsequent quantity.
'I': Time integral from simulation start of subsequent quantity.
Time unit is seconds regardless of the unit chosen in
"Simulation conditions".
Note that time integrals may produce significant errors on output
of interpolated values, especially in the beginning.
'D': Time derivative of subsequent quantity. Time unit is seconds
regardless of time unit specification.
'M': Time average from simulation start of subsequent quantity.
'S': Quantity evaluated from a function.
The number of operands (nOpand) may range from 0 to 2.
The operands defaults to 'Time' (see predefined operands below).
'R': Total time during simulation in which subsequent quantity
is within a value range. The range is closed, i.e. contains
the lower and upper values.
"nOpand"
Opand - Operand name.
(Opor = 'S')
/Quantity as a function of time/
(Opor = 'R')
ValueLo, - Lower value of range.
ValueHi - Upper value of range.
Comment on derived quantities output:
Only backward references to quantities are possible. nOpand of '+' and '*' is given
dynamically from the number of operands specified on the same line.
Otherwise, the number is given above. The notation is called Polish notation.

There is a number of predefined operands available:

Time Absolute time. TimeSim Simulated time. t0->K 273.15 (to convert from Degrees Celsius to Kelvin). rTimeLow Time fraction with capacity controlled aggregate operating on higher step. CostInv Non-component (invariable) plant cost. Cost Total plant cost. (CostInv + [Price of all components]) Weight Total plant weight. ([Weight of all components])

The "CostInv
" quantity is set by Parameter control.

By output conditions the user specifies the frequency of result output,
both to the report file and the result file. The result file is used for producing
plots by spreadsheet programs.

Example of output conditions data with results for each 24 hours, regardless of
time step. Results also to a separate result file appropriate for spreadsheet programs:

D 86400 R

Formal input description:

Input section header: '* Output conditions *' =(KindRes <> '$')= KindRes, - Output time option: 'P': Output at given points of time. 'D': Output with a given time interval. 'N': Output with interval being a given number of time steps. (Default with ndTimeRes = 1.) 'F': Full output every certain number of outputs. 'R': Output to rsl-file. (KindRes = 'P') nRes - Number of outputs. "nRes" TimeRes - Output time. (KindRes = 'D') dTimeRes - Time interval between outputs. (KindRes = 'N') ndTimeRes - Number of time steps between outputs. (KindRes = 'F') nResFull - Number of outputs between full outputs. The intermediate outputs are compressed (i.e without explanatory text). (Default: 1000) (KindRes = 'R') KindResTime - Rsl-file output time option: 'D': Output after each time step. (Default) 'U': Output when ordinary output. '$': Output after ended simulation.

Comment on output conditions:

You only need to specify one of 'P', 'D' or 'N'. If several are given,
the last one is used. Output of results to an rsl
-file, i.e. to the file
'SIM-file-name'.rsl
, refers to both component quantities and derived quantities.
Derived quantities are written unscaled.

Illustrations are elements that are put in the background of other elements,
adding to the visual impression of the plant layout.
In addition, explanatory text labels may be added to the plant through such objects.

Example of an illustration with name "Central
" representing a house
where a plant may be placed. The colour is Blue.

Central - Central heat pump building iHouse -16.168 4.851 0.000000 11.878000 9.843000 clrBlue

Formal input description:

Input section header: '* Illustrations *' =(NameIllust <> '$')= NameIllust, - Name of illustration. "cOption", - Option for mirroring of illustration: 'X': Mirroring round x axis. 'Y': Mirroring round y axis. 'I': Display symbol. '+': Display text. '-': Suppress text. 'P': Use polygon. (The symbol is not displayed is this case) 'C': Store polygon coefficient relative to the polygon centre. (This is to facilitate SIM-file direct editing.) Text - Illustration text. NameSymbol, - Name of symbol used for illustration. X, - X-coordinate of illustration. Y, - X-coordinate of illustration. Angle, - Rotation angle of the illustration (symbol or polygon) rSizeX, - Horizontal illustration size. rSizeY, - Vertical illustration size. NameColour - Internal name referring to illustration colour. (cOption = 'P') X, - Reference X coordinate. Y - Reference Y coordinate. nPnt - Number of polygon points. =nPnt= XPnt, - Polygon point X-coordinate. YPnt - Polygon point Y-coordinate.Comment: The actual polygon point positions are the sums of X and XPnt, and Y and YPnt. The X and Y values are 0 if the cOption has not been given the 'C' setting. Otherwise, the X and Y values are the averages of XPnt and YPnt respectively. The NameSymbol is read but disregarded if the polygon mechanism is used.

The specification described so far sets the conditions for *one* simulation.
The plant has fixed properties and prescribed external and internal conditions.
In the search for an optimally designed plant the user wishes to try out different
variants of plant properties and imposed conditions, often knowing in advance what to try.
In such cases variant conditions could be used. The user varies constant data of
basis components, use different basis components for the same plant component,
replace fluids, set different initial values and/or replace function data.
Then a number of simulations equal to the number of variants will be performed
in *one* run. The plant architecture, however, can not be varied by variants.
This has to be done in several runs.

Example of variant conditions data that produces 3 different simulations in one run,
the first with condenser area 3 and using basis component "evap1
" for plant component "Evap
",
the next with area 5 and basis component "evap2
", and the last one with condenser area 7
and basis component "evap3
" for component "Evap
":

N 3 D Cond a 3 5 7 B Evap evap1 evap2 evap3

Formal input description:

Input section header: '* Variant conditions *' =(KindVnt <> '$')= KindVnt, - Variant condition option: 'N': Setting number of variants. 'D': Varying constant data of a basis component. 'B': Varying basis components used for a plant component. 'M': Varying fluids of a circuit. 'I': Varying initial values of a plant component. 'S': Varying functions. (KindVnt = 'N') nVnt - Number of simulation variants. (Default: 1) (KindVnt = 'D') NameBasis, - Name of basis component. NameKData, - Name of constant data to be varied. "nVnt" DataR - Constant data. (KindVnt = 'B') NameComp, - Name of plant component to have varying basis components. "nVnt" NameBasis - Name of basis component. (KindVnt = 'M') ConVnt, - Connector number of circuit to have varying fluids. "nVnt" NameMed - Fluid name. (KindVnt = 'I') NameComp, - Name of plant component. NameInit, - Name of quantity with initial value to be varied. "nVnt" rInit - Initial value. (KindVnt = 'S') NameFunc - Name of function to be varied. =nVnt= /New function/

Comment to variant conditions:

Variant conditions are not available through the windows user interface,
but may be used by editing directly in the sim file.
There is no initial simulation with the original data.
The variants are applied from the start,
so that the number of simulations equals the number of variants.
Varying a function means that the new functions are used
in stead of the one to be varied, wherever this is referred in the data set.
Variant conditions may be left out if there is no need for it.

A special notation is used for describing the input file structure,
specified below:

Notation Corresp. Pascal Explanation A, readln(A,B,C); If an identifier is followed by a comma, B, then the next variable should normally be C specified on the same line. "N" for I:=1 to N do Repeat the indented N times on the same line. A, read(A[I],B[I]); B readln; =N= for I:=1 to N do Repeat the indented N times each time starting A, readln(A[I],B[I]); on a new line. B (I=1) if I = 1 then Conditional input of the indented. A, readln(A,B); Symbols in condition: B = (equals), <> (not equals), < (less than), >= (greater than or equals) etc. =(I <>1)= while I <> 1 do Read the indented as long as the condition I, readln(I,A[I],B[I]); in parentheses is true. A, B :A: if not eoln then Read the variable if it is specified. readln(A); This variable, if given, will always be the last variable of a line. N - N is ... The identifier to the left of - is given an explanation to the right. 0: ... Description of effect of giving a variable 1: ... specific values.

Specification data are often entered as one of several types of functions.
A description follows:

KindFunc, - Function type: 'K': Constant. 'T': One-dimensional table. If the quantity is a function of several variables the 1st variable is used. 't': One-dimensional table in which the 2nd variable is used. 'Y': Two-dimensional table. 'E': Equidistant table points. If the quantity is a function of several variables the 1st variable is used. 'e': Equidistant table points in which the 2nd variable is used. 'S': Template function. If the quantity is a function of two variables, the 1st is used. 's': Template function where the 2nd variable is used. 'C': Correlation selected by user employed in the function evaluation. 'F': An external function from file ExtFunc.dll is called in the function evaluation. This enables the user to connect to own code. 'I': Identical data with previously defined function. 'V': Variable modifier. Redefines 1st variable used. 'v': Like 'V' with 2nd variable. 'P': Period modifier. Makes functions being dependent on 1st variable periodic. 'p': Like 'P' with 2nd variable. (KindFunc = 'K') Scalar, - The given constant. :NameFunc: - Function name. (KindFunc = 'T' or 't') nTbl, - Number of table values. (Max: 1000) :NameFunc: - Function name. "nTbl" XTbl - Abscissa value. "nTbl" YTbl - Corresponding quantity value. (KindFunc = 'Y') nXTbl, - Number of table values for 1st variable. (Max: 40) nYTbl, - Number of table values for 2nd variable. (Max: 40) :NameFunc: - Function name. "nXTbl" XTbl - Abscissa value for 1st variable. =nYTbl= YTbl, - Abscissa value for 2nd variable. "nYTbl" ZTbl - Corresponding quantity value. (KindFunc = 'E' or 'e') nEqui - Number of equidistant table points. (Max: 10000) :NameFunc: - Function name. X0Equi, - First abscissa value. dXEqui - The constant distance between abscissa values. "nEqui" YTbl - Quantity value. (KindFunc = 'S' or 's') NameFunc, - Template name: 'Period': f(x) = p1 + p2 * cos(2*pi*(x - p3)/p4) 'Potent': f(x) = p1 + p2 * (x/p3)**p4 'Exp': f(x) = p1 + p2 * exp(x/p3) 'LogNat': f(x) = p1 + p2 * ln((x-p3)/p4) 'Polynom': f(x) = p1 + x*(p2 + x*(p3 + x*(p4 + x*(p5 + x*p6)))) (5th order polynomial) :NameFunc: - Function name. "nPar" Par - Parameter (pn) of the function. The value of nPar is evident from the functions above. (KindFunc = 'C') :NameFunc: - Function name. =nCirc= nCourse, - Number of courses for this circuit. lDiam - Hydraulic diameter of each course for this circuit. (See correlations for details)Comment:

nCirc is the number of local fluid circuits of the component. It is set by FrigoSim.

(KindFunc = 'F') FNo, - Function number. Reference to Fn in the user module with n = FNo (1-10). (Ref. dynamic link library connection) XMin, - Minimum x value. XMax, - Maximum x value. YMin, - Minimum y value. YMax, - Maximum y value. ZMin, - Minimum function value. ZMax, - Maximum function value. :NameFunc: - Function name. (KindFunc = 'I') NameFunc - Name for a previously defined function to be used in stead of a new function. (KindFunc = 'V' or 'v') NameCompMdf, - Component name owning the quantity. NameQuaMdf, - Quantity name. rInitMdf - Initial value of quantity.

Comment:

When setting NameCompMdf to '*' the quantity of the current component will be used.
(Only to be used in "Basis component data".) When setting NameCompMdf to '=' the variable
used is the special output with name NameQuaMdf. Note that all user defined special output
quantities are updated only after each time step.

(KindFunc = 'P' or 'p') VPerMdf - Period of variable.

A function is referenced in the input description by

/A function of B (and C)/

where A corresponds to YTbl or ZTbl and B to XTbl and C to YTbl.

Note! If a table is exceeded, FrigoSim will issue an "info" being a warning.
At return the nearest table value is used.

In the description there is a reference to "Function name".
This is a name that may be connected to a function
so it may be referenced elsewhere (through KindFunc = 'I').
This name should be omitted unless it is used.

Through the function dialogue a two-column file (of type xy.
)
can be loaded into a function and then subsequently stored
in the FrigoSim function format.

It is possible to connect FrigoSim to external (user's own) code by making a dynamic link library.
The user must specify a file ExtFunc.dll
, replacing the one in the FrigoSim package.
It must contain the following functions using StdCall calling conventions:
(See included Delphi code in file ExtFunc.dpr
.)

ExtFunc1(X,Y) ExtFunc2(X,Y) ... ExtFunc10(X,Y)

All functions must be specified, but those not needed can be dummies
and should then return the value -1.0E20 to signal to FrigoSim that the functions are not specified,
in case you inadvertently refer to them.
They must be exported as function numbers 1 to 10, as the functions are
imported by ordinal
from FrigoSim.
The input variables X and Y, as well as the function results,
must be Double type float numbers.
The specified functions are connected to FrigoSim through the Function dialogue,
using function type External function
.

It is also possible to specify one's own correlation of some heat transfer coefficient, which otherwise is selectable from a list. There is a specific function "ExtCorr " for this in ExtFunc.dll. Available input parameters are:

ExtCorr(T,dT,vel,D,L,CP,Dens,DV,DVWall,KV,TC,Beta,Pr) T - Bulk temperature dT - Surface temperature - Bulk temperature vel - Fluid velocity D - Hydraulic diameter L - Flow length CP - Fluid specific heat capacity at bulk temperature Dens - Fluid density at bulk temperature DV - Fluid dynamic viscosity at bulk temperature DVWall - Fluid dynamic viscosity at wall condition KV - Fluid kinematic viscosity at bulk temperature TC - Fluid thermal conductivity at bulk temperature Beta - Fluid thermal volumetric expansion coefficient at bulk temperature Pr - Fluid Prandtl number at bulk temperatureThe ExtCorr must be exported function number 11, as FrigoSim imports it by ordinal.