Encyclopaedia Index

### 8.1 Distinction between VR and In-Form Objects

In-Form treats the motion of faceted (i.e. (i.e. VR) and parameterised (i.e. In-Form) objects differently. For the former, it provides the MOVOB keyword and POS and OFFSET functions, which obviate the need to employ a MOF file; but it leaves the momentum sources to be introduced by built-in MOFOR coding within the Earth solver.

For the latter it allows formulae describing the motion to appear as 'position', 'size' and 'rotation-angle' arguments of the object-describing functions, BOX, SPHERE etc; and it attaches momentum sources describing the effect of the motion explicitly in the Q1 file.

The built-in MOFOR coding is then not activated.

### 8.2 Faceted (i.e. VR) Objects

#### (a) MOVOB and POS

The MOVOB keyword of In-Form enables the motion of VR objects to be described by way of formulae. How it is used can be seen by inspection of core library case 360, which shows two objects moving along different trajectories through a fluid.

MOVOB statements make use of the POS function for setting the X, Y and Z coordinates and the rotation angles about the X, Y and Z axes of a moving object as functions of the time variable, TIM:

In case 360, the relevant statements are:

```char(vel,gravt,times)
vel=10.; gravt=9.81; times=tim
(MOVOB of SPHERE1 is POS(:times:*:vel:,:times:*:vel:-0.5*:gravt:*:t\$
imes:^2,0,0,0,0))
(MOVOB of SPHERE2 is POS(-:times:*:vel:,0,0,0,0,0))```
These dictate a motion which, after the first time step appears thus:

Since the connection between the formula and the picture is not perfectly obvious, the following discussion is in order:
• Examination of the Q1 shows that the time interval is 0.1 second and that the domain size is 22 meters long and 7 meters high.
• Since the velocity has been set to 10 m/s, the x-coordinate of sphere1 is expected to be at 0.1*10 (i.e. :times:*:vel:) metres from its starting position; so it will have travelled a fraction 1/22 of the length of the domain.

Its distance of vertical travel will be about the same, because the acceleration term has not had time to become significant.

The presence of one sphere near the bottom left-hand corner in the just-seen picture suggests that this indeed sphere 1.

• Where should sphere2 be? Its x-coordinate and y-coordinate arguments in the (MOVOB....) statement are -1 (i.e. -:times:*:vel:) and zero. Yet, in the PHOTON picture, it appears to be near the extreme right of the domain, and halfway up. What is the explanation?

• To discover this, one must look at the object-describing part of the Q1 file, where are to be found the lines:
```
> OBJ,    NAME,        SPHERE1
> OBJ,    POSITION,    0.000000E+00, 0.000000E+00, 0.000000E+00
> OBJ,    NAME,        SPHERE2
> OBJ,    POSITION,    2.100000E+01, 3.000000E+00, 0.000000E+00
```
in which the 'position' lines show that sphere1 starts at the origin of the coordinate system, whereas sphere2 starts at x=21 and y=3.

• From these observations it can be concluded that the x,y and z coordinates in the MOVOB statement are measured relative to the positions of the objects in question, laid down in the '>OBJ' lines.

#### (c) The effect on the flow

The movement of the objects causes motions in the fluid also. This is achieved by the MOFOR feature of PHOENICS, about which the following remarks may suffice for present purposes:
• In the Q1 file for case 360, MOFOR is activated by the line:
SPEDAT(SET,MOFOR,MOFFILE,C,NOTSET)

This provides two pieces of information, namely:

1. that the MOFOR mechanism is to be activated; and
2. that a 'MOFFILE' is not to be used.
• The explanation of the second item is that, when MOFOR was first introduced to PHOENICS, the motion of objects was conveyed by means of an ASCII file with extensions .mof (earlier, .bvh). This means is still operative.

However, the moffile approach is rather too clumsy for motions which are simple enough to be described by formulae. This is indeed the reason for the introduction of the In-Form MOVOB keyword.

• The .mof~.bvh file format is provided with means of describing the motion of articulated objects, arranged in a 'hierarchy', such for example as the torso, upper alarms, lower arms, hands, and fingers of a human being, which are 'offset' relative to one another, and have limited freedom of relative movement.

As will now be seen, the 'hierarchy' and 'offset' concepts are also embodied in MOVOB.

#### (e) The OFFSET function

The OFFSET function is used when several objects move in pre-defined relative motion.

It is exemplified in library cases 381 and 382.

In-Form can calculate coordinates of a moving body position by the formula specified in "(MOVOB" In-Form statements which uses POS and OFFSET special functions. "(MOVOB" statement has next format:

```
(MOVOB of VR_OBJ_NAME is special_FUNCTION() with PARENT=PARENT_NAME)
```
where VR_OBJ_NAME is the name of the VR object name which is connected to a appropriate object-related coordinate system for which the current attributes are set.

The special In-Form flag "!PARENT=PARENT_NAME" set the name of parent object-related coordinate systems. The OFFSET function describes the hierarchy part of the attribute settings. OFFSET is In-Form special function of declaring the frames of reference of object-related coordinate systems. Each new OFFSET function declares a new frame coordinate system and describes its position relative to its

parent system. OFFSET has the following format:
OFFSET(arg1,arg2,arg3)
where arg1 ,arg2 and arg3 are formulas f defining the of the new coordinate origin relative to those of its parent.

Each formula can contain the TIM variable which is current time in seconds at the current time step.

#### (f) Examples

Elementary motion: linear movement

The task is to describe the linear motion of a 2D rectangular object called "BLOCK" with uniform velocity of 3m/s in Z-direction of computational domain starting from a given initial, stationary position of the object.

The movement is along Z-axis. The initial position and the sizes of the BLOCK are specified in the Q1 file. Z coordinates of moving BLOCK object are described as

Z velocity component[m/s] * current time[s].The following picture displays the result. It is input-library case v119

.

The description the hierarchy part is not mandatory as there is only one moving object. Therefore it is enough to define the Z position of moving object in each time step, thus:

```
(MOVOB of BLOCK is POS(0, 0, 3*TIM, 0, 0, 0))
```

More-complex movement: translation and rotation. The following image reveals what is to be simulated. It is input-library case v120

.

The case exemplifies the specification of the attributes for composite movement: the translation of a rotating block. It results in the effect of the rolling 2D rectangular object with the longitudinal (X-direction) velocity component of 0.5 m/s and the angular rotation about block centre line (Z-axis) of 30 degrees per seconds. The movement starts from the initially steady position defined in the Q1 file.

The hierarchy part is described as follows:

```
(MOVOB of CHAM is OFFSET(0&0&0))
(MOVOB of BLOCK is OFFSET(0.55&0.9&0) with PARENT=CHAM)
```

The OFFSET defines the position of the rotation axis relative to the root frame: it places the Z-axis in the middle of BLOCK initial position.

The movement is along X-axis and the rotation about Z-axis. X coordinates of moving BLOCK object and rotation angles are described as

```
(MOVOB of BLOCK is POS(0.5*tim&0&0&0&0&-30*tim))
```

Independent motions: crossing paths

The case exemplifies the setting-up the attributes for the independent movements of two objects following their own linear trajectories in 2D, X-Y, computational space.

The movement of the first object, called SPHERE1, starts from its stationary position at the west-south corner and follows a prescribed parabolic trajectory. The velocity of SPHERE1 is 10 m/s and is defined by interaction of gravitation force.

The second object, SPHERE2, starts at east-south corner of the domain and follows the linear trajectory crossing the one from right to left. It has the constant velocity component of -10 m/s in X-direction and 3 m/s in Y-direction.

The movement starts from the initially steady position defined in the Q1 file.

The description the hierarchy part is not mandatory as two moving objects move inside one root coordinates system. Therefore it is enough only to define the position of moving objects in each time step.

The movement of SPHERE1 object is along diagonal of XY plane. X and Y coordinates of moving object are described as

```
vel=10.; gravt=9.81
(MOVOB of SPHERE1 is POS(tim*:vel:&tim*:vel:-0.5*:gravt:*tim^2&0&0&0&0))
```

The movement of SPHERE2 object is along X-axis from right to left. X coordinates of moving object are described as

```
(MOVOB of SPHERE2 is POS(-tim*:vel:&0&0&0&0&0))
```

Connected objects: falling of a cracked wall

The case exemplifies the setting-up the attributes for the connected movements of two objects following their relative rotation in 2D, Y-Z, computational space.

The movement of the first object, called BLOCK, starts from its stationary position as a vertical wall with its base placed next to the middle of the bottom domain boundary. BLOCK is allowed to fall. It does so by rotating clockwise about X-axis of its south-high corner. The angular velocity of the fall is ,5 degrees per second.

Initially, the second smaller object, TIP, sits stationary on the top of BLOCK and can be regarded as a part of the wall. Once the whole wall starts to fall, it cracks and TIP begins to move in opposite direction by rotating counterclockwise about X- axis of the north-low corner of the BLOCK. The angular velocity of the TIP relative to the BLOCK is 180 degree per second.

The hierarchy part is described as follows:

```
(MOVOB of BLOCK is OFFSET(0&0&2.1))

(MOVOB of TIP is OFFSET(0&2.5&-0.5) with PARENT=BLOCK)
```

Two frames are defined: BLOCK is a parent joint, and TIP is the BLOCK's child.

The OFFSET of BLOCK defines the position of the rotation axis relative to the root frame: it places the origin of parent related coordinate frame at the south-high corner of BLOCK initial position.

The OFFSET of TIP defines the position of the rotation axis relative to the BLOCK frame: it places the origin of its coordinate frame at the north-low corner of BLOCK initial position.

The movement of BLOCK object is a rotation clockwise about X plane. Rotation angle is described as

```
(MOVOB of BLOCK is POS(0&0&0&75*tim&0&0))
```

The movement of SPHERE2 object is a rotation counterclockwise about X plane. X coordinates of moving object are described as

```
(MOVOB of TIP is POS(0&0&0&-180*tim&0&0))
```

Agitated reactor

Impellers are the units one most commonly associates with stirred reactors. The particular design considered here consists of the ROD, mounted on rotating vertical SHAFT. The rod carries two PADDLEs, which agitate the flow. As the impeller rotates it forces the surrounding fluid to rotate with it. The design with rotating paddles is used when "in-depth" mixing is a must.

The task of the exercise is to provide the attributes for connected movements of SHAFT-ROD-PADDLEs assembly following their relative rotation in 3D computational space. The angular velocity of the shaft is 60rpm.

The hierarchy part is described as follows:

```
(MOVOB of CHAM is OFFSET(0&0&0))

(MOVOB of SHAFT is OFFSET(0.15&0.25&0.25) with PARENT=CHAM)

(MOVOB of ROD is OFFSET(0&0&0) with PARENT=SHAFT)

(MOVOB of PADDLE1 is OFFSET(0&0&0) with PARENT=ROD)

```

Four frames are defined: SHAFT is a parent joint, and ROD, PADDLE1 and PADDLE2 are the SHAFT's children.

The OFFSET of SHAFT defines the position of the rotation axis relative to the ROOT frame: it places the origin of parent related coordinate frame at the middle of the SHAFT bottom face of its initial position.

The ROD and PADDLEs rotate about the same axis and has no freedom to move relatively to SHAFT. The OFFSETs of ROD and both PADDLEs are zero.

The movement of SHAFT object is a rotation clockwise about X plane. Rotation angle is described as

```
(MOVOB of SHAFT is POS(0&0&0&360*tim&0&0))
```

### Introduction

As has just been seen, In-Form's MOVOB keyword enables the motion of VR objects to be described; then activation of MOFOR sets the fluid in motion.

However, even before the existence of MOVOB, In-Form had a means of causing its own 'In-Form objects' to move, and to move the fluid with them. How this works will now be illustrated.

The fluid motion is achieved by attaching momentum sources to the In-Form objects. This was not in evidence when the MOVOB keyword was being used; but such sources were being introduced, nevertheless, behind the scenes.

Studying the 'source' statements associated with moving In-Form objects therefore throws some indirect light on how MOFOR works.

### a. Moving spheres

So the 765 library case sets the linear motion of two hot spherical bodies to follow a horizontal path as

(INFOB at FIRST is SPHERE(:xce:,:yce:,:zce:,:radius:) with INFOB_1)

(INFOB at SECOND is SPHERE(:xce:,:yce:,:zce:,:radius:) with INFOB_2)

It should be noted that the '(INFOB' statement can contain several long formulae. These can be spread over several lines in the Q1 file, with a '\$' symbol as the last character of a line acting as a continuation marker.
When the Q1 file is rewritten at the end of an interactive section, lines longer than 68 characters will be automatically folded with a \$ at column 68.

In the setting of long formulae it is recommended to use intermediate symbolical variables, as shown above.
The maximum possible length of a formula in any In-Form statement is 1000 symbols.

Heat sources within In-Form objects are represented thus:

(SOURCE of TEM1 at FIRST is 100. with INFOB_1)

(SOURCE of TEM1 at SECOND is 100. with INFOB_2)

The 770 library case set steady rotated In-Form object for simulation two paddle-stirred reactor. The rotated paddle is describes by In-Form:

REAL(ANGVL); ANGVL=4.*PI/1. ! Number of revolutions, 1/s.

REAL(X0,Y0); X0=0.5; Y0=0.5 ! X and Y coordinate of centre of impeller

char(ang,dx1,dx2,dy1,dy2); ang=:ANGVL:*TIM; dx1=:hsid2:*SIN(:ang:); dx2=:hsid1:*COS(:ang:) dy1=:hsid2:*COS(:ang:); dy2=:hsid1:*SIN(:ang:)

(INFOB at PATCH1 is BOX(:x0:-:dx1:-:dx2:,:y0:-:dy1:+:dy2:,0,0.1,0.7,10,0,0,:ang:) with INFOB_1)

The cartesian components of paddle velocity are set

(SOURCE of U1 at PATCH1 is :ANGVL:*(YG-:Y0:) with INFOB_1!FIXV)

(SOURCE of V1 at PATCH1 is :ANGVL:*(:X0:-XG) with INFOB_1!FIXV)

### c. Moving valve

The inclined linear motion of rectangular object is submitted in 784 library case. Here four immobile In-Form objects (1, 2, 3 and 4) describe the geometry of blading sections of the chamber.

(INFOB at WHOLE is BOX(0.,.07,0.,.04,.03,1.,0.,0.,0.) with INFOB_1)

(INFOB at WHOLE is BOX(.07,0.,0.,.03,.04,1.,0.,0.,0.) with INFOB_2)

(INFOB at WHOLE is BOX(.04,.07,0.,.05,.03,1.,0.,0.,:-PI/4:) with INFOB_3)

(INFOB at WHOLE is BOX(.07,.04,0.,.03,.05,1.,0.,0.,:PI/4:) with INFOB_4)

Each of them is a solid body with appropriate installations inside objects

(STORED of VPOR at WHOLE is 0. with INFOB_1)

(SOURCE of U1 at WHOLE is 0. with INFOB_1!FIXV)

(SOURCE of V1 at WHOLE is 0. with INFOB_1!FIXV)

(STORED of VPOR at WHOLE is 0 with INFOB_2)

(SOURCE of U1 at WHOLE is 0. with INFOB_2!FIXV)

(SOURCE of V1 at WHOLE is 0. with INFOB_2!FIXV)

(STORED of VPOR at WHOLE is 0. with INFOB_3)

(SOURCE of U1 at WHOLE is 0. with INFOB_3!FIXV)

(SOURCE of V1 at WHOLE is 0. with INFOB_3!FIXV)

(STORED of VPOR at WHOLE is 0. with INFOB_4)

(SOURCE of U1 at WHOLE is 0. with INFOB_4!FIXV)

(SOURCE of V1 at WHOLE is 0. with INFOB_4!FIXV)

Two next In-Form objects (5 and 6) describe the geometry of a valve and a valve holder.

Description of a geometry of a valve

X and Y coordinates of a valve in the first time step

REAL(XVAL,YVAL); XVAL=0.065; YVAL=0.035

Moving of a valve during one time step

REAL(DMOV); DMOV=THROW/LSTEP; DMOV=DMOV/1.414

INTEGER(HLS,HLS1,HLS2); HLS=LSTEP/2; HLS1=HLS+1; HLS2=HLS+2

CHAR(CXP,CYP); CXP=:XVAL:-:DMOV:*(:HLS:-ABS(ISTEP-:HLS1:)); CYP=:YVAL:-:DMOV:*(:HLS:-ABS(ISTEP-:HLS1:))

(INFOB at WHOLE is BOX(:CXP:,:CYP:,0.,.01,.042,1.,0.,0.,:-PI/4:) with INFOB_5)

Description of a geometry of the valve holder

X and Y coordinates of the valve holder in the first time step

REAL(DXH,DYH); DXH=0.0113; DYH=0.0252

(INFOB at WHOLE is BOX(:CXP:-:DXH:,:CYP:+:DYH:,0.,.01,.11,1.,0.,0.,:PI/4:) with INFOB_6)

Fixation of the valve velocities into valve

(SOURCE of U1 at WHOLE is :UP: with INFOB_5!FIXV)

(SOURCE of V1 at WHOLE is :VP: with INFOB_5!FIXV)

Fixation of the valve velocities into valve holder

(SOURCE of U1 at WHOLE is :UP: with INFOB_6!FIXV)

(SOURCE of V1 at WHOLE is :VP: with INFOB_6!FIXV)

### d. Football trajectory, 2D

The 766 library case illustrates the use of the In-Form 'SPHERE' function to simulate the effect on the motion of the air of a football following a prescribed parabolic trajectory. The In-Form object is presented as

(INFOB at PATCH1 is SPHERE(:xce:,:yce:,:zce:,:radius:) with INFOB_1)

Where xce,yce and zce are the x,z and z coordinates. They are character variables which are evaluated in the In-Form statements because they are enclosed within colons.

Setting of U1 and V1 values into SPHERE is

char(usour,vsour); usour=:vel:/1.414; vsour=:vel:/1.414-:gravt:*:times:

(SOURCE of U1 at PATCH1 is :usour: with INFOB_1!FIXV)

(SOURCE of V1 at PATCH1 is :vsour: with INFOB_1!FIXV)

### e. Football trajectory, 3D

The modeling of motion of spherical object in 3D space is submitted in 767 library case.

The In-Form object is presented as

(INFOB at PATCH1 is SPHERE(:xce:,:yce:,:zce:,:radius:) with INFOB_1)

Setting of U1, V1 and W1 values into SPHERE is

char(usour,wsour); usour=:vel:/1.414-:gravt:*:times:; wsour=:vel:/1.414

(SOURCE of U1 at PATCH1 is :usour: with INFOB_1!FIXV)

(SOURCE of V1 at PATCH1 is 0. with INFOB_1!FIXV)

(SOURCE of W1 at PATCH1 is :wsour: with INFOB_1!FIXV)

### 9.1 LONGNAME

Variables which are introduced by way of In-Form statements beginning:
(STORED
are computed at each sweep through the solution domain. However, it sometimes occurs that values are required only for print-out purposes.

In these cases, In-Form makes use of the longname feature, which slightly pre-dates In-Form itself.

Syntax The syntax of longname statements can be deduced from the following example extracted from Input library case 763:

```
The LONGNAME feature provides reminders at RESULT-reading time
(LONGNAME of L3RH print as 3-Piece-Wise_Linear_Density)
(LONGNAME of L3EN print as 3-Piece-Wise_Linear_Viscosity)
(LONGNAME of L3CP print as 3-Piece-Wise_Linear_Specific_Heat)
(LONGNAME of L3CN print as 3-Piece-Wise_Linear_Conductivity)```
This illustrates the use of longname as a reminder, which will be printed in the RESULT file as a field-values title, of what formula has been used for the calculation of density and other properties.

The similarity of the property and longname entries in this example should not however lead to the supposition that their treatment by PHOENICS is similar.

On the contrary; whereas what follows "is" in the property statement must a meaningful formula, that in the longname statement can be any string of characters. Equally acceptable, for example, would be:

```
(LONGNAME of VISL is my_new_formula)```

### 9.2 PRINT

Another feature for a dump of variables values in a separate file is the '(PRINT' In-Form statement. It prints fields of standard dependent variables, or of user-defined single real variables calculated by Formula, in an INFOROUT file, which it places in the working directory.

Its format is:

(PRINT String_15 [at PatchName] is Formula)

where

String_15 is a character name with a length of 15 symbols;

PatchName is the name of a PATCH or VR object.

The length of String_15 together with PatchName is limited 15 symbols according to SPEDAT format.

The String_15 string is a comment of dumping variables.

Examples of use are:

(make pinlet) ! make user-defines single real variable

(store1 of pinlet is old(p1[1,1,1]) with if(isweep.eq.1)) ! define pinlet

(print of pin is pinlet) ! dump in INFOROUT file the pinlet value

(stored of pold is old(p1) with if(isweep.eq.1)) ! calculate POLD variable

(print of p1_old is pold) ! dump in INFOROUT file the fields of POLD

The 362 and 363 library cases use for a print-out of user-defined single real variables ASUM and TSUM.

(PRINT of Whole_high_area is ASUM)

(PRINT of IZ=NZ__Sum_TEM1 is TSUM)

### 9.3 Coefficients, residuals, corrections and exchange coefficients (gammas)

Contents:
1. #### Coefficients

Users who are interested in the finite-volume equations solved by PHOENICS may print, and manipulate, terms which enter those equations.

The typical form these equations is seen by clicking here.

The terms which may be accessed are:

• the north, south, east, west, high and low coefficients:
aN, aS, aE, aW, aH, aL;
• aP, which is added to the denominator; and
• S, which is the so-called "residual", i.e. the current imbalance in the equation.

The In-Form statements which enable them to be accessed have the form:

(STORED of name is AX(varname))

where:

• name is the name chosen by the user for the coefficient in question, for example E_V1 if the east coefficient of variable V1 is in question
• X is N, S, E, W etc according to the coefficient which is required; and
• varname is the name of the solved-for variable which is in question, i.e. V1 in the just-mentioned case.

A complete set of examples can be found in input-library case 788

2. #### Residuals

The equation imbalances, i.e. the residuals, may be obtained in a similar manner; but for them the In-Form Statement is:

(STORED of name is RESI(varname))

Such statements are also to be seen in case 277.

3. #### Corrections

Solving the finite-volume equations produces "corrections", i.e. quantities which should be added, cell-by-cell, to the values of the solved-for variables in order to reduce the imbalances in the equations.

(STORED of name is CORR(varname))

Examples of accessing residuals and corrections are to be found in library cases: 249, concerned with 2D flow in a square cavity, and 768, concerned with 3D flow in a water heater.

If on-line, click here for the temperature field, the residual field, and the correction field for case 249.

Because the solution is well-converged, the values of both the residuals and the corrections are very small. This accounts for the irregularity of the residual field, of which the values have been reduced to the round-off error of the computer.

This method of displaying residuals and corrections is more convenient than the older-established method, which involved giving the variable of which residuals and corrections were required a special name, ending with the % sign. That method however is still available.

#### Warning

It will sometimes occur that the corrections are printed as zero. The explanation is that the iterative computation will have stopped before the prescribed value of LSWEEP because the residuals had fallen below the reference value; therefore the solver, which is where the corrections are computed, may not have been entered.

The cure is to set NPRINT to some value well below that of the number of sweeps at which solution terminated.

4. #### Exchange coefficients (gammas)

Also of interest to those who study the workings of the numerical-solution process are the exchange coefficients, i.e. diffusivities times densities, which enter (together with convection contributions) into the calculation of aN, aS, aE, aW etc. These too may be accessed by way of an In-Form statement, which is in this case:

(STORED of name is GAMM(varname))

This feature is illustrated in case 788.

5. #### Manipulating the coefficients, etc

Like other 3D-stored variables, the coefficients and other quantities mentioned in the present section may be:

• given initial values via FIINIT,
• confined between upper and lower values by way of VARMAX and VARMIN, and
• "relaxed" via RELAX(name,LINRLX, factor).

These possibilities give the user great power to intervene, if he or she wishes, in the solution process.

### 9.4 Eliciting debug

In-Form is supplied with extensive debug facilities, for the investigation of suspected errors.

These facilities are activated by use of the "read Q1" facility. Specifically, the Q1 file is supplied with, starting in column 3 or greater:

• the starting line:
informbegin

• a second line:
debug t

• a succession of further lines, of the kind:
feature t
or
feature f

where feature is one of the list given below

• concluded by the finishing line:
informend

The full list of features is:

FULL
for all the following
FORMULA
for displaying the formula being parsed
INITIAL
for initial-value settings
STORED
for stored-value settings
MAKE
for the MAKE facility
PROPERTY
for property settings
SOURCE
for sources
LINE
for linearization aspects
XGRID
for grid-related settings
YGRID
ZGRID
TGRID
INFOB
for In-Form objects
MOFOR
for moving objects

As is obvious, debug of a particular kind is activated when t follows the feature name, and deactivated by f.

An f following debug deactivates all debug features.

All debug features are f by default.

In-Form debug print-out is governed by the same indices as is the older-established debug from EARTH, i.e. that elicited by the PIL variable debug, namely izdb1,izdb2, etc.

Library case case 768 provides an example.

The READQ1 features of PHOENICS allow variables which do not form part of the PIL set to be transmitted to EARTH. However, each variable requires one extra line to be inserted in the Q1 file.

In-Form allows up to 20 variables to be transmitted in a single line (possibly with 'continuation' effected by the \$ sign), by means of the READREALS, READINTS, and READLOGS statements.

Their use is illustrated by the facility (introduced with PHOENICS-3.5) for changing turbulence-model constants, which is described here,

Suppose, for example, it were desired to employ the different constants:
 CMU =0.6 CD =0.2 C1E =1.5 C2E =1.92 AK =0.4 EWM =9.0

This could be effected by inserting in the Q1 file the line:

(READREALS turconst 0.6 0.2 1.5 1.92 0.4 9.0)

When the satellite reads this line, it places in Q1EAR the line:

```
which is echoed in RESULT; and in EARDAT the line:
```
This is then acted upon by the sequence of coding starting with IF(GETREALS in the subroutine INIVST, which duly interprets what it finds and records its work by printing the following in the RESULT file:
```
CMU     = 6.000000E-01 CD      = 2.000000E-01
C1E     = 1.500000E+00 C2E     = 1.920000E+00
AK      = 4.000000E-01 EWAL    = 9.000000E+00
```
This example has shown how real variables may be transmitted. Integer and logical variables are transmitted by use of READINTS and READLOGS statements in the corresponding manner.

#### (b) Discussion

The following points need to be understood by those wishing to exploit this powerful new means of transmitting simulation-defining data:
• Of course, inserting (READREALS etc ) in a Q1 file is of no effect unless there exist corresponding CALL GETREALS in the EARTH coding; and at present (May 2002) there are few of these.

The new technique is therefore mainly of use to those having access to re-compilable versions of PHOENICS.

• Whereas the READQ1 facility did involve the reading of Q1 by the EARTH module, this is not true of In-Form's READxxx; for this uses EARDAT as the information-transmitting file.

• It also makes use of SPEDAT (which is true of all In-Form features); but it differs from the conventional uses of SPEDAT for transmitting single real, integer and logical values both:
• in capability, in that it can convey many values, and
• in method, in that it uses SPEDAT in character-string mode, which is signalled by the C in the Q1EAR, RESULT and EARDAT lines).

• The GETREALS, GETINTS and GETLOGS logical functions make no protest if, when they inspect the SPEDAT transmissions, they find no entry corresponding to their first argument (namely 'TURCONST' in the above example). They simply return their logical value as .FALSE. .

### (a) Historical background

• In-Form was conceived as an extension to the PHOENICS Input Language, PIL. The VR-Editor, on the other hand, was conceived as a replacement for PIL, and moreover that of earlier years.

• Even as a replacement, the VR-Editor has some deficiencies; for example it lacks the ability to 'declare' variables, or even to retain declarations already in the Q1.

• As has been seen, In-Form makes much use of declared-and-set character variables, which the VR-Editor could not retain.

• It is for this reason that informXbegin and informXend markers have had to be placed at the head and end of every set of In-Form statement, if the Q1 is to be processed by the VR-Editor.

• X, in these markers, is a number indicating to the VR-Editor into which 'Group' it should place the In-Form statements when writing an end-of-session Q1, namely:
• Group 7 for storing whole-field variables, whether stored-only or also solved;
• Group 9 for property-related settings,
• Group 11 for initial values, and
• Group 13 for sources and boundary conditions.

• However, this protection still leaves open the question: How can the user see and, if desired, modify, the In-Form settings?

### (b) Editing In-Form statements via the menu

The question has been answered by providing "In-Form" buttons in all appropriate menu panels of the VR-Editor, which access a newly-created 'In-form editor'.

One such button is shown here, for the top panel.

When that button is pressed, the Inform Editor appears.

Similar buttons appear on lower-level panels of the VR-Editor user-interface.

### (c) Example; library case 360

There now follow several screen-capture images which show stages in the editing of the moving-body trajectory.

The existing Group 13 statements are viewed here

They are then changed by way of Notepad-like editing actions to this.

When they are what the user wants, they are saved.

This action places them in the phxx file which the VR Editor uses to store items which must be written to the final Q1, the relevant part of which is seen here:

```
Echo InForm settings for Group 13
inform13begin
char(vel,times);
** Definition of the first moving In-Form Object
vel=10.;times=tim
xce=0.5+:times:*:vel:
```

### (d) The future of the Inform Editor

• The VR and In-Form Editors work satisfactorily together.

• However, it will take some time for the maturity of the former to be emulated by the latter, and for the In-Form Editor's greater flexibility to be utilised by VR.

• The In-Form Editor needs at least two additions before it can be considered mature, namely:
1. It must enable suitable formulae to be selected from lists in drop-down menus; and
2. it must subject what is typed in to immediate validity checks, and then reject, with advice, syntactical errors.

• What it can offer to the VR-Editor is the ability to handle:
• PIL declarations,
• IF statements and
• DO loops; and indeed
• all the excellent PIL features which the current VR-Editor disregards.

Now that the PHOENICS Commander, which also employs the Tcl/Tk package, has been adopted as the main introduction to and manager of PHOENICS, these additions to the In-Form Editor will swiftly be made.