The Q1 file is an ASCII text file which the PHOENICS data-input module SATELLITE must read before it can do anything else, being told first of all whether to operate in the batch or interactive mode, and then how many runs to make (see PHOENICS Encyclopaedia entry: RUN).
Its primary position in the PHOENICS-module system is shown here:
The present article is therefore 'required reading' for the user of PHOENICS who wishes to master the mechanisms of data input.
It is true that the Satellite, in VR-Editor mode, not only reads a Q1 but helps a users to write one. Therefore users who do not wish to 'master the mechanisms' need never even look at a Q1, let alone learn any thing about the PHOENICS Input Language in which it is written. But there are some things which the Editor cannot do for them, such as extract only the significant-for-purpose data items from all those with which it has been supplied; and this can have serious excessive-computer-time implications.
The minimum Q1 contains at least two lines, of which the first is typically:
TALK=T;RUN(1,1)or:
TALK=F;RUN(1,1)and the second is:
STOPTALK=T tells SATELLITE to "converse" with the user, i.e. to start an interactive session.
TALK=F tells SATELLLITE not to converse, but simply to process whatever other commands it finds in the Q1, and then stop. (T and F mean TRUE and FALSE respectively in PIL).
RUN(1,1) instructs SATELLITE to stop at the first STOP line. (RUN(1,10) would mean: "Don't stop reading until you've reached the 10th STOP".
PHOENICS is supplied with model Q1, which resides in folder /phoenics/d_satell, as a reminder of what input data need typically to be introduced.
Its content is as follows:
TALK=T;RUN(1,1)
GROUP 1. Run title and other preliminaries
GROUP 2. Transience; time-step specification
GROUP 3. X-direction grid specification
GROUP 4. Y-direction grid specification
GROUP 5. Z-direction grid specification
GROUP 6. Body-fitted coordinates or grid distortion
GROUP 7. Variables stored, solved & named
GROUP 8. Terms (in differential equations) & devices
GROUP 9. Properties of the medium (or media)
GROUP 10. Inter-phase-transfer processes and properties
GROUP 11. Initialization of variable or porosity fields
GROUP 12. Patchwise adjustment of terms (in differential equations)
GROUP 13. Boundary conditions and special sources
GROUP 14. Downstream pressure for PARAB=.TRUE.
GROUP 15. Termination of sweeps
GROUP 16. Termination of iterations
GROUP 17. Under-relaxation devices
GROUP 18. Limits on variables or increments to them
GROUP 19. Data communicated by satellite to GROUND
GROUP 20. Preliminary print-out
GROUP 21. Print-out of variables
GROUP 22. Spot-value print-out
GROUP 23. Field print-out and plot control
GROUP 24. Dumps for restarts
STOP
The 24 lines between the first and the last are the names of the groups of data items which SATELLITE understands. (See GROUP, for systematically-arranged information about these.)
Because these lines start in the fifth column, they are treated by the Satelllite as comments which may be ignored; whereas TALK and STOP start in the first column and are therefore acted upon.
SATELLITE responds only to statements on lines of which the first two
characters are NOT
blank, treating all others as comments.
So the T of TALK and the S of STOP, for example,
must lie in column 1 or column 2 in order to take effect.
Further points of note are:
The lines which SATELLITE does take notice of are those which, as well as starting in one of the first two columns, are written in PIL, the PHOENICS Input Language.
The richest source of Q1 files available to the user of Encylopaedia is the PHOENICS Input-File Library, which can best be inspected by clicking here.
Core-library case 116 will be chosen as a typical example, about which the following remarks can be made:
These are commands which, while being ignored by Satellite, are meaningful to the graphical-display packages PHOTON and VIEWER. They constitute a macro which it is useful to include in the Q1 file which generates the calculations, of which the macro is to display the results.
These are displayed on the screen in an interactive session so as to convey to the user what is the nature of the simulation.
There follow other Group entries on which there is no need to comment for present purposes.
CHAM strives still to make PHOENICS the CFD code of choice for ambitious innovators.
This was indeed written in an interesting way (admittedly unseen by its users); for PIL was the language in which it was written,
Acceptable lines in a Q1 file are usually introduced in one of five ways, listed here and explained in more detail immediately thereafter:
TALK=T;RUN( 1, 1)
DISPLAY
Simulation of heat conduction in a steel slab of 0.1 m thickness,
internallly heated by 1. kW/m**3 of electric power, with both its
faces held to 0.0 deg Celsius
ENDDIS
NX=100 ! Dividing the x dimension into 100 elements
XULAST=0.1 ! The thickness of the slab
GRDPWR(X,NX,XULAST,1.0) ! To create a uniform grid, namely one with
! a power-law distribution, the exponent
! being 1.0
SOLVE(TEM1) ! To solve for temperature
STORE(PRPS) ! To be able to set material properties via PROPS file
STORE(KOND) ! To be able to print and check thermal conductivity
FIINIT(PRPS)=STEEL ! To require properties of steel to be used
PATCH(minXface,WEST,1,1,1,1,1,1,1,1) ! To locate the low-x face
PATCH(maxXface,WEST,NX,NX,1,1,1,1,1,1) ! To locate the high-x face
COVAL(minXface,TEM1,FIXVAL,0.0) ! To fix the values of both faces
COVAL(maxXface,TEM1,FIXVAL,0.0) ! to zero
PATCH(HEATER,volume,1,nx,1,1,1,1,1,1) ! To show that the volumetric
! heat flux extends from low x to high, i.e. from 1 to nx
COVAL(HEATER,TEM1,FIXFLU,1.e3) ! To fix the heat flux 1kW/m**3
STOP
These few lines are sufficient to enable:
For those however who prefer to work via the PHOENICS SATELLITE module in interactive mode, it should be said that the same effect can be achieved by clicking 'run' at the top of the screen seen here:
and then choosing 'pre-processor', 'text-mode (Satellite)' and Talk=F' from the successive drop-down menus.
The user needed to type only few lines because all PIL variables are supplied with 'default' values, which they retain unless the user sets new values. Thus the PIL variable LSWEEP, which specifies the last 'sweep' (i.e. outer iteration) which the solver should execute, is by default 1 .
The user was probably content to set no value for LSWEEP because he knew that, for this linear heat-conduction problem, a single sweep should suffice.
The computed temperature values in RESULT are as follows, in which it is seen that the values at only 5 x-locations are printed (because the user did not over-write the default print-control commands):
Field Values of TEM1
2.500E-09 1.837E-02 2.744E-02 2.721E-02 1.767E-02
IX= 1 21 41 61 81
Nett source of TEM1 at patch named: HEATER = 1.000001E+02which, since the default dimensions of the domain in the y- and z-directions are both 1.0 m, corresponds to the specified heat input of 1 kW/m**3 . But are the other temperatures correct?
The user can answer this question by laboriously calculating by hand the ordinates of the parabolic temperature profile which represents the exact solution to the differential equation. But this is not necessary; for PHOENICS can be told to make the comparison itself.
This is done by introducing into the q1 file, the additional lines shown below in red:
SOLVE(TEM1) ! To solve for temperature
STORE(PRPS) ! To be able to set material properties via PROPS file
STORE(KOND) ! To be able to check the thermal conductivity
! To enable the correctness of the calculated values
! of temperature to be checked act, as follows:
CHAR(FORMULA) ! Declare the character variable FORMULA, and set it
! to the temperature calculated by PHOENICS, TEM1,
! divided by the theoretical temperature: namely,
! thus:
FORMULA=TEM1/(0.5*1.E3*(XG-.005*:XULAST:)*(.995*:XULAST:-XG)/43.0)
! where
! 0.5 is a constant in the theoretical expression for
! the parabolic profile,
! 1.E3 is the volumetric heat input,
! xg = x value of any grid point,
! .005*:xulast: = xg of first grid point,
! .995*:xulast: = xg of last grid point,
! 43.0 is thermal conductivity of steel in PROPS file
(STORED var #RAT is :FORMULA:) ! Calculates the temperature ratio
(LONGNAME of #RAT print as tem1/theoretical_temperature)
These lines are designed to calculate and print the ratio of the temperature computed by PHOENICS to the analytically-derived temperature; and it is of course to be expected that the ratio is everywhere close to unity.Only four of these lines are active, and therefore essential; the remainder are explanatory comments, introduced so as to bring to the attention of the present reader the existence of an easy-to-implement accuracy-checking feature, which makes use of the unique-to-PHOENICS In-Form facility.
The consequential RESULT file now contains the following new lines, in which it is seen that #RAT is indeed printed as unity everywhere except at IX=1. There, the very large departure from unity is without significance; it reflects the 2.5E-9 value of TEM1 computed there, divided by the even lower theoretical value, 0.0, to which 1.e-20 has been added to prevent a 'division-by-zero' Fortran error.
Field Values of #RAT: tem1/theoretical_temperature
2.500E+11 1.0 1.0 1.0 1.0
IX= 1 21 41 61 81
Field Values of KOND
IY= 1 4.300E+01 4.300E+01 4.300E+01 4.300E+01 4.300E+01
IX= 1 21 41 61 81
Field Values of PRPS
1.110E+02 1.110E+02 1.110E+02 1.110E+02 1.110E+02
IX= 1 21 41 61 81
Field Values of TEM1
2.500E-09 1.837E-02 2.744E-02 2.721E-02 1.767E-02
IX= 1 21 41 61 81
It can thus be concluded that the PHOENICS solution is indeed satisfactory.
PATCH(TEM1PLOT,PROFIL,1,NX,1,1,1,1,1,1) COVAL(TEM1PLOT,TEM1,0.0,0.0) ORSIZ=0.2enables the profile to be displayed by means of a line-printer plot, thus:
PATCH(TEM1PLOT,PROFIL, 1, 100, 1, 1, 1, 1, 1, 1)
PLOT(TEM1PLOT,TEM1, 0.000E+00, 0.000E+00)
Variable 1 = TEM1
Minval= 2.500E-09
Maxval= 2.849E-02
Cellav= 1.880E-02
1.00 +....+....+....+....11111111111....+....+....+....+
0.90 + 1111 1111 +
0.80 + 111 111 +
0.70 + 11 11 +
0.60 + 11 11 +
0.50 + 11 11 +
0.40 + 11 11 +
0.30 + 11 11 +
0.20 + 11 11 +
0.10 +11 11+
0.00 11...+....+....+....+....+....+....+....+....+...11
0 .1 .2 .3 .4 .5 .6 .7 .8 .9 1.0
the abscissa is X . min= 5.00E-04 max= 9.95E-02
Such plots are not elegant; but, because they are so easily generated and often give the information which the user needs, they are not to be despised.
PIL allows the declaration of new variables as characters, reals, integers and logicals. [It calls the latter 'booleans'.] The second of these is illustrated in the following modificaction of the first-shown Q1 file, in which the new features are again indicated by the red colour as follows:
TALK=F;RUN(1,1)
REAL(THICK,HEATINPT) ! Declaration of new variables
THICK=1.0 ! Setting their values
HEATINPT=0.01
NX=100 ! dividing the x dimension into 100 elements
! the thickness of the block = THICK
GRDPWR(X,NX,THICK,1.0) ! to create a uniform grid, namely one with
a power-law distribution, the exponent
being 1.0
SOLVE(TEM1) ! to solve for temperature
PATCH(minXface,WEST,1,1,1,1,1,1,1,1) ! to locate the low-x face
PATCH(maxXface,WEST,NX,NX,1,1,1,1,1,1) ! to locate the high-x face
COVAL(minXface,TEM1,FIXVAL,0.0) ! to fix the values of both faces
COVAL(maxXface,TEM1,FIXVAL,0.0) ! to zero
PATCH(HEATER,volume,1,nx,1,1,1,1,1,1) ! to show that the volumetric
! heat flux extends from low x to high
COVAL(HEATER,TEM1,FIXFLU,HEATINPT) ! to fix the heat flux to HEATFLUX
STOP
Here the parameters THICK and HEATINPT were introduced
and set at the top of the file; and they were used lower down.The computed results will of course of course be the same as before.
As will be seen below, the VR-Editor also treats the two q1s as identical; which (for reasons to be explained) is less desirable.
If the user sets TALK=T in the first line of his Q1, the PHOENICS
satellite responds to the command RUNSAT by presenting the
screen shown here.
Pressing the F2 key leads to the next screen, which permits the
interaction to begin:
The user can now make keyboard entries and read responses on the screen.
For example, if the user understands that the variable steel is recognised by the PHOENICS Satellite module as an integer and wishes to know its value, he may type 'steel' on the screen (case being unimportant) and will at once see:
Should the user then wish to to confirm that his selection of that material is conveyed to the solver by the setting of the value of the variable
FIINIT(PRPS), entering 'fiinit(prps)' at the keyboard will elicit:
:
Suppose now that the user wishes to replace steel by copper, first establishing which integer to use. Then entering 'copper' at the keyboard will reveal:
So as to make the change, the user should then type
'fiinit(prps)=copper'
(or fiinit(prps)=103), and will see on the screen:
If the interactive session is now closed by pressing the F7 key, and the resulting Q1 file is inspected in any editor, it will be found that its last few lines are now as follows, showing that, as is true of all such interactions, new instructions are added to the bottom of the file:
FIINIT(PRPS)=STEEL ! To require properties of steel to be used
PATCH(minXface,WEST,1,1,1,1,1,1,1,1) ! to locate the low-x face
PATCH(maxXface,WEST,NX,NX,1,1,1,1,1,1) ! to locate the high-x face
COVAL(minXface,TEM1,FIXVAL,0.0) ! to fix the values of both faces
COVAL(maxXface,TEM1,FIXVAL,0.0) ! to zero
PATCH(HEATER,volume,1,nx,1,1,1,1,1,1) ! to show that the volumetric
! heat flux extends from low x to high, i.e. from 1 to nx
COVAL(HEATER,TEM1,FIXFLU,1.e3) ! to fix the heat flux 1kW/m**3
FIINIT(PRPS)=COPPER
STOP
If now the solver is run, by way of the command RUNEAR, it will be found that the RESULT file now contains the lines:
Flow field at ITHYD= 1, IZ= 1, ISWEEP= 1, ISTEP= 1
Field Values of KOND
3.810E+02 3.810E+02 3.810E+02 3.810E+02 3.810E+02
IX= 1 21 41 61 81
Field Values of PRPS
1.030E+02 1.030E+02 1.030E+02 1.030E+02 1.030E+02
IX= 1 21 41 61 81
Field Values of TEM1
2.500E-09 2.073E-03 3.097E-03 3.071E-03 1.995E-03
IX= 1 21 41 61 81
They show that the increase in thermal conductivity, to 381.0 from 43.0, has produced a proportionat reduction in temperature, as is to be expected (the heat input having been left unchanged).
COVAL(HEATER,TEM1,FIXFLU,1.e4)This line would then appear at the bottom of the screen; and, since Satellite reads and interprets lines in the Q1 from top to bottom, would over-ride the higher-up line.
However, invocation of the Satellite's built-in editor enables the higher-up line to be edited directly.
Thus, entering lb (meaning 'list from the bottom') in interactive mode
elicits the screen shown here,
Evidently the line to be changed is number 76.
The built-in editor has no 'replace' command; therefore the user must type d76 so as to delete the line, followed by:
i75
RETURN
COVAL(HEATER,TEM1,FIXFLU,1.e4)
RETURN
RETURN
Typing lb again will show that line 76 has indeed been replaced in the
desired manner;
and, when the solver is run again, the temperatures will be
found to have increased ten-fold as expected.
The built-in text editor is somewhat primitive, as has been admitted; but it has one advantage over a text editor: it edits not the q1 but the internal-to-satellite 'instruction stack'. It can therefore see, and allow the user to change, instructions which the satellite reads by default before it reads the Q1.
What these instructions are can be seen by issuing successively the commands: L1-15, L16-30, L30-45, etcetera so as to list them all, fifteen lines at a time.
The interested reader is free to study these; but no further comments will be made here.
This editor is intended to assist users who are not conversant with PIL to write Q1 files for them; and indeed it does so. However, in the course of time, it has acquired the propensity to do much more.
Specifically, when supplied with a user-written Q1 file and nothing more, it re-writes it, in its own 'dialect' of PIL, with both advantages and disadvantages, some of which will now be discussed.
Let the Q1 which it reads be the first text-edited Q1 which was discussed above.
First it is instructive to look at the Q1 which the VR-Editor writes when it is simply opened and closed, without the user's having made any modification to the data whatsoever. It is shown here, with interspersed comments in brown font, explaining its differences, from the Q1 described above, with which the VR-Editor started.
TALK=T;RUN( 1, 1) ************************************************************ Q1 created by VDI menu, Version 2008, Date 06/11/08 CPVNAM=VDI;SPPNAM=CoreThese are defaults of the VR-Editor (referred to as VRE from now on.)
For present purposes, there is no need to comment on every item. Readers who are interested in disregarded items, such as CPVNAM, can find explanations in the PHOENICS Encyclopaedia.
************************************************************ Echo DISPLAY / USE settings DISPLAY Simulation of heat conduction in a steel slab of 0.1 m thickness, internallly heated by 1. kW/m**3 of electric power, with both its faces held to 0.0 deg Celsius ENDDIS ************************************************************ IRUNN = 1 ;LIBREF = 0 ************************************************************ Group 1. Run Title TEXT(No title has been set for this run. ) ************************************************************ Group 2. Transience STEADY = TThe human editor knew that steady flow is the default, and therefore made no mention of the logical variable STEADY; but VRE is here seen to be more punctilious.
************************************************************
Groups 3, 4, 5 Grid Information
* Overall number of cells, RSET(M,NX,NY,NZ,tolerance)
RSET(M,100,1,1,1.000000E-05)
This is an example of VRE's dialect
of PIL.It should be noted however that neither XULAST nor THICK appear, either explicitly or implicitly. VRE prefers numbers to characters.
It may also be noticed that VRE is not economical in its printing practices. We humans might find 1.E-5 sufficient; but VRE prints 1.000000E-05 .
************************************************************
Group 6. Body-Fitted coordinates
************************************************************
Group 7. Variables: STOREd,SOLVEd,NAMEd
ONEPHS = T
* Non-default variable names
NAME(148) =KOND ; NAME(149) =PRPS
NAME(150) =TEM1
* Solved variables list
SOLVE(TEM1)
* Stored variables list
STORE(PRPS,KOND)
H.E. did not need to say that this was a (default) one-phase phenomenon;
and H.E. did not care into which member ot the NAME array TEM1 was
placed.
************************************************************
Group 8. Terms and Devices
************************************************************
Group 9. Properties
* Domain material index is 111 signifying:
* STEEL at 27 deg c (C = 1%)
SETPRPS(1,111)
ENUT = 0.000000E+00
DRH1DP = 5.000000E-12
DVO1DT = 3.700000E-06
PRNDTL(TEM1) = -4.300000E+01
Here the VR-Editor has used the commandOnce again, VRE uses the harder-to-read long form rather than the briefer equivalent:
ENUT = 0. DRH1DP = 5.E-12 DVO1DT = 3.7E-06 PRNDTL(TEM1) = -4.3E+01
************************************************************ Group 10.Inter-Phase Transfer Processes ************************************************************ Group 11.Initialise Var/Porosity Fields FIINIT(KOND) = 1.001000E-10 ;FIINIT(PRPS) = -1.000000E+02 FIINIT(TEM1) = 1.001000E-10 No PATCHes used for this Group INIADD = F ************************************************************ Group 12. Convection and diffusion adjustments No PATCHes used for this Group ************************************************************ Group 13. Boundary and Special Sources PATCH (MINXFACE,WEST ,1,0,0,0,0,0,1,1) COVAL (MINXFACE,TEM1, FIXVAL , 0.000000E+00) PATCH (MAXXFACE,WEST ,2,0,0,0,0,0,1,1) COVAL (MAXXFACE,TEM1, FIXVAL , 0.000000E+00) PATCH (HEATER ,VOLUME,0,0,0,0,0,0,1,1) COVAL (HEATER ,TEM1, FIXFLU , 1.000000E+03)Here is something interesting: the indicial arguments of the PATCH command are different from those in the original Q1. This will be explained below.
EGWF = T
************************************************************
Group 14. Downstream Pressure For PARAB
************************************************************
Group 15. Terminate Sweeps
LSWEEP = 1
RESFAC = 1.000000E-03
************************************************************
Group 16. Terminate Iterations
************************************************************
Group 17. Relaxation
************************************************************
Group 18. Limits
************************************************************
Group 19. EARTH Calls To GROUND Station
************************************************************
Group 20. Preliminary Printout
************************************************************
Group 21. Print-out of Variables
************************************************************
Group 22. Monitor Print-Out
NPRMON = 100000
NPRMNT = 1
************************************************************
Group 23.Field Print-Out and Plot Control
NPRINT = 100000
ISWPRF = 1 ;ISWPRL = 100000
No PATCHes used for this Group
************************************************************
Group 24. Dumps For Restarts
Now begin some VRE-only settings. GVIEW has no counterpart in the
original Q1, which was not concerned, as GVIEW is, with displaying the domain, grid and objects visually on the computer screen.
GVIEW(P,0.000000E+00,1.000000E+00,0.000000E+00) GVIEW(UP,1.000000E+00,0.000000E+00,0.000000E+00) > DOM, SIZE, 1.000000E-01, 1.000000E+00, 1.000000E+00The first 1.000000E+00 of SIZE ( of DOM, the domain) is the XULAST set by the user in his Q1, of which the 'block' occupies the whole of the domain. The other two are the default values of YVLAST and ZWLAST.
Of course, the line would be easier to inderstand, and equally acceptable to the SATELLITE, if it were printed as :
> DOM, SIZE, XULAST, YVLAST, ZWLAST
> DOM, SCALE, 1.000000E+00, 1.000000E+00, 1.000000E+00 > DOM, INCREMENT, 1.000000E-02, 1.000000E-02, 1.000000E-02 > GRID, BOUNDS, F F F F F F > GRID, RSET_X_1, 99, 1.000000E+00 > GRID, RSET_X_2, 1, 1.000000E+00Above is seen the way in which the VR-editor thinks of the 100-interval set by H.E., namely as 99 plus 1.
> GRID, RSET_Y_1, 1, 1.000000E+00 > GRID, RSET_Z_1, 1, 1.000000E+00Below it appears that the low-x and high-x patches which H.E. inserted have been converted into Virtual-Reality objects.
> OBJ, NAME, MINXFACE > OBJ, POSITION, 0.000000E+00, 0.000000E+00, 0.000000E+00 > OBJ, SIZE, 0.000000E+00, 1.000000E+00, 1.000000E+00 > OBJ, GEOMETRY, default > OBJ, ROTATION24, 1 > OBJ, TYPE, USER_DEFINED > OBJ, NAME, MAXXFACE > OBJ, POSITION, 9.900000E-02, 0.000000E+00, 0.000000E+00 > OBJ, SIZE, 0.000000E+00, 1.000000E+00, 1.000000E+00 > OBJ, GEOMETRY, default > OBJ, ROTATION24, 1 > OBJ, TYPE, USER_DEFINED STOPwithout changing the relative geometrical positions of the physically-important physical features.
Nevertheless, it can be disconcerting; for, unless certain precautions are taken, the re-writing of the Q1 can involve loss of some important information which H.E. has supplied.
How this comes about is reported, at length,
here.The Q1 which the VR-editor creates as output, replacing and leaving no back-up of the one which it read, has no do-loop. Instead the implications of the initial do-loop are expressed thus:
> OBJ, NAME, HPOR1 > OBJ, POSITION, 0.000000E+00, 0.000000E+00, 2.200000E+00 > OBJ, SIZE, 1.000000E+00, 5.000000E-02, 3.400000E+00 > OBJ, GEOMETRY, cube14 > OBJ, ROTATION24, 1 > OBJ, TYPE, BLOCKAGE > OBJ, MATERIAL, 199,Solid allowing fluid-slip at walls > OBJ, NAME, HPOR2 > OBJ, POSITION, 0.000000E+00, 5.000000E-02, 2.600000E+00 > OBJ, SIZE, 1.000000E+00, 5.000000E-02, 2.600000E+00 > OBJ, GEOMETRY, cube14 > OBJ, ROTATION24, 1 > OBJ, TYPE, BLOCKAGE > OBJ, MATERIAL, 199,Solid allowing fluid-slip at walls > OBJ, NAME, HPOR3 > OBJ, POSITION, 0.000000E+00, 1.000000E-01, 3.000000E+00 > OBJ, SIZE, 1.000000E+00, 5.000000E-02, 1.800000E+00 > OBJ, GEOMETRY, cube14 > OBJ, ROTATION24, 1 > OBJ, TYPE, BLOCKAGE > OBJ, MATERIAL, 199,Solid allowing fluid-slip at walls > OBJ, NAME, HPOR4 > OBJ, POSITION, 0.000000E+00, 1.500000E-01, 3.400000E+00 > OBJ, SIZE, 1.000000E+00, 5.000001E-02, 9.999998E-01 > OBJ, GEOMETRY, cube14 > OBJ, ROTATION24, 1 > OBJ, TYPE, BLOCKAGE > OBJ, MATERIAL, 199,Solid allowing fluid-slip at walls > OBJ, NAME, HPOR5 > OBJ, POSITION, 0.000000E+00, 2.000000E-01, 3.800000E+00 > OBJ, SIZE, 1.000000E+00, 4.999997E-02, 1.999998E-01 > OBJ, GEOMETRY, cube14 > OBJ, ROTATION24, 1 > OBJ, TYPE, BLOCKAGE > OBJ, MATERIAL, 199,Solid allowing fluid-slip at wallsThese statements are very different in form from those of the original Q1; and indeed 'porosity' makes no appearance. Instead, the same fluid-flow-blocking effect achieved by the formerly-specified field of porosity is here effected by introduction of 'objects', to which the the Editor has automatically assigned the names HPOR1 etc.
Further, the positions of these objects are specified in terms of geometrical distances rather than by reference to grid indices. This has the advantage that they will retain their positions and sizes in space even though the fineness of the grid is increased.
However, how the porosity was at first defined has been lost sight of.
This loss is sometimes serious.
A much fuller account of Q1s written by the VR-Editor can be found in the relevant section of TR326, accessed by clicking here.