In-form6.htm

Encyclopaedia Index Back to main contents

6. Initial values

The INITIAL keyword
Initial values for patches
Initial values for VR-objects
Initial values for In-Form objects

6.1 The INITIAL keyword

The (initial ...) keyword of In-Form is used for ascribing starting values of solved-for variables or auxiliary ones, i.e. those which have featured in a preceding SOLVE(), STORE() or SOLUTN() statement.

A simple example is provided by library case 707, in which a sinusoidal temperature profile reduces in amplitude while retaining its shape.

The variation of temperature with time (plotted as the z-axis, increasing to the right) is shown by this contour plot.

In the just-shown In-Form statement, the formula for the initial profile was valid for the whole domain; there was therefore no need for an 'at' in the statement.

More often, however, different specifications of initial values are required for different parts of the domain. Localization by means of 'at' are therefore necessary.

Three distinct kinds of localization are possible:

by reference to patches;
by reference to VR (i.e. faceted) objects:
by reference to 'In-Form objects' which are entities which are indeed defined by way of initial conditions.

These three topics will be discussed in turn.

6.2 Initial values for patches

The discussion will proceed by way of example:

A simple example is to be seen in library case 105 where indeed the old (PIL) and the new (In-Form) ways of doing the same thing are compared.
Somewhat more interesting are the following lines extracted from the core-library case 704
```
PATCH(IINIT,INIVAL,1,NX,1,NY,1,NZ,1,1)
(INITIAL of C1 at IINIT is XG+YG)
(INITIAL of EXAC at IINIT is XG+YG+:TLAST:)
```
for which no equivalent PIL statement exists. In this case, C1 is a solved-for variable; it is therefore given an initial distribution only for the first time step.
EXAC, by contrast, is an auxiliary variable which represents the exact solution of the problem; and, since its values vary with time, it has to be initialised at each time step, this being effected by the TLAST in the formula.
However, although 'at IINIT' does appear in the statement, examination of the arguments of the patch show that it extends over the whole domain; therefore, omitting all mention of IINIT would give the same result.
A better example is provided by case 758 which illustrates the use of the initial statement for the setting of three two-dimensional velocity fields, each in its own slab-shaped patch.
The fields correspond to:
- the first two fields have been placed on slabs IZ=1 and IZ=2, and
- the third, which to be placed on the IZ=3 slab, needs to make reference to the values which are present at the lower slabs.
An environmental example is provided by case 401 in which is simulated the rise of oil released from a wreck on the ocean floor. The deep water is initialised to 4 degrees Celsius and the near-water layer to 10 degrees.
As a consequence, the oil scarcely penetrates to the surface, as this contour plot shows.

6.3 Initial values for VR objects

(initial at OBJECT is FORMULA with OPTIONS)
is the syntax for specifying initial distributions for faceted objects, as is illustrated by case 764.

The object is a sphere, the material of which is the domain fluid (i.e. unusually, not a solid) and it is given a non-uniform initial enthalpy distribution by means of a formula with a 'with if' condition. This produces an initial field which is printed in the RESULT file (for iy=5) as:

 Field Values of H1
 IX=  10   0.0         0.0         0.0         0.0         0.0
 IX=   9   0.0         0.0         0.0         0.0         0.0
 IX=   8   0.0         1.860E+01   0.0         0.0         0.0
 IX=   7   0.0         1.740E+01   1.740E+01   0.0         0.0
 IX=   6   0.0         1.580E+01   1.580E+01   1.580E+01   0.0
 IX=   5   0.0         1.400E+01   1.400E+01   1.400E+01   0.0
 IX=   4   0.0         1.240E+01   1.240E+01   0.0         0.0
 IX=   3   0.0         1.120E+01   0.0         0.0         0.0
 IX=   2   0.0         0.0         0.0         0.0         0.0
 IX=   1   0.0         0.0         0.0         0.0         0.0
 IZ=          6           7           8           9          10

in which the specified variation with x and cut-off below iz=7 can be clearly seen.

It is not implied that anyone would desire such a bizarre initial enthalpy field, merely that, if anyone did, In-Form would make it possible, which PIL on its own, whether accessed via the VR-Editor or not, is unable to provide.

There is no need to present more examples of this capability of In-Form; for another of its capabilities, also connected with initial values deserves more attention.

a. Overview

A new class of object

Since the introduction many years ago of the 'Virtual-Reality' user interface, PHOENICS has made extensive use of 'objects'. [Click here for the relevant Encyclopaedia entry]

Now In-Form allows the use of its own objects, the positions and shapes of which are marked by the cells which they occupy; and it provides formula-based means for defining those cells.

It should be recognised from the start that In-Form objects occupy cells either wholly or not at all; they cannot at present, as facet-described (i.e. 'VR') objects can, occupy only part of a cell. This limitation may be removed in the future.

A change of syntax

All that has been explained above about attachment of In-Form operations (INITIAL, SOURCE, etc) to the whole domain, to patches in space and time, and to VR-objects, applies also to In-Form objects, as will be illustrated below. However the syntax is a little different.

For example, an initial value is attached to an In-Form object by way of a statement such as:
(INITIAL of PRPS at PATCH1 is 0.0 with INFOB_1)

wherein it can be seen that In-Form objects, here INFOB_1, are always associated with patches.

All this will be explained below. What must first be described however is how In-Form objects are actually created,

Object creation

In-Form objects are created by means of statements of the following format:

(INFOB at PATCHNAME is Formula with INFOB_N)

Here:

'INFOB' is a keyword which indicates what is to follow;
'PATCHNAME' is the name of a patch defined by a preceding (in the q1 file) PATCH statement, which defines the limits, in terms of ixf, ixl, iyf, iyl, izf, izl, itf and itl, within which the object may exist;
N is the index number of the object ; and
'formula' is a character string which defines the shape and position of the object in space and time.

The INFOB statement acts by 'tagging' the cells of which the centre lies within the object, recording at the same time which object is in question.

Additionally and optionally, if it is desired to indicate these cells via the RESULT file or PHOTON display, a 3D-stored variable (usually, but not necessarily, called 'MARK') is also given the infob index as its value.

To ensure this, the INFOB statement needs to be preceded by one such as:
(STORED of MARK at PATCH1 is 1.0 with INFOB_1)
which ensures that:

the variable MARK is indeed stored; and
that the value 1.0 is assigned to it in cells which are to be regarded as part of INFOB object number 1.

Is an INFOB PATCH a 'bounding box'?

VR objects have 'bounding boxes'. These are the smallest volumes which can be defined by grid-aligned surfaces into which the object will fit.

The patch associated with an In-Form object, however, is usually larger than would be the bounding box of the cells comprising the objects. It is the volume within which such cells may exist; but it is rare for any of these cells to touch the bounding surfaces of the patch.

In one sense the INFOB PATCH is unnecessary; for, if the PATCH were always defined as the whole domain, the effects of the object would be the same. However its existence acts as an economy measure; it tells PHOENICS where searching for parts of the object would be a waste of time.

That each In-Form object should have a distinct PATCHNAME is important; for it is this which is used, rather than INFOB_1, INFOB_2, etc when initial values and sources are ascribed.

New functions

Two special functions, namely 'BOX' and 'SPHERE', are used in the formulae which follow the INFOB keyword.

These may create directly objects having the shapes suggested by their names; but, with appropriately devised arguments, they may also be used for the creation of objects of much more complex shape.

It should be noted that both these functions can be used with cylindrical-polar and body-fitted coordinate grids as well as cartesian ones.

In the last respect they are superior to Virtual-Reality objects; for the latter can not be used with BFCs.

b. The BOX function

The format governing the use of BOX in INFOB statements is indicated by the following example:
(INFOB at PATCH1 is BOX(arguments) with INFOB_1)

This, in conjunction with the (STORED of MARK.... statement, uses BOX(arguments) to indicate which are the cells in question.

Also permissible is the statement:
(INFOB at PATCH1 is ALL - BOX(arguments) with INFOB_1)

This indicates that the said value of MARK is to be placed at all cells in the patch except those within the space defined by BOX.

'ALL' can here be regarded as a function which has no arguments.

The arguments in question are as follows:
BOX(x0,y0,z0,xsize,ysize,zsize,alpha,beta,theta)
where
x0 = X-coordinate of west south low corner of box, in meters
y0 = Y-coordinate of west south low corner of box, in meters
z0 = Z-coordinate of west south low corner of box, in meters
xsize = X-size of box side, in meters
ysize = Y-size of box side, in meters
zsize = Z-size of box side, in meters
alpha = angle rotating around x axis, in radians
beta = angle rotating around y axis, in radians
theta = angle rotating around z axis, in radians

Any one of the nine arguments can be expressed by way of a formula which may itself contain functions and constants.

Library case 383 illustrates the use of the box function for the creation of a box in a cubical domain, with all its rotations equal to 0.25 radians. A photon plot is shown here, created by the sur mark x 0.99 and sur mark y 0.99 commands.

c. The SPHERE function

The format governing the use of SPHERE in INFOB statements is similar to that of BOX, namely:
(INFOB at PATCH1 is SPHERE(arguments) with INFOB_1)

It has fewer arguments however, namely:
SPHERE(xc, yc, zc, radius)
where
xc = x coordinate of the centre, in meters
yc = y coordinate of the centre, in meters
zc = z coordinate of the centre, in meters
radius = radius of the sphere, in meters
because rotations about its centre cannot change its shape.

When the calculation is being carried out with a cartesian grid, the coordinate system of the sphere coincides with the coordinate system of the calculation domain.

When the calculation is being carried out with a polar-coordinate grid, the cartesian coordinate system of the sphere has its origin at the bottom left-hand corner of a square which circumscribes a circle of radius RINNER+YVLAST.

Therefore the cartesian coordinates xc and yc are related to the polar coordinates xp and yp by the relations:

xc=(yvlast+rinner) + (yp + rinner) * sin(xp)
and
yc=(yvlast+rinner) + (yp + rinner) * cos(xp)

The Z coordinates of the origins and the directions of Z axes of both coordinate systems coincide with one another.

'ALL - SPHERE' has the same significance as for 'BOX'.

Library case 772 creates an In-Form object, namely a sphere with its centre on the axis of a polar grid, by means of:
(INFOB at PATCH1 is SPHERE(10, 10, 10, 5) with INFOB_1)

The PHOTON plot displayed here reveals the result.

d. Simple shapes made with BOX

A pyramid

Core Library 769 shows how a pyramid can be created by a succession of In-Form statements employing the BOX function, in which the x-, y- and z-sizes vary with the value of zg.

The pyramid is made in four parts, each of which is rotated around the vertical edge which they share.

The following images show: the whole pyramid, then part 1, part 2, part 3 and part 4.

Inspection of the q1 file shows that each part of the pyramid is made by a different Infob statement, each of which however refers to the same PATCH1 and the same INFOB_1. The differences reside in their zangle arguments.

An x-direction pyramid

If a similar pyramid is required with its base on the X=0 surface rather than the z=0 one, at it is necessary to replace zg by xg in the In-Form statements and to interchange the first, fourth and seventh arguments (which relate to x) with the third, sixth and ninth (which relate to z). Then the result is as shown here.

The pyramids have been created, as other examples will be, by making one or more arguments of the box function depend the grid-point coordinate.

The information is used at the time that each grid-point is visited at infob-scanning time; and it implies that the question "is this cell-centre in the box?" refers, in general, to a different box for each cell.

A single infob in more than one patch

It is permissible, and sometimes convenient, to associate an individual In-Form object with more than one patch, for example when different time periods are in question.

Library case 783 illustrates this, wherein PISTON1 is a patch which is active for the first time step only, while PISTON2 is used for describing the position of the same In-Form object at later times.

Other simple shapes made by use of BOX

Library case 754 provides several examples of simple shapes made by the use of the BOX function.

e. Simple shapes made with SPHERE

Library case 749 provides several examples of simple shapes made by the use of the SPHERE function.

f. Some more-complex examples

Sphere connecting two tubes

Next 771 library case illustrates the creation of a Pump Chamber.

(INFOB at PATCH1 is SPHERE(10., 10., 10., 8.) with INFOB_1)

(INFOB at PATCH2 is SPHERE(XG, 16., 10., 2.) with INFOB_1)

(INFOB at PATCH3 is SPHERE(XG, 4., 10., 2.) with INFOB_1)

The first statement describes the central sphere, second - the top horizontal cylinder and third - the bottom cylinder.

Spheres inside wide channel

The creation of complex duct by means drilling of In-Form object in BFC is shown in 787 library case. At first a wide bent channel is created by means of BFC. The narrow channel is created from it by blocking any cells. Then two In-Form objects are described as spheres inside a wide channel.

(INFOB at PATCH1 is SPHERE(:XPP1:,:YPP1:,:ZPP1:,:RADIUS:) with INFOB_1)

(INFOB at PATCH2 is SPHERE(:XPP2:,:YPP2:,:ZPP2:,:RADIUS:) with INFOB_2)

Further inside each sphere values of PRPS variable are filled in with zero

(INITIAL of PRPS at PATCH1 is 0. with INFOB_1)

(INITIAL of PRPS at PATCH2 is 0. with INFOB_2)

See also the description of spiral-shape creation in section 7.4b below.