Click below for Contents Lists.
Brief or extended
or on the right
for a power-point presentation about In-Form.
The formulae are placed in the data-input file, Q1 by way of a text editor, or via the graphical user interface of PHOENICS, the Virtual-Reality Editor.
The PHOENICS input module, Satellite, thereafter transmits the implications of the formulae to the solver module, EARTH. There they are recognised as instructions to perform the appropriate computations. The user has nothing more to do except await and inspect the computed results.
PLANT still exists and functions as before, for users who have become accustomed to it; but In-Form can now do all that PLANT can do, and more.
Moreover, In-Form not only greatly the range of admissible new-to-PHOENICS features: it also allows already existing features to be introduced in simpler ways. In particular, it renders unnecessary the use of GRNDx as an option indicator; and even the long-established COVAL command can often be replaced by a simpler statement.
Method 1 has sufficed for the majority of users for most of their requirements, not least because the standard solver module is richly endowed with already-prepared GROUND-type sub-routines which can be switched on or off by pointers (the GRNDx flags) placed in Q1.
However, it is impossible to provide sufficient of these to satisfy all the needs which users may at some time express; therefore methods 2 or 3 have been extensively and successfully employed by many users throughout the years. Besides, keeping track of what all the GRNDx pointers mean is rather tiresome.
Method 2, of course, is accessible only to users with sufficient knowledge of Fortran, and the leisure to exploit it.
Method 3 requires no such knowledge; so it can be used by a wider circle of users. Nevertheless, like Method 2, it does necessitate the possession of a re-compilable version of PHOENICS, and of a compiler, both of which entail extra expense.
This is why In-Form has been introduced. It provides:
(keyword what_where_when_indicators formula optional_conditions)
English words such as 'at', 'of', 'is' and 'with' appear as meaningful separators.
Users do not need, but may be interested, to know what SATELLITE does when it has read the statement. This is as follows:
The line in Q1:
RHO1 = 1.189
sets its value to a constant, namely that of 1-atmosphere
20-degree-Celsius air.
If some other setting is needed the Encyclopaedia article on RHO1 shows how alternative settings may be made.
For example, the setting:
RHO1=GRND1
leads to four options, the selection from which is effected by ascribing
values to one or more of the PIL variables: RHO1A, RHO1B, RHO1C,
IBUOYA, IBUOYB etc.
Further opportunities are opened by the settings:
RHO1=GRND2
RHO1=GRND3
until
RHO1=GRND10
The choice is thus rich, if somewhat bewildering; but, inevitably, it is still limited.
The dialog boxes of the PHOENICS Graphical User Interface, of course, are designed to reduce the bewilderment, by presenting the alternatives in a systematic way; but they can do nothing to overcome the limitations.
Let its definition be such that H1 is zero at 20 degrees Celsius.
This option might be selected if one were seeking to represent the
dependence on temperature of the density of atmospheric pressure
air, which is most naturally expressed as:
RHO1 = 1.189 * [ 1.0 + H1 / ( 1005.0 * 293.0 ) ]
wherein:
1005.0 is the constant-pressure specific heat of air, and
293.0 is the absolute temperature corresponding to 20 degrees
Celsius.
Of course, RHO1A and RHO1B have to be calculated as 1.0 and 1.0/(1005.0*293.0) respectively.
This is easily written and easily understood; and its writer needs to make no visit to the Encyclopaedia in order to check that the right GRND number has been chosen.
In-Form thus allows users to express their requirements in a natural manner.
Instead he could simply extend his formula thus:
(property RHO1 is 1.189*(1.0 + H1/(1005.0*293.0) + 1.e-6*H1^2))
[Here 1.e-6 is just an example, of course; any value could be used. The ^ is the In-Form symbol for exponentiation.]
No. The Satellite converts all characters to upper-case before processing them. Some users prefer to place the In-Form-specific words 'property' and 'is' in lower case, and the ones which they have introduced (here 'RHO1' and 'H1') in upper case. Or they may use the opposite rule; or none at all. It is their choice.
Insertion of a $ sign in or before the 68th column will be interpreted by SATELLITE as an append-next-line command; so In-Form statements consisting of two lines (but no more) are allowed. However, if the formula is so long as to exceed this limit, it is necessary to construct it out of several smaller parts, as shown here.
Yes. For example the PIL variable RHO1A could be introduced in
place of the 1.189 of the formulae, if the setting:
RHO1A=1.189 preceded the In-Form statement thus:
(property RHO1 is RHO1A)
Good question! The answer will be provided in section 2.2 .
The answer is that all three specifications would be transmitted to and processed by EARTH; but it is only the last to appear in the Q1 which would actually be used for the flow-simulating calculation.
The answer is negative: it is in EARTH that the decision is made; and it is always the In-Form statements EARTH which chooses to follow.
The reader may care to check these statements by running PHOENICS with the following Q1:
TALK=f;RUN(1,1) store(rho1) (property rho1 is 1.0) (property rho1 is 2.0) (property rho1 is 3.0) rho1=4.0 STOPThe RESULT file will show RHO1=4.0 in the GROUP 9 print-out; but the field print-out will show RHO1 to be 3.0.
It will also carry the printed line: "Formula used for setting RHO1" .
New users will find it helpful to inspect the Encyclopaedia article on SPEDAT first.
SPEDAT(SET,PROPERTY,RHO1,C,=1.189)in Q1EAR ( and later in RESULT),
wherein the 'C,' is a reminder that what follows it must be treated as a character string.
The solver module, EARTH, does not read this however. It reads instead the EARDAT file, where the corresponding entry is:
PROPERTY RHO1 C=1.189
SPEDAT(SET,PROPERTY,RHO1,C,=1.189*(1.0+H1/(1005.0*293.0)))in Q1EAR, and
PROPERTY RHO1 C=1.189*(1.0+H1/(1005.0*293.0))in EARDAT.
SPEDAT(SET,PROPERTY,RHO1,C,=1.189*(1.0+H1/(1005.0*293.0)+1.E$) SPEDAT(SET,PROPERTY,RHO1,C,-6*H1^2))in Q1EAR, and
PROPERTY RHO1 C=1.189*(1.0+H1/(1005.0*293.0)+1.E$ PROPERTY RHO1 C-6*H1^2)
in EARDAT.
The following comments are appropriate:
This will now be explained, under the headings:
It should be noted that:
See also Appendix 2 for a succinct summary of In-Form-statement features, in which it will be seen (from the appearance of [] brackets, which items may be dispensed with).
Such variables are of two main kinds, namely:
These will be discussed in section 5.
This keyword is discussed in section 6.
In accordance with the usual PHOENICS practices, boundary conditions are also introduced by its means.
Sources may, like initial values, be applied to the whole domain or to variously-defined limited spaces.
As originally introduced, the motion of objects had to be specified by way of a .bvh (later .mof) file. Whereas this was necessary and convenient for complex motions of articulated objects such as the 'dancing man', it was over-complicated for others, for which formulae suffice.
The MOVOB keyword, discussed in section 8.1, makes this possible, indeed easy.
Here RHO1 is of the 'what_where_when' kind, and specifically 'what': it says: 'this formula applies to the variable with name RHO1' and, by implication, to no other. It can thus be regarded as a pre-formula condition.
As it happens the words: 'of RHO1 is', or 'var RHO1 is' would have had the same effect; but, since the 'of' and 'var' add little to the understandability of the statement, they are best omitted.
The word 'is' is a signal that the formula follows. It must not be omitted.
An example of a Q1 file which defines density differently for each of four different patches (SW, NW, NE, SW) now follows.
#249 case 249 (square cavity with moving lid) has now been loaded STORE(RHO1) ! in order that PHOTON will be able to display it ! now declare the patches to which 'at' can refer. PATCH(SW,CELL,1,NX/2,1,NY/2,1,1,1,1) ! south-west quadrant (property RHO1 at SW is 2.0) PATCH(NW,CELL,1,NX/2,NY/2+1,NY,1,1,1,1) ! north-west quadrant (property RHO1 at NW is 3.0) PATCH(NE,CELL,NX/2+1,NX,NY/2+1,NY,1,1,1,1) ! north-east quadrant (property RHO1 at NE is 4.0) PATCH(SE,CELL,NX/2+1,NX,1,NY/2,1,1,1,1) ! south-east quadrant (property RHO1 at SE is 5.0)Here, the 'where' is specified by the IXF, IXL, IYF etc arguments of the patch commands; and the 'when' by the final '1,1's which, since the case is a steady-state one, signify 'at all times.'
The result is as shown (with the smearing engendered by the very-coarse grid) in the following PHOTON plot.
Readers interested in the transmission details may like to know that the relevant EARDAT contains the lines:
PROPERTY RHO1!SW C=2.0 PROPERTY RHO1!NW C=3.0 PROPERTY RHO1!NE C=4.0 PROPERTY RHO1!SE C=5.0wherein it will be noted that the exclamation mark, !, replaces 'at'; and
the corresponding lines in the Q1EAR and RESULT files are:
SPEDAT(SET,PROPERTY,RHO1!SW,C,=2.0) SPEDAT(SET,PROPERTY,RHO1!NW,C,=3.0) SPEDAT(SET,PROPERTY,RHO1!NE,C,=4.0) SPEDAT(SET,PROPERTY,RHO1!SE,C,=5.0)
However, INIVAL patches allow only uniform (or linear in x or y or z, via LINVLX, LINVLY and LINVLZ) values to be set, whereas In-Form can set any non-uniform ones which can be described by formulae, for example:
(property rho1 at sw is 100*(xg + yg)) (property rho1 at nw is 1.0 + 1.e-1*(u1+v1)) (property rho1 at ne is 10.0 + 0.0001*p1/h1) (property rho1 at se is 5.0+0.1*((xg)^2 + (yg)^2))from which it can be deduced that the formulae may involve other 3D-stored variables (u1, v1, p1, h1) and also geometrical quantities (xg, yg) .
In association with In-Form SOURCE settings which depend upon the PRPS value, to be described below, the fluid is set in motion as seen here.
Input-Library case 764 shows how the viscosity can be set at different values according to whether the cell in question lies inside or outside a sphere defined by way of facets.
The sphere object is of course that defined by the line:
> OBJ, NAME, SPHERE
near the bottom of the Q1 file.
The resulting viscosity distribution is here shown in a VR-Viewer contour plot.
Further scrutiny of the Q1 file for case 764 reveals the 'at' condition in use also for statements with the keywords PROPERTY, INITIAL, STORED and SOURCE,in each case showing that the formula is to be applied to the sphere. Evidently it is very versatile.
This appeared natural, and conducive to orderly thought; but was it necessary?
In case 764, the lines with 'at sphere' all appear above the line which defines the sphere object. This suggests that the patch-first-at-later principle may not a necessity; and the suggestion can be proved to be correct by running the following Q1:
#249 case 249 (square cavity with moving lid) has now been loaded STORE(RHO1) ! in order that PHOTON will be able to display it ! now declare the patches to which 'at' can refer. (property RHO1 at SW is 2.0) (property RHO1 at NW is 3.0) (property RHO1 at NE is 4.0) (property RHO1 at SE is 5.0) PATCH(SW,CELL,1,NX/2,1,NY/2,1,1,1,1) ! south-west quadrant PATCH(NW,CELL,1,NX/2,NY/2+1,NY,1,1,1,1) ! north-west quadrant PATCH(NE,CELL,NX/2+1,NX,NY/2+1,NY,1,1,1,1) ! north-east quadrant PATCH(SE,CELL,NX/2+1,NX,1,NY/2,1,1,1,1) ! south-east quadrantwhich will be found to give the same results as before.
The patch-first-at-later prescription is a good rule to follow; but it is not required by In-Form.
Then any algebraically-literate person would recognise this as being expressed symbolically, with x, y and z as the Cartesian coordinates, by:
density = 1 / ( x**2 + y**2 + z**2 )**0.5
with ** signifying exponentiation.
This is (almost) exactly how it is expressed in an In-Form statement, which
might be:
(property RHO1 is 1/(XG^2 + YG^2 + ZG^2)^0.5)
wherein xg, yg and zg denote the Cartesian coordinates of the cell centres, and ^ replaces ** as the exponentiation sign.
Then the formula could be expressed as:
1/((XG-X0)^2 + (YG-Y0)^2 + (ZG-Z0)^2)^0.5
It is therefore useful to recognise that PIL is flexible enough to allow the formula to be built up in stages, each one being brief enough be easily understood.
Then the formula could be abbreviated to:
1/(:XDSQ: + :YDSQ: + :ZDSQ:)^0.5
wherein the colons signify that, because XDSQ etc are character variables, they must be evaluated as soon as read by SATELLITE.
whereupon the whole In-Form statement would be reduced to:
(property RHO1 is :FORM:)
talk=t;run(1,1) store(rho1) nx=50;ny=50;nz=50 xulast=2.4;yvlast=4.4;zwlast=6.6 #unigrid inform9begin REAL(X0,Y0,Z0) X0=1.2; Y0=2.2; Z0=3.3 Case 1 (property of RHO1 is 1/((XG-X0)^2 + (YG-Y0)^2 + (ZG-Z0)^2)^0.5) Case 2 CHAR(XDSQ,YDSQ,ZDSQ) XDSQ=(XG-X0)^2 YDSQ=(YG-Y0)^2 ZDSQ=(ZG-Z0)^2 (property of RHO1 is 1/(:XDSQ: + :YDSQ: + :ZDSQ:)^0.50 Case 3 CHAR(FORM) FORM=1/(:XDSQ: + :YDSQ: + :ZDSQ:)^0.5 ! colons are needed here too FORM=1/(XDSQ + YDSQ + ZDSQ)^0.5 ! This would be incorrect (property of RHO1 is :FORM:) inform9endIf Group 19 of the RESULT file is examined, it will be seen that all four of the formulae have been converted into identical SPEDAT lines; and the VR-Viewer plot shown here indicates (qualitatively) that the resulting density field is as expected.
Keyword-specific options will be dealt with keyword-by-keyword in section 4. However there are three which apply to many keywords, being characterised by IMAT, IF and INFOB.
These will be dealt with, in order, here.
The flow is transient; so this is a 'when' as well as a 'where' condition.
'with IMAT>=100.0' is what appears in the In-Form statement in question.
(SOURCE of U1 at I is 1.E5*(VEL*(YIC-YG)-U1) with IMAT>=100!LINE) (SOURCE of V1 at I is 1.E5*(VEL*(XG-XIC)-V1) with IMAT>=100!LINE)are ( with $ and blanks removed for ease of reading ):
SOURCE U1!I C=1.E5*(7.8540E-01*(10-YG)-U1)!IMAT>=100!LINE SOURCE V1!I C=1.E5*(7.8540E-01*(XG-10)-V1)!IMAT>=100!LINE
Evidently the ' with ' has been replaced by an exclamation mark.
Consider now the '!LINE' which follows 100 in both the In-Form statements and their EARDAT counterparts. The following needs to be noted:
Other variables than PRPS can be used in a similar way. Thus, it is possible to:
Another generally-applicable post-formula option is the "IF( condition)" construct, wherein condition can be a Fortran-like expression, as exemplified in library cases:
It should be noted that either ' with ' or '!' must always precede the 'IF'.
This value is usually 1, 2, 3 or other integer. Then the post-formula option 'with INFOB_BALL', say, signifies that the formula is to be applied to cells where MARK has the value 2 (strictly 2.0, because 'real' values are in question).
Library case 768 illustrates its use.
Specifically, 'with INFOB_1' will be seen to modify
It should be noted that it is no longer necessary, as it was when case 768 was created, that 'INFOB_' should be followed by a numeral. Now any string of characters can be used, as in 'BALL' above.
It may be asked why, since this condition is of the 'what_where_when' variety, it is not among the 'pre-formula' options. The answer is that 'at' has already been used for a different purpose; for an In-Form object itself requires to be 'localised', which is why 'at PATCH1' appears in each of the In-Form statements in question.
Contents
No significance attaches to whether upper- or lower-case characters are used.
The syntax of all In-Form functions corresponds to Fortran. At first the function name is specified. Further in brackets the its arguments follow separated from each other by commas (or ampersands).
In general case arguments of many functions can be the formulas containing constants and names of solved, stored and user-defined variables or any variables from list in Appendix 4: In-Form operands . Except for some functions of which will be commented specially below.
The functions, listed in alphabetical order in Appendix 1, are as follows:
conventional mathematical functions:
EXP(arg1/(R*T))
where R is the universal gas constant = 8314.31, T is the absolute temperature and arg1 is a formula.
The mathematical functions can be used in any In-Form statements. In general case their arguments can be the formulas containing constants and names of any variables.
The examples of use are specified in Appendix 1: In-Form functions .
Syntax of POLx()
POLx is followed by a bracket, then the name of the variable in question, then a comma or ampersand (i.e. , or &) followed by the requisite number, separated by further commas (or ampersands).
Thus:
Examples of use of polynomial functions are to be found in
library cases:
701
for POL3();
345
for POL4();
089
for POL6() and POL5(),
whereby it may be remarked that the practice of case
345, in which the coefficients are declared and allocated before
being placed as symbols in the In-Form statement, is preferable
from the view-point of clarity.
Syntax of PWL3()
The syntax of PWL3() is similarly constructed. Thus, PWL3 is followed by a bracket, then the name of the variable in question, followed by a comma or an ampersand.
Thereafter follow pairs of numbers, of which the first is the abscissa and the second is the corresponding ordinate, thus:
PWL3(x , x0 , y0 , x1 , y1 , x2 , y2 , x3 , y3 )
represents y as a function of x consisting of straight
lines which pass through
(x0,y0), (x1,y1), (x2,y3), (x3,y3).
Here x may be a constant or a solved/stored variable and
x0 , y0 , x1 , y1 , x2 , y2 , x3 , y3 are constants.
Library case 763 illustrates the use of this function. It enables different formulae for setting each of four fluid properties to be compared.
It calculates the four relevant properties of the fluid (ethylene glycol) in four different ways, namely by way of:
Syntax of SPL5()
The syntax of SPL5() is similarly constructed. Thus, SPL5 is followed by a bracket, then the name of the variable in question, followed by a comma or an ampersand.
Thereafter follow pairs of numbers, of which the first is the abscissa and the second is the corresponding ordinate, thus:
SPL5(x , x0 , y0 , x1 , y1 , x2 , y2 , x3 , y3 , x4 , y4 , x5 , y5 )
represents y as a spline function of x
which passes through
(x0,y0), (x1,y1), (x2,y2), (x3,y3), (x4,y4), (x5,y5)
As in the previous function x may be a constant or a solved/stored variable and x0 , y0 , x1 , y1, etc are constants.
Library case 763 illustrates the use of this function also.
Syntax of PWLF()
PWLF is followed by;
Examples of the use of PWLF can be found in library case 763, in which the property values at a range of values are read from the files:
The file is a free-format ASCII file which can be created with any convenient file editor. Lines starting with # or * are ignored. Anything following a ! (including the !) is ignored.
The first active line may optionally contain the names of the columns. These names are not actually used.
The following lines contain the numerical values of the variables. The file can contain any number of lines, each line containing two values.
The values of the first (X) column must always increase, as otherwise it is not possible to obtain a unique value for the interpolation.
A space, comma, semi-colon (;) or tab can be used to separate the columns.
Syntax of INTPOL()
INTPOL is followed by;
The file is a free-format ASCII file which can be created with any convenient file editor. Lines starting with # or * are ignored. Anything following a ! (including the !) is ignored.
The first active line must contain the names of the columns. These names are used as the second and third arguments of the command.
The following lines contain the numerical values of the variables. The file can contain any number of columns and lines, with the restriction that all lines must contain the same number of columns.
The values of the column designated as the dependent (X) variable must always increase, otherwise it is not possible to obtain a unique value for the interpolation.
A space, comma, semi-colon (;) or tab can be used to separate the columns.
They calculate of variable value at neighbouring cell beside appropriate face and at previous time step.
Syntax of neighbour-location functions is conventional in PHOENICS. The function name is followed by a bracket, then the name of the variable in question.
Examples of the use of neighbour-location functions may be found
ALL function sets BOX In-Form object which fills the whole boundary box limited by PATCH command connected with current INFOB statement. Unlike other this function has not arguments and therefore brackets. See more
BOX(x0,y0,z0,xsize,ysize,zsize,alpha,beta,theta) function sets BOX In-Form object which lies in the boundary box limited by PATCH command connected with current INFOB statement. The position and size of the box are defined in its nine parameters. The syntax of BOX in more details can be found in section 6.4.b
SPHERE(xc,yc,zc,radius) function sets SPHERE In-Form object which lies in the boundary box limited by appropriate PATCH. The position and size of the sphere are defined in its four parameters. The syntax of SPHERE in more details is described in section 6.4.c
POINT(x,y,z,diam) function creates the point sub-grid object which lies in the boundary box limited by appropriate PATCH. The position and size of the point object are defined in its four parameters. The syntax of POINT in more details can be found in section 6.4.a
LINE(xf,yf,zf,xl,yl,zl,diam) function creates the line sub-grid object which lies in the boundary box limited by appropriate PATCH. The position and size of the line are defined in its seven parameters. The syntax of LINE in more details is described in section 6.4.a
It is exemplified in core library
The SUM() and SSUM() functions are used for summation of results of the formula calculation on all cells inside the area of which can be limited by Patch command connected with current In-Form statement.
The result of summation is a real number. Therefore as a rule the summation result is assigned to real user-defined variable connected with current In-Form statement and previously to described by '(make' In-form statement.
The SUM() function is operation of the global summation at all IZ slabs inside Patch region. Before each fulfillment of sum operation the sum is zeroized and accumulates results of summation on all iz-slabs.
The SSUM() function is operation of the slab summation at one current IZ-slab lying inside Patch region. At each iz-slab before performance of SSUM operation the sum is zeroized and accumulates result of summation at current iz-slabs only.
For example in 786 case the SUM() function is used for setting the bulk room temperature where TEM1 is temperature, VOL is cell volume and YVLAST & XULAST are y & x sizes of domain. The summation is executed at finish of each iz-slab calculation on all domain area and is assigned to user-defined variable TBUL.
(MAKE of TBUL is 0) (STORE1 TBUL is SUM(TEM1*VOL/(YVLAST*XULAST)) with ZSLFIN)
In 785 case the SUM() function is used for definition the sum of factors on which inlet mass fluxes should be multiplied. Here AEAST is east face area of calculation grid and (:PI:*:RAD1:^2) is real inlet area from task.
PATCH(PATCH1,INIVAL,1,1,1,NY,1,NZ,1,1) *** Primary inlet mass flux coefficient (MAKE PRIMF is 1.) (STORE1 PRIMF at PATCH1 is SUM(AEAST/(:PI:*:RAD1:^2)) w$ ith INFOB_1!IF(ISWEEP.LE.2)) *** Secondary inlet mass flux coefficient (MAKE SECNF is 1.) (STORE1 SECNF at PATCH1 is SUM(AEAST/(:PI:*(:RAD2:^2-:RAD1:^2))) w$ ith INFOB_2!IF(ISWEEP.LE.2))
Here the Patch command with PATCH1 name contained any IZ-slabs. If the Patch command contained one IZ-slab then it was possible to use for these purposes other function SSUM() as will be shown below .
In 781 case the SUM() function provide the re-calculation of reference residuals for G solved variable. The summation is executed on all domain area and is assigned to the PIL real array, RESREF.
(STORE1 of RESREF(G) is SUM(VOL*(GENG-2.*:RHO1:*EPKE*G)/(NY*NZ)))
In 345 case the SUM() function calculate the surface heat flux where TEM1 and TCOLD are temperatures at cell and cold wall accordingly.
WALL(COLD,EAST,NX,NX,1,NY,1,NZ,1,LSTEP) (STORED of QWAL at COLD is SUM(PART*(TEM1-TCOLD))/(NZ*NY) with IF(I$ SWEEP.EQ.LSWEEP))
The result of summation is assigned the QWAL stored variable which is used hereinafter calculation the bulk heat-transfer coefficient. However will more economically use for these purposes single user-defined variable.
In 362 case the SUM() function calculate the average temperature at each IZ-slab where ASUM and TSUM user-defined variables are sums at one IZ-slab of high cell face areas and the cell temperatures accordingly.
(MAKE TSUM is 0.) (MAKE ASUM is 0.) DO II=1,NZ ! ** Start of IZ cycle PATCH(PATCH:II:,CELL,1,NX,1,NY,:II:,:II:,1,1) ! One PATCH per slab ** Summation of HIGH area for each IZ slab (STORE1 ASUM at PATCH:II: is SUM(AHIGH)) ** Summation of temperature multiplied by HIGH area for each IZ slab (STORE1 TSUM at PATCH:II: is SUM(AHIGH*TEM1)) ** Determination of average temperature for each IZ slab and storage inside 3D variable TAVE (STORED TAVE at PATCH:II: is TSUM/ASUM) ENDDO ! End of DO loopThe calculations are executed within the limits of one IZ-slab of which set by Patch command with PATCH:II: name. The DO command of cycle is used for fulfillment of calculation in all domain area.
Example of SSUM() use for calculation the average temperature at each IZ-slab may be found in 363 case which is identical to 362.
PATCH(PATCH1,CELL,1,NX,1,NY,1,NZ,1,LSTEP) ! One PATCH per whole domain ** Summation of HIGH area for each IZ slab (STORE1 ASUM at PATCH1 is SSUM(AHIGH)) ** Summation of temperature multiplied by HIGH area for each IZ slab (STORE1 TSUM at PATCH1 is SSUM(AHIGH*TEM1)) ** Determination of average temperature for each IZ slab and storage inside 3D variable TSLB (STORED TAVE at PATCH1 is TSUM/ASUM)
The use of SSUM() function permits to avoid the creation iz-slab loop as in 362 case. Here the summation operations of are executed consistently for each iz-slab for calculation of the total area, total temperature multiplied by high area and average temperature.
AECO(), AWCO(), ANCO(), ASCO(), AHCO(), ALCO(), APCO() functions get coefficients of the finite-volume equation. See more.
Examples of the use may be found
COVAL(), which can used for linearized source setting in the (SOURCE statement. The functions has two arguments which in general case can be the formulas for calculation coefficient and value.
Examples of the use may be found in 737, 745, 746, 747, 774 and 789 core-library cases. In more details it will be discussed and exemplified in section 7.1 and section 7.6
POS(), OFFSET() which can used for mofor purposes in the (MOVOB In-Form statement.
POS(Xpos,Ypos,Zpos,Xang,Yang,Zang) function describes the coordinates of position of moving object. Its six parameters can be formulas. If they are functions of the TIM current time then the object will be moved during time steps.
Examples of the use may be found in 360, 365, 369, 370, 371, 372, 373, 376, 378, 379, 380, 381 and 382 core-library cases. More details see section 8 .
OFFSET(Xorigin,Yorigin,Zorigin) function declares the frames of reference of object-related coordinate systems. In general case its three parameters can be formulas also.
Examples of the use may be found in 381 and 382 core-library cases. See more
If no square or curly brackets follow the name of the variable, the value prevailing at the current cell is intended.
However neighbour-cell or more-distant-cell values may be referred to, either in terms of their indices, IX, IY, IZ, or of their geometric coordinates, x, y, z.
Square brackets are used for the former and curly brackets for the latter, in accordance with the following conventions:
A core-library example which makes extensive use of indexing is case 759, where it is used for the creation of the pressure-gradient sources which are needed for the solution of the 'collocated-velocities' equations.
Another is case 758, where it is used for the creation of an initial-value field on one slab by the superposition of the initial-value fields on two lower slabs.
Another example is case 710, where indexing is used to enable the flow of tube-side fluid to be simulated for a shell-and-tube heat exchanger.
Relative indices are used in case 368, as a substitute for the 'neighbour-patch' technique which had been employed in an earlier PLANT-based solution of the same problem.
Use of curly brackets in the formulas after the variable name effects this interpolation domain.
The curly brackets, like the square ones, are placed after the variable
name in the formula. They are intended for the description
of x, y and z coordinates of the point inside the domain and consequently
should not exceed the domain sizes. The coordinates are separated by &
symbols.
In one- or two-dimensional problems, the coordinate appropriate to the missing dimension(s) may be omitted.
The core-library case v152 sets the x and y coordinates of the temperature sensor to 0.05 m. by means of the specification:TEM1{0.05,0.05}.
All operands, used in In-Form formulas, listed in alphabetical order in Appendix 4.
This permits cases to be selected which exemplify the use of In-Form in combination with selected other PHOENICS features.
The variable XRAT can be set for each z-location. An example is:
(XGRID of XRAT is 1.+:POWER:*DZ/(ZWADD+ZZW))
Likewise, YRAT can be specified, for example as in case 777 as follows:
(YGRID of YRAT is 1.+:POWER:*DZ/(ZWADD+ZZW) with IF(IZ.LE ..20.OR.IZ.GT.40))
Finally, In-Form can specify the forward step, DZ, as for example in case 776:
(ZGRID of DZ is 0.1*YVLAST with IF(IZ.LE.2))
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.
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, of which the user is at present allowed up to eight in a given flow simulation, are actually created,
(INFOB at PATCHNAME is Formula with INFOB_N)
Here:
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 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.
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.
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.
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.
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.
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.
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.
(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.
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.