Get documents about "In-Form the INput of data via FORMulae
Document Sample
In-Form In-Form
the INput of data via FORMulae
However hard they try, creators of CFD codes can
never foresee all the processes which their users
PHOENICS User Meeting,
will want to simulate; for users are humans. They
think of things never thought of before.
But code creators can provide the tools
Paris, 2008
and instruments which creative
thinkers require.
In-Form is a both a constructional tool and an investigative
Instrument, with which PHOENICS was first equipped in 2001
and which is still being extensively developed.
It represents the third stage in the process of enabling users
to extend the simulation capability of PHOENICS in any
direction they choose..
In-Form‟s predecessors In-Form
The previous two stages were:
1. User programming, (1981) enabling users to add Fortran
PHOENICS User Meeting,
sub-routines written by themselves.
This facility is still available and used; but it requires a re-
compilable version of PHOENICS.
Paris, 2008
2. PLANT, (1998) which created the Fortran automatically upon
the basis of formulae provided by the user. This, too,
necessitates having a re-compilable version.
In-Form is also formula-based; but no new Fortran is written;
nor is any re-compilation needed.
Yes, time must be watched. And In-Form uses
less, both of computers and humans; yet it
does all that PLANT could do, and more.
For what In-Form can be used
(Examples will be supplied later) In-Form
In-Form has very many uses, of which some are:
1. creating initial-value distributions;
PHOENICS User Meeting,
2. introducing non-linear boundary conditions and sources;
3. defining material properties in accordance with whatever
formulae the user wishes;
Paris, 2008
4. computing exact-solution values for comparison with those
which PHOENICS produces;
5. defining how objects move in time through space;
6. defining, computing and printing new variables;
7. adjusting diffusion, convection and source terms locally;
8. creating ‘transfer’ and ‘list’ objects;
9. eliciting details of inner workings of PHOENICS for diagnosis.
How In-Form works In-Form
1. In-Form is activated by statements placed by the user in the
Q1 (input) file in accordance with a special syntax.
PHOENICS User Meeting,
That is all that the user has to do; and even this labour can be
reduced if PRELUDE is employed (of which more later).
Paris, 2008
2. The statements are then read by the PHOENICS Satellite,
which writes their equivalents into the EARDAT file for reading
by the PHOENICS solver ( EARTH).
3. The solver, on first reading EARDAT, rapidly parses the
character strings. It then writes instructions (to itself) which
cause it to perform the appropriate computations.
No significant computer-time increase has ever been detected
as compared with user- programming or PLANT processing.
Examples of the use of In-Form: In-Form
1. the shell-and tube heat-exchanger
PHOENICS Input-File library case 800 represents a shell-and-
tube heat exchanger, cooling hot engine oil by cold water.
PHOENICS User Meeting,
In-Form is used to calculate the temperature-dependent
properties at each location for the shell- and tube-side fluids.
The temperatures vary considerably, as shown here, for the
Paris, 2008
shell-side fluid and the tube-side fluid
Shell-side fluid (water) flows from left to right; tube-side fluid (oil)
from right to left. The contours for the central plane are shown.
The shell-and tube heat-exchanger;
fluid viscosities In-Form
In-Form is used to compute material properties, by extracting
formulae from the PHOENICS library. Thus, for the kinematic
PHOENICS User Meeting,
viscosity of water, the lines to be copied into the Q1 file are:
rho_expression=POL5(tems,2446.,-20.6741,.11576,-3.12895e-4,
4.0505E-7,-2.054E-10)
emu_expression=1.e-7*exp((1.12646-.039638*tems) /
Paris, 2008
(1.-7.29769E-3*tems))
(property rho1 is :rho_expression:)
(property enul is :emu_expression:/(rho1))
wherein:
tems stands for shell-side temperature,
POL5() indicates that In-Form can handle 5th-order polynomials,
exp() indicates that it can use the exponential function.
(property rho1 …sets the density everywhere,
(property enul … sets the kinematic viscosity.
Corresponding lines must be copied in for the engine oil.
The shell-and tube heat-exchanger; In-Form
fluid viscosities and Prandtl numbers.
The corresponding computed
fields of (for example) oil
viscosity are shown here.
PHOENICS User Meeting,
Conventional heat-exchanger-
design program presume, by
the way, all material
Paris, 2008
properties are uniform.
Thermal conductivities and specific heats are similarly
computed; and from them Prandtl (prs) and Reynolds (reys)
numbers are computed. The appropriate In-Form statements are:
(stored var reys is diam*vabs/enul)
(stored var prns is cps*rho1*enul/cond)
wherein:
diam= tube diameter, vabs=local absolute velocity,
cps=shell-side specific heat and cond=conductivity
This is all the user has to do. PHOENICS reads, and understands.
Nusselt numbers deduced from In-Form
empirical formulae
Where, the heat-transfer specialist should be asking, will the
empirical Nusselt/Reynolds/Prandtl number formulae appear?
We need these for the heat-transfer coefficients.
PHOENICS User Meeting,
Answer: In the Q1, in accordance with the user’s choice.
Here are examples, for shell- and tube-side Nusselt numbers:
(stored var nuss is 0.2*reys^0.6*prns^0.33)
Paris, 2008
(stored var nust is max(2.0,0.328*(reyt*prnt)^0.33))
Please note the In-Form convention: ^ indicates exponentiation;
so these expressions are of familiar power-law form; but this
user has decided that nust should never be less than 2.0.
Wide place-to-place variations are to be seen here.
Shell-side, tube-side and overall
heat-transfer coefficients
In-Form
What follows is obvious: deduce the
coefficients from the Nusselt Numbers Here are the results:
PHOENICS User Meeting,
via further In-Form statements, viz:
(stored var coes is areadvol*
nuss*cond/diam)
Paris, 2008
(stored var coet is areadvol* shell-side
nust*cont/diam)
(stored var coeu is coes*
coet/(coes+coet))
tube-side
wherein:
areadvol is area divided by volume,
coes, coet and coeu
are the three coefficients, etc.
Recall: all this from Q1 statements alone! overall
Assistance with the understanding of In-Form
print-out: In-Form‟s longname feature
Before leaving case 800, note the following In-Form statements:
(longname of hs print as shell-side_fluid_enthalpy)
PHOENICS User Meeting,
(longname of tems print as shell-side_fluid_temperature)
(longname of rho1 print as shell-side_fluid_density)
(longname of cps print as shell-side_fluid_specific_heat)
Paris, 2008
The longnames are what is printed in the RESULT file; so there
is no need to remember the abbreviations used in the Q1.
This is just one of many items which In-Form provides for the
user‟s convenience.
More could be provided. Users‟ suggestions are welcome.
In-Form can describe the motion of In-Form
objects
A useful feature of PHOENCS
is MOFOR (= Moving Frames
PHOENICS User Meeting,
of Reference), which permits
Simulation of relatively
moving objects and grids.
Paris, 2008
When MOFOR was first
introduced, the motion had to
be described by way of the
long, and not-easy-to-create,
MOF file.
Now, however, In-Form can
be used for specifying any
motion which obeys
mathematical relationships.
An example: library case 766; In-Form
a parabolic trajectory
The animated picture shows the
velocity vectors caused by a
PHOENICS User Meeting,
body moving in a two-
dimensional fluid-filled space.
The motion is activated by way of
PIL declarations followed by a few
Paris, 2008
In-Form lines in the Q1, as follows:
SAVE13BEGIN
char(xce,yce,zce,radius,usour,vsour,gravt)
char(vel,times);
gravt=9.81; vel=14.14;times=tim
xce=0.5+:times:*:vel:/1.414; zce=.05; radius=.5
yce=0.5+:times:*:vel:/1.414-0.5*:gravt:*:times:^2
Velocity, time and the gravitational acceleration 9.81 are easily
recognised here; xce, yce and zce are coordinates of the body
An example: library case 766; In-Form
a parabolic trajectory (continued)
That is not all; one still has to
define what moves, and ensure
PHOENICS User Meeting,
that its motion is imparted to
the fluid.
The first is achieved by declaring
the existence of an ‘in-form
Paris, 2008
object’ of spherical shape, thus:
PATCH(PATCH1,CELL,1,NX,1,NY,1,NZ,1,LSTEP)
INFOB at PATCH1 is SPHERE(:xce:,:yce:,:zce:,:radius:) with
OB_1)
The PATCH arguments allow the sphere to travel anywhere; and
the SPHERE function has coordinates and radius as arguments
The previous slide showed xce linear with time and yce quadratic.
Hence the parabolic trajectory.
An example: library case 766;
a parabolic trajectory (continued)
In-Form
How ensure that its motion is
imparted to the fluid?
By way of In-Form source
PHOENICS User Meeting,
statements, one for horizontal
velocity u1, and the other for
vertical velocity v1.
Paris, 2008
usour and vsour have already
been declared; now is the time to
give them meaning, as follows:
usour=:vel:/1.414
vsour=:vel:/1.414-:gravt:*:times:
(SOURCE of U1 at PATCH1 is :usour: with OB_1!FIXV)
(SOURCE of V1 at PATCH1 is :vsour: with OB_1!FIXV)
This is „In-Form speak‟ for: “wherever object OB_1 (i.e. the
sphere) finds itself in PATCH1, fix the values of the velocity
components of the fluid to be those of the sphere”.
An example: library case 766;
a parabolic trajectory (concluded)
In-Form
“But that‟s so difficult”, some
may say. ”Why can‟t the VR-
Editor enable me to set up the
PHOENICS User Meeting,
problem by way of dialogue
boxes?”
The answer is that it could be
Paris, 2008
programmed to do so; but only for
particular trajectories.
But remember Rodin‟s PHOENICS
user. Nevertheless, PHOENICS
Whatever does now have a user
PHOENICS interface which assists
supplies, its with the input of In-Form
thoughtful users sources, as will now be
will think of illustrated. It is called
something else. PRELUDE.
In-Form sources written by PRELUDE:
a source of vertical velocity caused by In-Form
buoyancy
The picture shows what a user
might see when using
PHOENICS User Meeting,
PRELUDE to set up the
simulation of heat and air
flow in a room.
In such circumstances,
Paris, 2008
buoyancy plays an important
role. How is it to be introduced?
An appropriate In-Form source
would be:
(source of W1 at BUOYANCY is 9.81*rho1*(tem1-exttem)/
(273+exttem) with volu)
This is ‘In-Form-speak’ for: “source of upward velocity per unit
volume is gravitational acceleration times difference of temperature
from external one divided by absolute temperature.”
In-Form sources written by PRELUDE:
a source of vertical velocity caused by In-Form
buoyancy (concluded)
The PRELUDE user need not remember how to write that In-
Form statement however; for he can summon a ‘buoyancy
object’, which, when it appears, already has its W1 source.
PHOENICS User Meeting,
Here is part of the screen which appears:
Paris, 2008
and the In-Form expression which is required is found right here!
The user is permitted to edit the expression if he wishes; then what
he writes will be transferred to the Q1 and onward.
The compatibility of In-Form and PRELUDE is based on their both
using character strings for data transfer, unlike the VR-Editor.
Another MOFOR example:
when the grid accelerates
In-Form
To simulate flow around accelerating
bodies, it is necessary to make the grid
PHOENICS User Meeting,
accelerate too. In-Form makes this
easy.
It must:
1. make the boundary conditions
Paris, 2008
depend on time; and
2. Create a body force everywhere.
Case v207 does this for a sphere, thus:
patch(in,low,1,nx,1,ny,1,1,1,lstep) ! Inlet patch.
(source of p1 at in is tim*rho1) ! Flow rate and velocity
(source of w1 at in is tim with onlyms) ! increase with time
patch(acel,phasem,1,nx,1,ny,1,nz,1,lstep) ! Body-force patch.
(source of w1 at acel is 1.0) ! Z-direction momentum source.
Case v207:
The accelerating sphere
In-Form
Here are velocity vectors and
contours at 1, 5 and 10 seconds after
PHOENICS User Meeting,
the start. The velocity field quickly
develops a steady pattern; but of
course the scale increases with time.
Paris, 2008
This capability of In-Form, like
many others, has not so far been
widely exploited, because too little
publicised. Yet it is powerful and
simple.
Swerving cars, manouvering
ships and (with foreseen
developments) colliding objects
can all be handled with its aid.
A more unusual example:
the „In-Form wave tank‟ In-Form
The VR-Editor can handle HVAC with buoyancy without In-Form;
so now a more-challenging task is considered: forces on an
PHOENICS User Meeting,
underwater structure on the sea bed.
The picture shows one result
of the simulation, in the
Paris, 2008
creation of which In-Form
played a large part.
Its task was to provide initial
and boundary conditions
which corresponded to
oscillating potential flow.
The Navier-Stokes equations
for the enclosed space were
then solved by PHOENICS.
The In-Form wave tank;
the mathematical foundation
In-Form
The ideal wave motion can be calculated from the velocity
potential, which, on the assumptions that the motion is
irrotational and the wave amplitude small compared with the
PHOENICS User Meeting,
wave-length, obeys the formula:
Pot = a cosh(m*y) cos(m*x + sigma*t)
where:
Paris, 2008
a = a measure of the wave amplitude
sigma**2 = g*m*tanh(m*h)
g = gravitational acceleration
h = mean water depth
m = 2*pi/wave-length
Further, the pressure and the two velocity components u and v
are respectively the differential coefficients of Pot with respect to
time, the negative-y coordinate and the negative-x coordinate.
Converting these relations into „In-Form-speak‟ is straightforward.
The In-Form wave tank; In-Form
some of the In-Form statements
The relevant Q1 is Core-Library case 743, from which a few
lines will be displayed in order that their straightforwardness
PHOENICS User Meeting,
can be recognised.
Formula for the potential as function of space and time
form=aa*(cosh(m*yg))*cos(m*xg-sig*tim)
(stored var pot is :form:) ! Create the variable
Paris, 2008
form=aa*(cosh(m*yg))*cos(m*xg-sig*tim1) ! tim1=tlast/lstep
(initial of pot at whole is :form:) ! Initialise the field
Formula for the potential-derived u velocity = - d pot/dx
form = aa*m*(cosh(m*yg))*sin(m*xu-sig*tim) ! for all times
(stored var upot at whole is :form:) ! Create the variable
form = aa*m*(cosh(m*yg))*sin(m*xu-sig*tim1) ! note tim1
(initial of u1 at whole is :form:) ! Initialise the field
It‟s tedious to type; but easier than Fortran or c++ programming!
The In-Form wave tank;
In-Form
some other clever tricks
In order to make sure that the pressures and velocities fit the
potential-derived values at the boundaries, use is made of the
PHOENICS User Meeting,
(little-used because little-known) ‘greater-than’ patches,
i.e.those with names starting >ppot..., >upot… and >vpot…
Also, not only are the forces on the underwater obstacle computed,
Paris, 2008
but also its deformations.
Because these are not
especially connected with In-
Form, they will not be further
discussed here.
However, it is worth remarking
that PHOENICS has many such
treasures lying buried in the
PHOENICS ocean!
In-Form computes exact solutions for
comparison with numerical computations In-Form
As well as the deformations of solids, PHOENICS can also
calculate the stresses and strains in them. (It is untrue that
PHOENICS User Meeting,
finite-element methods are necessary for stress-analysis).
Here is an example, chosen
because it has a known
Paris, 2008
analytical solution: a
rectangular strip with a
circular hole is in tension.
Symmetry allows only one
quarter of the strip to be
analysed for economy.
It appears as case s202 in the PHOENICS Input-File library
In-form enables the numerical and analytical solutions to be
compared.
In-Form computes exact solutions for
comparison with numerical computation In-Form
The exact solution is to be found in: I. Demirdzic, S. Mustaferija
"Finite-Volume method for stress analysis in Complex
Domains“; Int. J. for numerical methods in engineering", vol. 37,
PHOENICS User Meeting,
pp 3751-3756 (1994).)
When expressed via In-Form, it is:
char(form1,form2) ! Useful declarations to shorten lines below
Paris, 2008
(STORED VAR R7 IS SQRT(XG^2+YG^2)) ! Note SQRT
(STORED VAR TET7 IS ATAN(YG/(XG+1.e-10))) ! and ATAN
form2=COS(4*TET7))+1.5*(:R0:/R7)^4*COS(4*TET7)) ! and COS
(STORED VAR SXTH IS :form1::form2: with imat>100) ! Imat>10
(STORED VAR SX-T IS STRX/SXTH-1 with imat>100) ! 0 = solid
(STORED … defines and computes new variables
(longname of sx-t print as sx_minus_sxth_divided_by_sxth)
The last line is useful; it enables the fractional error to be printed
In-Form computes exact solutions for
comparison with numerical computation In-Form
Many people turn immediately to graphical display so as to inspect
their results. Here analytical and numerical x-direction stresses
are compared.
PHOENICS User Meeting,
Paris, 2008
Not bad agreement? But the scale maxima are 2.9e4 and 3.26e4 .
Sometimes it‟s better to look closely at numbers, not colour plots.
Comparison between analytical In-Form
solutions (concluded)
Here then is an extract from the RESULT file:
Field Values of SY-T: sy_minus_syth_divided_by_sxth
PHOENICS User Meeting,
IY= 60 -3.146E-04 1.242E-04 9.213E-04 1.376E-03 8.655E-04
IY= 48 -2.133E-02 -1.572E-02 -5.273E-03 3.121E-03 8.614E-03
IY= 36 -4.177E-02 -2.867E-02 1.588E-03 1.827E-02 1.782E-02
IY= 24 //////////////////////////////////// 4.043E-02 4.374E-02 2.426E-02
Paris, 2008
IY= 12 hole /////////////////////////////// 1.435E-01 3.099E-02
Field Values of SX-T: sx_minus_sxth_divided_by_sxth
IY= 60 2.302E-02 2.157E-02 1.782E-02 1.334E-02 5.359E-03
IY= 48 1.072E-02 7.732E-03 1.691E-03 -2.600E-03 -3.856E-03
IY= 36 1.180E-02 1.132E-02 -1.050E-02 -1.467E-02 -6.902E-03
IY= 24 ////////////////////////////////// -4.286E-02 -2.229E-02 -3.843E-03
IY= 12 hole ///////////////////////////// 1.146E-02 6.945E-03
IX= 1 13 25 37 49
Appreciable % errorsexist near hole edge; much less elsewhere.
Other uses for In-Form connected In-Form
with solid-stress analysis
In-Form statements are used in Q1 files to express stress, load
or displacement boundary conditions, e.g. in case s202:
PHOENICS User Meeting,
***** RIGHT : U - normal ******
char(fU3,fU4,TU2,RU2)
RU2=(:R02:/(:LX:^2+YG^2))
TU2=ATAN(YG/:LX:)
Paris, 2008
fU3=:FX:*(1-:RU2:*(1.5*COS(2*:TU2:)+
fU4=COS(4*:TU2:))+1.5*:RU2:^2*COS(4*:TU2:))
PATCH(RIGHTU,EAST,NX,NX,1,NY,1,1,1,1)
(source of U1 at RIGHTU is COVAL(FIXFLU,:fU3::fU4:))
Of course, this is far too complex for anyone but a specialist to
write; therefore the VR-Editor and PRELUDE are being provided
with dialogue boxes enabling users to insert data in ways
meaningful to them.
PHOENICS is becoming the first SFT (solid-fluid thermal) code.
Representing the atmospheric In-Form
conditions for wind-farm simulations
When simulating wind farms, it is necessary to
allow for the variation of temperature, pressure
PHOENICS User Meeting,
and density with altitude.
In the absence of significant motion and heat
transfer, these properties accord with known
formulae. In-Form provides a convenient means
Paris, 2008
of inputting these as „reference values‟, tref,
pref and dref, to PHOENICS, thus:
(stored var tref is =:t0:*(1-zg*:const1: )
(stored var pref is =:p0:*(1-zg*:const1:)^:const2::)
(stored var dref is :p0*29/(8314.0*t0)*(1-zg*:const1 :)
where zg is altitude and const1 and const2 are constants
depending on ground-level altitude and temperature
The temperatures, pressures and densities which PHOENICS
computes are then the local deviations from these quantities.
Representing the upstream wind- In-Form
velocity profiles
A related use for In-Form is the
specification of the wind profile.
PHOENICS User Meeting,
The PHOENICS Commander
even offers a tutorial on this; and
on many other topics!
Paris, 2008
For example a sixth-power
polynomial may be used:
POL6(arg1,arg2,arg3,arg4,ar
g5,arg6,arg7,arg8) - where
arg1 may be a constant or a
stored/solved variable, arg2,
arg3, arg4, arg5, arg6, arg7
and arg8 must be constants.
Above is not a sunset but a computed dref distribution plus hills.
Domain partitioning;
„exporting‟ and „importing‟ via In-Form
In-Form
Domain-partitioning reduces a large calculation to a
succession of smaller ones
PHOENICS User Meeting,
It is useful for simulation of phenomena characterised by a
predominant direction of flow, e.g when several chemical-
plant vessels are connected in series.
Paris, 2008
A similar situation arises when simulating flow over an extensive
tract of terrain, e.g. a complete city or a wide forest.
Partitioning is then possible because usually the direction of
wind varies little from place to place.
Upstream partitions are simulated first; their results are
„dumped‟ as „export objects‟ which are treated as „import
objects‟ by the next-downstream partitions.
The computations are carried out successively.
Using In-Form‟s „transfer objects‟ In-Form
for import and export
The idea is simple; but implementation has to be made easy.
Therefore ‘Transfer Objects‟ have been introduced by providing
PHOENICS User Meeting,
two keywords for In-Form, namely:
(EXPORT
and
(IMPORT
Paris, 2008
The first causes the PHOENICS solver module, EARTH, to write
a transfer-object file at the end of its run; the second causes
EARTH to read such a file at the start of its run.
Transfer objects can accordingly be created by placing in the Q1
file In-Form statements such as:
(EXPORT in NAME_of_TRANSFER_OBJECT at PATCH_NAME)
or
(EXPORT in NAME_of_TRANSFER_OBJECT at
OBJECT_NAME)
Transfer-object tests, 1 In-Form
This 2D steady laminar
convective and diffusive
PHOENICS User Meeting,
flow shows how one gets the
same answer whether one
partitions the domain (case
B) or does not (case A)
Paris, 2008
For this to happen, the flow
must be uni-directional with
Reynolds number >> 1.
This is Input-File Library case 856 .
The variable is a scalar, viz H1 .
Here is how one of the three export objects is created
PATCH(PAT1,HIGH,1,NX,1,NY,NZ,NZ,1,1) ! States where it is
(EXPORT in TROB1 at PAT1) ! Names the file to be used
Transfer-object tests, 2 In-Form
This 3D example shows
partitioning in two directions.
PHOENICS User Meeting,
It represents a steady
atmospheric boundary
layer with a point source of
Paris, 2008
pollutant.
The results with (case B) and
without (case A) partitioning
are in close agreement
It is Input-File-Library case 858., in which
TALK=T;RUN( 1, 5)
launches five runs in succession, one for each sub-domain
and a last one for the whole domain.
Transfer-object tests, 3;
three-dimensional and transient
In-Form
This example concerns
unsteady spread of a finite
release of pollutant into the
PHOENICS User Meeting,
atmosphere.
With (lower diagram) and
without (higher) partitioning,
Paris, 2008
the concentration distribution at
a fixed time is much the same
The wind field was constant, but
it could have been allowed to
change with time.
This is Input-File Library case 859, in which a power-law inlet-
velocity profile is created by In-Form thus:
PATCH(LINLET,LOW,1,NX,1,NY,1,1,1,LSTEP)
CONST=RHOIN*ABS(VELZ)/REFH**ALPHA
(SOURCE of P1 at LINLET is CONST*YG^ALPHA)
Transfer-object tests, 4; In-Form
objects of differing shape and size
The individual partitions may be more different from each other,
and connected in more complex ways.
PHOENICS User Meeting,
For example,
• the first might be used to compute the flow and heat transfer
within, and the output from, a computer cabinet;
Paris, 2008
• then the second might comprise a computer room with several
identical computers within it,
Another example:
• the first might be a room with a smoke-producing fire in it,
• the second the space around the building, and
• the third another room into which smoke enters through open
windows.
Both of these will be illustrated in what follows.
Transfer-object tests, 5; In-Form
computers in a room
Here is the result of
computing:
PHOENICS User Meeting,
• the temperature
distribution within, and
• the heat output from,
a (highly idealised) computer
Paris, 2008
cabinet
Its effects are „exported‟ to its environment via transfer objects at
its fan inlets and outlets.
It is Input-File Library case 863, in which some of the In-Form
statements are:
PATCH(HPAT,HIGH,1,NX,1,NY,NZ,NZ,1,1)
(EXPORT in HIGHTROB at HPAT)
PATCH(LPAT,LOW,1,NX,1,NY,1,1,1,1)
(EXPORT in LOWTROB at LPAT)
The cabinet temperature distribution
PHOENICS User Meeting,
enlarged for better visibility
In-Form
Paris, 2008
Several computers in a room
In-Form
This is the result of the
subsequent simulation of the
PHOENICS User Meeting,
temperature distribution in a
room containing several
identical computers
Paris, 2008
Their effects are „imported‟ via
the „export‟ objects of the
previous calculation,
This is Input-File Library case 864.,wherein some of the
relevant In-Form statements are:
(IMPORT from HIGHTROB at CMP1L)
(IMPORT from LOWTROB at CMP1H)
where HIGHTROB and LOWTROB are names of transfer-
object files
and CMPIL and CMP1H are names of placed VR-objects .
PHOENICS User Meeting, The computer room enlarged In-Form
Paris, 2008
A further example: smoke from a room
fire spreads through a building
In-Form
Here a fire in a room „exports‟ its
smoke through open windows.
PHOENICS User Meeting,
The fire is treated as steady,
which is not realistic but suffices
to show how transfer objects are
Paris, 2008
used.
This is Input-File Library case 860., wherein VR-object settings
convey the export information thus:
> OBJ, NAME, NWIND1
> OBJ, POSITION, 6.000E+00, 6.000E+00, 1.000E+00
> OBJ, SIZE,………
> OBJ, EXPORT, wind1.pob
PHOENICS VR-Editor provides menus for transfer-object setting
The flow of smoke around the In-Form
building
Here the smoke is „imported‟
PHOENICS User Meeting,
into the surroundings, which
then „export‟ some of it to other
rooms in the building‟.
Paris, 2008
•This is library case 861.
Here are some relevant statements fom that file:
> OBJ, NAME, IMTROB1
>OBJ, POSITION, 1.600E+01, 2.200E+01, 1.000E+00
> OBJ, IMPORT, wind1.pob
Smoke is imported into another room In-Form
Here an adjoining room
„imports‟ smoke through its
PHOENICS User Meeting,
open windows
This is library case 862 which,
on inspection, will be found to
have the expected import
Paris, 2008
statements.
In a more realistic simulation,
• the calculation would have been carried out in a time-dependent
manner;
• all the rooms in the building would have been treated in the
same way, and
• if two-way interactions were suspected, Iterative procedures
would have been introduced.
The transfer-object framework is strong enough to bear all these
extra loads..
In-Form opens new research doors, In-Form
e.g. to the Population Dimension
Other PHOENICS-related
presentations have stressed
PHOENICS User Meeting,
the population dimension as
an important new direction of
CFD developments.
Paris, 2008
In-Form greatly facilitates entry
and participation.
The „new dimension‟ can take many forms; for example:
• age, or height or pigmentation in humans in one country;
• temperature, concentration, velocity or droplet size in a given
cell in a four-dimensional (x, y, z, time) CFD computation.
Computed distributions can be
represented as histograms or:
thus:
Built-in population-dimension features In-Form
of PHOENICS
PHOENICS has some built-in population-dimension features,
notably its multi-fluid model of turbulence, especially useful for
PHOENICS User Meeting,
simulating chemical-reaction processes.
This calculates both one-dimensional and two-dimensional
histograms such as the following.
Paris, 2008
But users who have different ideas can express these via In-Form.
Turbulent jet-mixing within a circular In-Form
pipe; library case 781
Some history:
• PLANT entered PHOENICS in 1998.
•The multi-fluid model (MFM) entered PHOENICS during 1995-6.
PHOENICS User Meeting,
• Sergey Zhubrin, the initiator of PLANT, used PLANT to make his
own version of MFM in 1999.
• Nikolay Pavitskiy, the creator of In-Form, re-wrote Zhubrin‟s
Paris, 2008
model in terms of In-Form in 2001.
Library case 781 uses Zhubrin‟s model In-Formised by
Pavitskiy, to simulate turbulent mixing of two coaxial streams.
The k-epsilon model is used to simulate the hydrodynamics.
A seventeen-fluid model is used to simulate mixing, each fluid
having a different proportion of material from the two streams
Conventional single-fluid equations for time-average concentration
and root-mean-square concentration fluctuations are also solved.
The results for the conventionally- In-Form
computed quantities
Computed values of usual
variables are as expected. Here
are the velocity vectors.
PHOENICS User Meeting,
Here are longitudinal-velocity
Paris, 2008
contours. The largest value is
on the axis at the entrance.
Time-average concentration
contours have similar shapes.
Root-mean-square fluctuations
also present no surprises
Results for unconventional quantities:
individual-fluid mass fractions
In-Form
Now for the interesting results:
individual-fluid mass fractions.
PHOENICS User Meeting,
Fluid1 clearly disappears
almost as soon as it enters.
Fluid 17 has a longer life; but
Paris, 2008
it is absorbed into the
turbulent jet boundary.
Colliding there with other
fluids, it creates first Fluid 16,
and others of course.
Here are the contours of the
next-richest in injected-
substance content, Fluid 15.
Results for conventional quantities: In-Form
computed in an unconventional way
And so on for all the other intermediate-richness fluids, which
need not however be displayed.
PHOENICS User Meeting,
From the complete spectrum (pdf) average and RMS fluctuations
can be directly deduced
Here are the former. The
Paris, 2008
contours are of identical to
those shown above, based on
conventional one-fluid theory.
And here the latter. They are
not identical to those shown
earlier. Why not?
Because the ‘g-equation’ is
based on a presumed, not
calculated (by MFM) pdf.
A calculated pdf at one location In-Form
in the turbulent jet
Here is a calculated probability-density
function deduced from knowledge of the
PHOENICS User Meeting,
individual-fluid mass fractions, One
exists for each computational cell.
Now that the MFM is available, there is no
Paris, 2008
need to guess the pdf shape.
Nor need the built-in MFM coding be used[
In-Form lets users create own versions.
Question 1. Are the predictions correct?
Answer 1. Only qualitatively; for collision-rate constants are first
estimates; and experimental research to refine them is absent.
Question 2. Why is it absent?
Answer 2. Because the existence and ease-of-use of MFM have
been too little known; but this can now change.
How the 17-fluid model is created In-Form
by In-Form statements
The case-781 Q1 contains all the necessary statements; some of
these will now be shown
PHOENICS User Meeting,
The conventional RMS fluctuations g is introduced thus:
** Source term for g
PATCH(ISORG,VOLUME,1,NX,1,NY,1,NZ,1,1) ! Where compute
(SOURCE of G at ISORG is 2.0*:RHO1:*EPKE* ! How compute
Paris, 2008
GENG/(2.0*:RHO1:*EPKE+TINY)-G))
where
STORED of GENG is 2.8*:RHO1:*ENUT*
(DFZ+DFY+DFZH+DFYN))
EPKE=epsilon/k, a standard PHOENICS turbulence-rate term,
DFZ and DFY and In-Form-calculated concentration gradients
PATCH(PAT1,CELL,1,NX,1,NY,1,NZ-1,1,1) ! Where compute
(STORED of DFZ at PAT1 is ((H1[,,+1]-H1)/DZG)^2) ! How
It‟s tedious to disentangle; but becomes clear in the end.
How collision (i.e. coupling & splitting) In-Form
are represented by In-Form
** Coupling/splitting rates
PATCH(iMIX,PHASEM,1,NX,1,NY,1,NZ,1,1) ! where
(SOURCE of F1 at iMIX is :MMC:*EPKE*
PHOENICS User Meeting,
(F3+F5+F7+F9+F11+F13+F15+F17)*(0.-F1) with LINE) ! How
Fluid 1 is never created, only destroyed by colliding with fluids 3,
5, 7, 9, 11, etc. Not 4, 6, 8 etc. ? That‟s Zhubrin‟s concept; the
Paris, 2008
built-in MFM allows more; In-Form users decide for themselves.
Fluid 3 is both created and destroyed. Here is Zhubrin‟s
proposal for its nett source:
(SOURCE of F3 at iMIX is 2.*:MMC:*EPKE*(F2*F4+F1*F5)-
:MMC:*EPKE*(F1+F17+F5+F7+F9+F11+F13+F15)*F3)
So it is created when fluids 2 and 4 collide; also 1 and 5; and it is
destroyed by collisions with 1, 17, 5, 7, 9, 11, 13 and 15.
Is that reasonable? Each can have his own opinion. Here we are
watching a researcher exploit the freedom In-Form provides
More of the same In-Form
Long In-Form statements are hard to read; but the PHOENICS
Input Language has many ease-of-use features. Here we see
PHOENICS User Meeting,
CHARacter declarations being exploited.
CHAR(SUM1,SUM2)
SUM1=(F8*F10+F7*F11+F6*F12+F5*F13+F4*F14+F3*F15+
F2*F16+F1*F17)
Paris, 2008
SUM2=(F1+F3+F5+F7+F17+F11+F13+F15) (SOURCE of F9 at
iMIX is 2.*:MMC:*EPKE*:SUM1:-:MMC:*EPKE*:SUM2:*F9)
Lastly, SUM1 and SUM2 are also used here, where all the fluid
mass fractions are summed for output purposes
** Output calculations
SUM1=16./16.*F1+15./16.*F2+14./16.*F3+13./16.*F4
SUM2=12./16.*F5+11./16.*F6+10./16.*F7+9./16.*F8+8./16.*F9
(STORED of CAV is :SUM1:+:SUM2: with
IF(ISWEEP.EQ.LSWEEP))
What have we learned from the study In-Form
of case 781?
That PHOENICS is capacious enough to enable users to introduce
new stored or solved-for variables at will.
PHOENICS User Meeting,
That In-Form then allows them to prescribe their values, their
sources and their boundary conditions according to arbitrary
formulae.
Paris, 2008
That these are precisely the facilities which are needed to allow
users to undertake researches in the Population Dimension of
modern CFD.
That unprecedented new CFD simulations can then be swiftly
carried out without creation of any new Fortran, C or C++ codiing
whatever.
The facilities are of course available for any other, even not-yet-
thought-of novel investigations. PHOENICS is the Thinker’s code.
When the fluids do not all have the In-Form
same density
Multi-fluid models throw much light on chemically-reacting flows;
then the distinct fluids have differing compositions, temperatures
PHOENICS User Meeting,
and densities. The latter effect will now be explored.
A single In-Form line added to the case-581 Q1 allows this:
(property rho1 is (f1+f17)*1.0+(1.-f1-f17)*0.1)
Paris, 2008
which gives all the created-by-collision fluids the density 0.1, so as
to represent crudely the effect of combustion [which can be done in
a few seconds, whereas a few minutes would be needed to
represent it realistically ].
In a few more seconds one has performed
the run and can inspect the results.
Here is the pdf for the same position as
before. It is of course different.
More results when density of new- In-Form
created fluids has been reduced to 0.1
Here is the resulting distribution
of mixture-average density;
PHOENICS User Meeting,
here is the consequent velocity-
vector diagram, which is of
Paris, 2008
course different from before.
and here is the resulting
distribution of fluid-16 mass
fraction, also different.
Having thus very quickly established that results are qualitatively as
expected, it is worth spending the few minutes required for realism.
It is the existence of the hundreds of input-file-library cases as
starting points, which allows such swift progress to be made
Further possible directions of In-Form
investigation opened up by In-Form
Because fluids of different density respond differently to
pressure gradient, relative velocities arise, expressible
PHOENICS User Meeting,
via In-Form, which influence collision rate.
Different temperatures and compositions lead to
Paris, 2008
different reaction rates, e.g. of NOX or smoke
formation. Non-linearity invalidates conventional
single-fluid computations, also two-fluid models
such as eddy-break-up and eddy-dissipation.
How many fluids are needed for accuracy? That
depends on the particular problem,
In-Form permits fluid number to be easily varied,
so allowing population-grid-refinement studies.
Further possible directions of In-Form
investigation opened up by In-Form
Radiation fluxes vary as T**4; and with
composition. Therefore hazards from gas
PHOENICS User Meeting,
explosions require multi-fluid analysis for
their prediction. In-Form facilitates this.
The built-in MFM of PHOENICS allows 2D
Paris, 2008
populations (eg fuel-air ratio and
reactedness. An In-Form-based alternative
would be simple to create. Remember:
no coding is needed. Any user can do it.
In short, the
possibilities are
endless
User-support in respect of In-Form; In-Form
a warning
In-Form is so powerful that CHAM has had to introduce a
change of policy: whereas much user support has been
PHOENICS User Meeting,
provided free of charge, this is not possible when In-Form
has been extensively exploited.
Many users have enthusiastically adopted In-Form as their
means of creating process simulations of unprecedented
Paris, 2008
nature and complexity; and sometimes they have obtained
unexpected, puzzling and even undesired results.
Understandably, they ask: why? or: did I do something
wrong? CHAM‟s user-support team would like to assist them.;
but this time-consuming assistance needs to be paid for.
Of course, if finally the results can be attributed to a defect in
the software or documentation, the obligation to pay is waived.
But such defects are nowadays rarely found.
PHOENICS User Meeting,
Paris, 2008
text
In-Form
Related docs
