Encyclopaedia Index
Back to main contents

4. Material properties in general

Contents of section 4

  1. The PROPERTY keyword
  2. Individual properties
  3. Further examples
  4. Choosing a fluid

4.1 The PROPERTY keyword

The keyword property is used in In-Form statements for specifying distributions of any of the twenty quantities listed below. These include both genuine properties, such as density, specific heat and thermal-expansion coefficient, and others, such as turbulence length scale, which PHOENICS handles in a similar way, as explained in the Encyclopaedia article.

Whenever In-Form statements holding the PROPERTY keyword are present in the Q1 file, and are accepted as legitimate by EARTH, the specified quantity is computed and used at every appropriate point in the calculation.

This is true even when the same properties are nominally being computed in accordance with PIL settings: what In-Form specifies takes precedence.

A typical In-Form statement is:
(property EL1 at PATCH_1 is YG - YG^2.0 if(YG.LT.1.0))
which should make the first-phase turbulence length scale a quadratic function of the y-distance from the wall over half the grid.

Then the following simple Q1 file:

TALK=T;RUN(1,1)
STORE(EL1)
PATCH(PATCH1,INIVAL,1,1,1,5,1,1,1,1)
GRDPWR(Y,10,2,1)
(property EL1 at PATCH1 is YG - YG^2.0 with if(YG.LT.1.0))
NYPRIN=1
would cause EARTH to place in the RESULT file the following:

 Flow field at ITHYD=   1, IZ=   1, ISWEEP=     1, ISTEP=    1
   IY     EL1
    10   0.0
     9   0.0
     8   0.0
     7   0.0
     6   0.0
     5   9.000E-02
     4   2.100E-01
     3   2.500E-01
     2   2.100E-01
     1   9.000E-02
from which it may be seen that, for YG in excess of 1.0, i.e. IY in excess of 5, EL1 has its default value of 0.0 because the In-Form statement made no prescription.

The last sentence made reference to both IY and YG because, tiresomely in this case, PHOENICS prints the grid coordinates in a different place. However (in anticipation of the not-yet-presented discussion of the keyword STORED) this may be easily remedied.

Thus, addition of the line:


(stored YGG is YG)
LSWEEP=2
causes the RESULT file to contain:

   IY     YGG         EL1
    10   1.900E+00   0.0
     9   1.700E+00   0.0
     8   1.500E+00   0.0
     7   1.300E+00   0.0
     6   1.100E+00   0.0
     5   9.000E-01   9.000E-02
     4   7.000E-01   2.100E-01
     3   5.000E-01   2.500E-01
     2   3.000E-01   2.100E-01
     1   1.000E-01   9.000E-02
It is worth explaining why YGG was stored, and not YG; and also why LSWEEP was increased to 2.

The reason for the first is that, although (stored YG ...) would have been accepted, PHOENICS would then become confused between the newly-stored YG and the already-present one.

The reason for the second is that, unless the (stored YGG ...) has a special post-formula option ('with SWPSTR', to be explained in section 5), YGG will not have been computed in time for first-sweep print-out.

4.2 Individual properties

Click below to proceed directly to discussion of the property selected RHO1 DRH1DP RHO2 DRH2DP ENUT ENUL PRNDTL PHINT TMP1 TMP2 EL1 EL2 CP1 CP2 DVO1DT DVO2DT CFIPS CMDOT CINT CVM

The material properties used by PHOENICS are listed above and in the file \phoenics\d_earth\d_core\gxprutil.for as may be seen by clicking here.

Each of these may be set by way of In-Form, as will now be explained and exemplified, in order of IPROP value.

First however two properties which are new to PHOENICS will be mentioned, namely ENT1 and ENT2, which will be used for representing the enthalpies of the two phases when they are not being solved for directly.

This renders more symmetrical than hitherto the alternative treatments of temperature and enthalpy.
Thus ENT1 is to H1 as TMP1 is to TEM1; and

ENT2 is to H2 as TMP2 is to TEM2.

For historical reasons, the symmetry is not perfect; for H1 and H2 are "hard-wired" to variables 14 and 15, whereas TEM1 and TEM2 take the indices which the satellite ascribes to them when it encounters them in the Q1 file. However, there would be no advantage in enforcing symmetry further.

ENT1 and ENT2 are therefore added to the list to be discussed below.

In the following discussion, examples are provided for some, but not all material properties. The principles of setting are the same for all properties; so exemplification of each one would become tedious.

4.3 Further examples of use of (PROPERTY ...

Core-library case 105.htm is one of the oldest in the library, having been originally provided to enable the main ingredients of CFD (time-dependence, convective flow, diffusion and sources) to be studied in a one-dimensional situation.

It has now been supplied with the In-Form equivalents of the earlier data settings, which have however been left in place in order that the advantages of the new style can be perceived.

Case 763 concerns the square-cavity flow of case 762, but calculates the four relevant properties of the fluid (ethylene glycol) in four different ways, namely by way of:

Since the temperature range is not very large, the agreement is close, as may be seen from this extract from the result file

Use for SCRS, the simple chemical reaction

Core-library case 492 provides a good example of how the use of In-Form simplifies the setting of properties required in combustion simulations; for it contains both the pre-In-Form and post-In-Form settings.

In the former, RHO1, TMP1 and CP1 are all set to GRNDx values; then further information is conveyed by the setting of such variables as RHO1A, TEMP2B and CPC; this is easy to do, but only when one has checked the documentation for the meaning of each variable.

No such checking is needed when the In-Form route is taken; for the statements starting '(property TMP1 is' and '(property RHO1 is' are rather easy to interpret; and indeed to write also, once the rule regarding colons has been mastered.

It is only the sections numbered 1. and 2. which concern the property settings; however the opportunity has been taken, under the heading of 'The In-Form Alternative' to illustrate uses also of:

Two-phase-flow cases

4.4 Choosing a fluid

Although users are enabled, as just explained, to use In-Form formulae for the setting of individual fluid properties, this is by no means always convenient.

Often the user prefers to specify the fluid by name and to rely on PHOENICS to use the properties which that fluid possesses.

The fluid_name feature of In-Form allows this.

Library case 761 exemplifies its use, showing that it is necessary to:

  1. set the character variable fluid_name equal to one of the following:

  2. then load library case 089 which contains formulae for the relevant properties of all the above fluids, and

  3. rely on that loading to include in the Q1-file the property formulae which are appropriate.

It will be seen that the property formulae which have been provided are both numerous and complex; but the user does not need to be concerned with the complexity; for In-Form and EARTH do all that is necessary.

Of course, if the user wishes to specify fluids which are not included in case 089, he or she will have to specify what the corresponding formulae should be, using the provided examples as templates.

When, as is true of the formulae in case 089, the formulae imply that the properties depend upon temperature and pressure, the user must ensure that these quantities are appropriately calculated, by setting SOLVE(P1,TEM1) and providing appropriate initial and boundary conditions.