Encyclopaedia Index

OBJECTS OBJECT files and libraries OFF ON ONCIRCLES ONE-PHASE FLOWS ONEPHS ONLYMS

Open-source Fortran OPENING object OPPVAL OPTIONS ORELSE ORSIZ Orthogonal grids OUT-OF-CORE OPERATION FOR FINE GRIDS OUTFLO Outflow boundary conditions in two-phase flows OUTFLOW OUTLET OUTLET object OUTLINE OUTPUT OVER-PRESCRIPTION OVER-RELAXATION OVRRLX


Objects

What they are

As used in connexion with PHOENICS, the term "object" denotes an entity which has the attributes of (at least):

and further attributes may be ascribed to an object, such as:

PHOENICS objects are divided into two main categories, according to whether their shapes are defined by way of

  1. facets, or
  2. formulae.
  1. The former are called 'VR objects' because they were brought into existence when PHOENICS acquired its 'Virtual-Reality' user interface, the facets being originally used to facilitate graphical display.

    They may also be called 'faceted' objects, or 'grid-cutting' objects. The latter name is a reminder of the fact that PHOENICS, by default, detects, and treats in a special manner, all those grid cells which are intersected by object-defining facets. A full list of these objects can be found here.

  2. Those of category b are called 'In-Form' objects, because they came into existence soon after the introduction of the In-Form facility for introducing data into a flow simulation by way of formulae.

    They may also, on occasion, be called 'sub-grid' objects, because their influence does not depend on the cutting of grid-cell edges by their outer surfaces.

Objects of both categories may be either at rest or in motion relative reference frame of the simulation in question. If the latter, the motion of either category may be described either by way of:

The remainder of this article is devoted to category a, the VR objects. For information about category-b objects, In-Form click here.

For convenience, sub-classes of objects are distinguished as being of different "types", some of which have one set of attributes and some another.

The position of an object is defined by way of the x-y-z coordinates of its "bounding box", ie of the parallelepiped which wholly encloses it.

How a particular object is defined

A particular instance of the class object is defined by lines in the Q1 file, for example (from library case v100):

    
> OBJ1,   NAME,        B1
> OBJ1,   POSITION,    0.000000E+00, 0.000000E+00, 0.000000E+00
> OBJ1,   SIZE,        0.000000E+00, 2.000000E+00, 1.000000E+00
> OBJ1,   CLIPART,     cube3t
> OBJ1,   ROTATION24,        1
> OBJ1,   TYPE,        INLET
> OBJ1,   PRESSURE,      0.000000E+00
> OBJ1,   VELOCITY,      1.800000E+01, 0.000000E+00, 0.000000E+00
> OBJ1,   TEMPERATURE,   0.000000E+00
    
> OBJ2,   NAME,        B2
> OBJ2,   POSITION,    5.000000E+00, 0.000000E+00, 0.000000E+00
> OBJ2,   SIZE,        0.000000E+00, 2.000000E+00, 1.000000E+00
> OBJ2,   CLIPART,     cube11
> OBJ2,   ROTATION24,        1
> OBJ2,   TYPE,        PLATE
> OBJ2,   POROSITY,      1.500000E-01
> OBJ2,   RESISTANCE,    4.000000E-01
> OBJ2,   SIDE,        BOTH
Such lines are interpreted by the SATELLITE; and their significances are conveyed to EARTH by way of the EARDAT and FACETDAT files.

These lines may be regarded as extensions to the PHOENICS Input Language, PIL.

The relationship between "objects" and "patches"

The PATCH(name, type, ixf,ixl,iyf,iyl,izf,izl,itf,itl) command of PIL, followed by the corresponding COVAL commands, performs a similar function to the lines which define an object; and indeed, by the time the latter information has been transmitted to EARTH, it is indeed interpreted in terms of PATCHes.

However there are differences which should be noted, namely:

How the object-defining lines may be written Lines such as the above may be written to the Q1 file by way of any word-processor. However, it is often more convenient to do so by way of the VR-Editor, in the reference guide to which a full account of object types and attributes, and of the means of selecting them, can be found.


OFF

(Geometry Edit Menu)---------------------------------------- Photon Help ----

PHOTON will prompt for the first and the last GEOMETRY elements to be turned off. Action will only be taken if you press [Confirm].


ON

(Geometry Edit Menu)----------------------------------------- Photon Help ----

PHOTON will prompt for the first and the last GEOMETRY elements to be turned on. Action will only be taken if you press [Confirm].


OnCircles

(Streamline Menu)---------------------------------- Photon Help ----

The starting positions of the streamlines will be uniformly distributed along a circle in the projection of the initial plane defined by [InitPln] in the STREAMLINES menu.

After pressing this button, PHOTON prompts you to supply the number of streamlines.


One-phase flows, specification of

(see ONEPHS)


ONEPHS

---- PIL logical; default=T; group 7 ----

ONEPHS....=T indicates that the flow is one-phase. ONEPHS=F indicates that it is two-phase, which implies the presence of two sets of velocity components, to be solved separately; but it is the user's task to activate the storage and solution of these velocities, and the storage and solution of the phase volume fractions R1 and R2. For example, a 2D 2-phase flow in the y-z plane would require the following commands for its activation: ONEPHS=F;SOLVE(P1,V1,V2,W1,W2,R1,R2)

By default, the two phases share the same pressures, but the pressure force acting on the velocities is partitioned between the two phases by volume fraction. The two phases may be thought of as two interspersed media or as being segregated one from the other ( a duct flow can exhibit both regimes at different locations ).

Interfacial conditions are set in group 9 by means of the PHINT array. Interphase transport can be de-activated in group 8 by means of the TERMS command. For the purposes of interphase transfer, first-phase variables are paired with second-phase ones as follows: U1,U2; V1,V2; W1,W2; R1,R2; H1,H2; C1,C2; C3,C4;.... .....; C33,C34.


ONLYMS

---- PIL real flag; value=0.0; group 13 - -

ONLYMS....is a coefficient name recognized in the third argument of COVAL, to be used to specify sources to represent inflow boundaries. Use of ONLYMS in COVAL for enthalpy (say) means that only convection flow effects are influential in the transport of enthalpy from the boundary to the cell centre. In other words, the diffusive effect is zero, which is why ONLYMS is equivalent to a coefficient value of 0.0.

See COVAL for further information.


OPPVAL

---- PIL real flag; value=-10250.0; group -

OPPVAL....is a value name recognized in the fourth argument of COVAL. It causes the VALue appearing in the source term to equal that of the variable itself on the opposite side of the face indicated by the PATCH type. Thus, if the type is NORTH, and the PATCH is located at NY-1, the magnitude will be that of the variable at cell NY.


OPTIONS

The OPTIONS were introduced into PHOENICS as "capabilities with which PHOENICS might be optionally NOT be supplied, in order to reduce its price".

This was the old idea. However, it has ceased to be important except as an explanation of the directory structure of PHOENICS.

Thus the Earth directory contains sub-directories named:
D_CORE and D_OPT

while the sub-directory d_opt is further sub-divided as:


ORELSE

------------- Advanced PIL command --- -

ORELSE is an optional element of the PIL CASE construct. See the HELP entry on CASE for further information.


ORSIZ

----- PIL real; default= 0.4; group 23 -- -

ORSIZ....sets the vertical extent of the ordinate in line-printer plots, whether of residuals and monitor values versus sweeps/iterations, or of PROFIL plots specified by users.

The default 0.4 allows for 20 lines of print.

See also ABSIZ, which concerns the abscissa size.


Orthogonal grids, checking of

(see ANGMIN and GRDCHK)


OUT-OF-CORE OPERATION FOR FINE GRIDS

The quality of a simulation effected by PHOENICS can be expected to improve when a large number of cells is employed in the grid. However, even when the correspondingly increased computer time can be afforded, it often occurs that the computer memory available is insufficient to allow the use of a fine grid directly.

PHOENICS incorporates a special device which alleviates this difficulty: it can work with a memory which suffices for the storage of information relating to only three of the numerous 'slabs' of cells; information about all other slabs than those on which Earth's attention is being concentrated can be stored on, and retrieved from, the hard disk.

This use of auxiliary storage takes place automatically, without the user's intervention; and it allows PHOENICS to work, even on a small-memory computer, with very fine grids. Messages transmitted to the VDU indicate that this action is taking place. It can be triggered for testing purposes, by setting NFMAX to a small number in the Q1 file.

Library case 101 and 102 illustrate the working of the device.

Of course, there is a penalty: because accessing disks is slower than computing, total times are longer.

For body-fitted-coordinate problems, which make use of a large amount of geometrical information, a similar device is automatically activated.

Note: this feature is no longer active, as all versions of PHOENICS since 3.6 have used dynamic memory allocation techniques to increase the size of the main storage array when needed. Click here for more information.


OUTFLO

---- PIL real flag; value= 15.0; group 13 -

OUTFLO....is a PATCH type used to specify PATCHes at which only outflow is desired. Thus when the in-cell pressure is greater than the external pressure, outflow is present, but when the in-cell pressure is less than the external pressure there is no inflow.


Outflow boundary conditions in two-phase flows

There is an important difference between the ways in which EARTH calculates mass outflow conditions for single-phase flows and for two-phase flows. For single-phase flows, the mass outflow is computed as,

Cp (Vp - pP)

where Cp and Vp are the coefficient and value that apear in the third and fourth arguments of the COVALs for P1. Of course, for outflow to occur at all, the in-cell pressure pP must be greater than the external value of the pressure, Vp.

For two-phase flows, the mass outflow for phase i (i=1 or i=2) is computed as,

Ri Cp,i (Vp,i - pP)

where Ri is the local value of the volume fraction of the phase. This practice of multiplication by Ri ensures that, if the values of Cp,i and Vp,i are the same for both phases, the outflows of each phase from a cell are in proportion to volume fractions of the phases in the cell.

The recommended practice, however, is to partition the outflows in proportion to the mass concentrations of the phases in the cell, ie

riRi Cp,i (Vp,i - pP)

where ri is the local value of the phase density. In incompressible flows, this condition is realised by multiplying the third COVAL argument by RHO1 for the first- phase outflow and by RHO2 for the second-phase outflow, eg

COVAL (name,P1,RHO1*FIXP,0.0)
COVAL (name,P2,RHO2*FIXP,0.0)

This practice is of course permissible only when RHO1 and RHO2 do stand for the first- and second-phase densities. If one of them is set equal to GRNDn, a different way must be adopted for introducing the density into COVAL.


Outflow, specifying PATCHes for

(see OUTLET and OUTFLO)


OUTLET, a PHOENICS-VR object type

An OUTLET object is used to declare a fixed-pressure boundary, where mass is allowed to leave (or enter) the solution domain. See the description in the PHOENICS_VR Reference Guide, TR326

In Flair, OUTLETs are referred to as OPENINGs.


OUTLET

---- Command; group 13 --------------

This command is used to declare a fixed-pressure boundary, where mass is allowed to leave (or enter) the solution domain.

Non-zero values of velocity and scalar quantities external to the domain can be specified by the VALUE command. See the entry on VALUE for more information.

The syntax is : OUTLET(NAME,TYPE,IXF,IXL,IYF,IYL,IZF,IZL,ITF,ITL)

NAME is a unique identifier for the OUTLET, up to 8 characters in length. TYPE can be NORTH,SOUTH,EAST,WEST,HIGH or LOW, and specifies which cell face areas will be used to multiply the specified mass-flows.

IXF ... ITL specify the limits in space and time over which the mass source is to be active.

For example :

REAL(PEXT) ; PEXT = 1.E5
OUTLET(OUTL1,NORTH,1,NX,NY,NY,1,NZ,3,5)
VALUE(OUTL1,P1,PEXT)

specifies an OUTLET extending from IX = 1 to NX, IZ = 1 to NZ at IY = NY, active during time steps 3,4 & 5, in which the pressure is held constant at PEXT.
The resulting mass flow is passing through the NORTH faces of the cells in question.

The function of the command is to generate a PATCH with the NAME and TYPE specified over the set limits.

COVALS are also generated for all solved variables, with:

for the COefficient and VALue, except

In the two-phase case the P1 & P2 coefficients are multiplied by RHO1 & RHO2 respectively, as long as both are constant. If either or both are GROUND-set, the coefficients are not changed.

It should be understood that the above coefficients are:

If outflow is to be ensured, the coefficient must be given a sufficiently low value to ensure that the pressure drop across the "outlet resistance" (for that is the physical significance of the patch) is considerably greater than the point-to-point pressure variations which occur in the computational cells adjacent to it. occurring with

See the entries on:

for further details.


Outline

------------------------------------ Photon Help ----

[Outline] causes the drawing to only take place on the out surface of the current plotting domain.

In the case of GRID, only the outline of the domain without mesh is drawn. The default is ON.

In case of STREAMLINES, this is inactive.


OUTPUT

---- Command; group 21 --------------

OUTPUT....is the command to specify what print-out and/or field dumping is required for stored and/or solved variables. The format of the command is:

OUTPUT(phi,Y or N,Y or N,...six times) (if uncertain, enter P for 'pass', which gives the defaults) The six questions answered by the Y's and N are:-

  1. Field print-out?
  2. Correction-equation monitor print-out?
  3. Selective dumping?
  4. Whole-field residual print-out?
  5. Spot-value table and/or plot?
  6. Residual table or plot?

Notes:


Output from EARTH

See PHENC entries: RESULT, PHOTON, AUTOPLOT, OUTPUT


OVER-PRESCRIPTION, a common user error

Among the easiest of errors to make when using PHOENICS is the setting of incompatible input data. Thus, the flow of an incompressible fluid can be specified as STEADY, and unequal inflow and outflow rates can be set; then, although PHOENICS will try to find values of pressure which will satisfy these conditions, it may well fail: then a divergence may occur which ought, strictly speaking, to be laid at the user's door.

To render such failures improbable, it is desirable that at least flow one boundary-condition 'patch' should be of the 'fixed- pressure' kind, e.g.:

PATCH(OUTFLOW,CELL, , , , , , , , )
COVAL(OUTFLOW,P1,1.E0,0.0)

Typically this will be at the boundary where the outflow is expected, a fixed inflow being specified at some other boundary.

The example just discussed concerns over-prescription in respect of mass flows; but, as the reader will be able to imagine, incompatibil- ities of input data can also be created in respect of the energy balance, or the balance of any particular chemical species. Once again, PHOENICS itself should be exonerated, if divergent calculations ensue.

There is a more subtle over-prescription error involving outflow conditions which arises from the notion, the origin of which is obscure, that the gradient of a scalar or a velocity component perpendicular to an outlet boundary "ought" to be zero. Well- intentioned attempts to impose such a condition by the introduction of GROUND coding have wasted much time. There is in fact no basis for this notion.


OVER-RELAXATION

In the default (Stone-type) linear-equation solver, Over-Relaxation, is used to accelerate reduction of errors, by applying, after each iteration, not the just-calculated correction but FACTOR times that value.

For any variable for which ENDIT is assigned a negative value, FACTOR equals minus ENDIT.

For other variable, FACTOR equals OVRRLX, unless OVRRLX=0.0 (its default) in which case FACTOR equals 1.0 .


OVRRLX

---- PIL real; default=0.0; group 17 ----

OVRRLX....is an over-relaxation factor for use in the built-in linear-equation solver. Values of the order of 1.7 are recommended. The feature is inactive if OVRRLX equals 1.0 or 0.0 (the default), and for those variables for which ENDIT is given a negative value.

See PHENC entry: over-relaxation.


wbs