InForm PHOENICS User Meeting Paris 2008 the INput

In-Form PHOENICS User Meeting, Paris, 2008 the INput of data via FORMulae In-Form However hard they try, creators of CFD codes can never foresee all the processes which their users will want to simulate; for users are humans. They think of things never thought of before But code creators can provide the tools 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 PHOENICS User Meeting, Paris, 2008 The previous two stages were: 1. User programming, (1981) enabling users to add Fortran sub-routines written by themselves. This facility is still available and used; but it requires a recompilable version of PHOENICS. 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 PHOENICS User Meeting, Paris, 2008 In-Form has very many uses, of which some are: 1. creating initial-value distributions; 2. introducing non-linear boundary conditions and sources; sources 3. defining material properties in accordance with whatever formulae the user wishes; 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 PHOENICS User Meeting, Paris, 2008 1. In-Form is activated by statements placed by the user in the Q 1 (input) file in accordance with a special syntax. That is all that the user has to do; and even this labour can be reduced if PRELUDE is employed (of which more later). 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.

PHOENICS User Meeting, Paris, 2008 Examples of the use of In-Form: 1. the shell-and tube heat-exchanger In-Form PHOENICS Input-File library case 800 represents a shell-andtube heat exchanger, cooling hot engine oil by cold water. 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 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.

PHOENICS User Meeting, Paris, 2008 The shell-and tube heat-exchanger; fluid viscosities In-Form is used to compute material properties, by extracting formulae from the PHOENICS library. Thus, for the kinematic viscosity of water, the lines to be copied into the Q 1 file are: rho_expression=POL 5(tems, 2446. , -20. 6741, . 11576, -3. 12895 e-4, 4. 0505 E-7, -2. 054 E-10) emu_expression=1. e-7*exp((1. 12646 -. 039638*tems) / (1. -7. 29769 E-3*tems)) (property rho 1 is : rho_expression: ) (property enul is : emu_expression: /(rho 1)) wherein: tems stands for shell-side temperature, POL 5() indicates that In-Form can handle 5 th-order polynomials, exp() indicates that it can use the exponential function. (property rho 1 …sets the density everywhere, (property enul … sets the kinematic viscosity. Corresponding lines must be copied in for the engine oil.

PHOENICS User Meeting, Paris, 2008 The shell-and tube heat-exchanger; fluid viscosities and Prandtl numbers. In-Form The corresponding computed fields of (for example) oil viscosity are shown here. Conventional heat-exchangerdesign program presume, by the way, all material 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*rho 1*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.

PHOENICS User Meeting, Paris, 2008 Nusselt numbers deduced from empirical formulae In-Form 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. Answer: In the Q 1, 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) (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.

PHOENICS User Meeting, Paris, 2008 Shell-side, tube-side and overall heat-transfer coefficients What follows is obvious: deduce the coefficients from the Nusselt Numbers via further In-Form statements, viz: (stored var coes is areadvol* nuss*cond/diam) (stored var coet is areadvol* nust*cont/diam) (stored var coeu is coes* coet/(coes+coet)) wherein: areadvol is area divided by volume, coes, coet and coeu are three coefficients, etc. Recall: all this from Q 1 statements alone! In-Form Here are the results: shell-side tube-side overall

PHOENICS User Meeting, Paris, 2008 Assistance with the understanding of print-out: In-Form’s longname feature In-Form Before leaving case 800, note the following In-Form statements: (longname of hs print as shell-side_fluid_enthalpy) (longname of tems print as shell-side_fluid_temperature) (longname of rho 1 print as shell-side_fluid_density) (longname of cps print as shell-side_fluid_specific_heat) The longnames are what is printed in the RESULT file; so there is no need to remember the abbreviations used in the Q 1. This is just one of many items which In-Form provides for the user’s convenience. More could be provided. Users’ suggestions are welcome.

PHOENICS User Meeting, Paris, 2008 In-Form can describe the motion of objects A useful feature of PHOENCS is MOFOR (= Moving Frames of Reference), which permits Simulation of relatively moving objects and grids. 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. In-Form

PHOENICS User Meeting, Paris, 2008 An example: library case 766; a parabolic trajectory In-Form The animated picture shows the velocity vectors caused by a body moving in a twodimensional fluid-filled space. The motion is activated by way of PIL declarations followed by a few In-Form lines in the Q 1, as follows: SAVE 13 BEGIN 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

PHOENICS User Meeting, Paris, 2008 An example: library case 766; a parabolic trajectory (continued) In-Form That is not all; one still has to define what moves, and ensure that its motion is imparted to the fluid. The first is achieved by declaring the existence of an ‘in-form object’ of spherical shape, thus: PATCH(PATCH 1, CELL, 1, NX, 1, NY, 1, NZ, 1, LSTEP) INFOB at PATCH 1 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.

PHOENICS User Meeting, Paris, 2008 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 statements, one for horizontal velocity u 1, and the other for vertical velocity v 1. 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 U 1 at PATCH 1 is : usour: with OB_1!FIXV) (SOURCE of V 1 at PATCH 1 is : vsour: with OB_1!FIXV) This is ‘In-Form speak’ for: “wherever object OB_1 (i. e. the sphere) finds itself in PATCH 1, fix the values of the velocity components of the fluid to be those of the sphere”.

PHOENICS User Meeting, Paris, 2008 An example: library case 766; a parabolic trajectory (concluded) In-Form “But that’s so difficult”, some may say. ”Why can’t the VREditor enable me to set up the problem by way of dialogue boxes? ” The answer is that it could be programmed to do so; but only for particular trajectories. But remember Rodin’s PHOENICS user. Whatever PHOENICS supplies, its thoughtful users will think of something else. Nevertheless, PHOENICS does now have a user interface which assists with the input of In-Form sources, as will now be illustrated. It is called PRELUDE.

PHOENICS User Meeting, Paris, 2008 In-Form sources written by PRELUDE: a source of vertical velocity caused by buoyancy In-Form The picture shows what a user might see when using PRELUDE to set up the simulation of heat and air flow in a room. In such circumstances, buoyancy plays an important role. How is it to be introduced? An appropriate In-Form source would be: (source of W 1 at BUOYANCY is 9. 81*rho 1*(tem 1 -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. ”

PHOENICS User Meeting, Paris, 2008 In-Form sources written by PRELUDE: a source of vertical velocity caused by buoyancy (concluded) In-Form 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 W 1 source. Here is part of the screen which appears: 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 Q 1 and onward. The compatibility of In-Form and PRELUDE is based on their both using character strings for data transfer, unlike the VR-Editor.

PHOENICS User Meeting, Paris, 2008 Another MOFOR example: when the grid accelerates In-Form To simulate flow around accelerating bodies, it is necessary to make the grid accelerate too. In-Form makes this easy. It must: 1. make the boundary conditions depend on time; and 2. Create a body force everywhere. Case v 207 does this for a sphere, thus: patch(in, low, 1, nx, 1, ny, 1, 1, 1, lstep) ! Inlet patch. (source of p 1 at in is tim*rho 1) ! Flow rate and velocity (source of w 1 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 w 1 at acel is 1. 0) ! Z-direction momentum source.

PHOENICS User Meeting, Paris, 2008 Case v 207: The accelerating sphere Here are velocity vectors and contours at 1, 5 and 10 seconds after the start. The velocity field quickly develops a steady pattern; but of course the scale increases with time. 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. In-Form

PHOENICS User Meeting, Paris, 2008 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 underwater structure on the sea bed. The picture shows one result of the simulation, in the 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.

PHOENICS User Meeting, Paris, 2008 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 wave-length, obeys the formula: Pot = a cosh(m*y) cos(m*x + sigma*t) where: 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.

PHOENICS User Meeting, Paris, 2008 The In-Form wave tank; some of the In-Form statements In-Form The relevant Q 1 is Core-Library case 743, from which a few lines will be displayed in order that their straightforwardness 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 form=aa*(cosh(m*yg))*cos(m*xg-sig*tim 1) ! tim 1=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*tim 1) ! note tim 1 (initial of u 1 at whole is : form: ) ! Initialise the field It’s tedious to type; but easier than Fortran or c++ programming!

PHOENICS User Meeting, Paris, 2008 The In-Form wave tank; some other clever tricks In-Form In order to make sure that the pressures and velocities fit the potential-derived values at the boundaries, use is made of the (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, 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!

PHOENICS User Meeting, Paris, 2008 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 finite-element methods are necessary for stress-analysis). Here is an example, chosen because it has a known 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 s 202 in the PHOENICS Input-File library In-form enables the numerical and analytical solutions to be compared.

PHOENICS User Meeting, Paris, 2008 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, pp 3751 -3756 (1994). ) When expressed via In-Form, it is: char(form 1, form 2) ! Useful declarations to shorten lines below (STORED VAR R 7 IS SQRT(XG^2+YG^2)) ! Note SQRT (STORED VAR TET 7 IS ATAN(YG/(XG+1. e-10))) ! and ATAN form 2=COS(4*TET 7))+1. 5*(: R 0: /R 7)^4*COS(4*TET 7)) ! and COS (STORED VAR SXTH IS : form 1: : form 2: 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

PHOENICS User Meeting, Paris, 2008 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. Not bad agreement? But the scale maxima are 2. 9 e 4 and 3. 26 e 4. Sometimes it’s better to look closely at numbers, not colour plots.

Comparison between analytical solutions (concluded) In-Form PHOENICS User Meeting, Paris, 2008 Here then is an extract from the RESULT file: Field Values of SY-T: sy_minus_syth_divided_by_sxth IY= 60 -3. 146 E-04 1. 242 E-04 9. 213 E-04 1. 376 E-03 IY= 48 -2. 133 E-02 -1. 572 E-02 -5. 273 E-03 3. 121 E-03 IY= 36 -4. 177 E-02 -2. 867 E-02 1. 588 E-03 1. 827 E-02 IY= 24 ////////////////// 4. 043 E-02 4. 374 E-02 IY= 12 hole //////////////// 1. 435 E-01 8. 655 E-04 8. 614 E-03 1. 782 E-02 2. 426 E-02 3. 099 E-02 Field Values of SX-T: sx_minus_sxth_divided_by_sxth IY= 60 2. 302 E-02 2. 157 E-02 1. 782 E-02 1. 334 E-02 5. 359 E-03 IY= 48 1. 072 E-02 7. 732 E-03 1. 691 E-03 -2. 600 E-03 -3. 856 E-03 IY= 36 1. 180 E-02 1. 132 E-02 -1. 050 E-02 -1. 467 E-02 -6. 902 E-03 IY= 24 ///////////////// -4. 286 E-02 -2. 229 E-02 -3. 843 E-03 IY= 12 hole /////////////// 1. 146 E-02 6. 945 E-03 IX= 1 13 25 37 49 Appreciable % errorsexist near hole edge; much less elsewhere.

PHOENICS User Meeting, Paris, 2008 Other uses for In-Form connected with solid-stress analysis In-Form statements are used in Q 1 files to express stress, load or displacement boundary conditions, e. g. in case s 202: ***** RIGHT : U - normal ****** char(f. U 3, f. U 4, TU 2, RU 2) RU 2=(: R 02: /(: LX: ^2+YG^2)) TU 2=ATAN(YG/: LX: ) f. U 3=: FX: *(1 -: RU 2: *(1. 5*COS(2*: TU 2: )+ f. U 4=COS(4*: TU 2: ))+1. 5*: RU 2: ^2*COS(4*: TU 2: )) PATCH(RIGHTU, EAST, NX, 1, NY, 1, 1) (source of U 1 at RIGHTU is COVAL(FIXFLU, : f. U 3: : f. U 4: )) 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.

PHOENICS User Meeting, Paris, 2008 Representing the atmospheric conditions for wind-farm simulations In-Form When simulating wind farms, it is necessary to allow for the variation of temperature, pressure 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 of inputting these as ‘reference values’, tref, pref and dref, to PHOENICS, thus: (stored var tref is =: t 0: *(1 -zg*: const 1: ) (stored var pref is =: p 0: *(1 -zg*: const 1: )^: const 2: : ) (stored var dref is : p 0*29/(8314. 0*t 0)*(1 -zg*: const 1 : ) where zg is altitude and const 1 and const 2 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.

PHOENICS User Meeting, Paris, 2008 Representing the upstream windvelocity profiles In-Form A related use for In-Form is the specification of the wind profile. The PHOENICS Commander even offers a tutorial on this; and on many other topics! For example a sixth-power polynomial may be used: POL 6(arg 1, arg 2, arg 3, arg 4, ar g 5, arg 6, arg 7, arg 8) - where arg 1 may be a constant or a stored/solved variable, arg 2, arg 3, arg 4, arg 5, arg 6, arg 7 and arg 8 must be constants. Above is not a sunset but a computed dref distribution plus hills.

Domain partitioning; ‘exporting’ and ‘importing’ via In-Form PHOENICS User Meeting, Paris, 2008 Domain-partitioning reduces a large calculation to a succession of smaller ones It is useful for simulation of phenomena characterised by a predominant direction of flow, e. g when several chemicalplant vessels are connected in series. 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.

PHOENICS User Meeting, Paris, 2008 Using In-Form’s ‘transfer objects’ for import and export In-Form The idea is simple; but implementation has to be made easy. Therefore ‘Transfer Objects’ have been introduced by providing two keywords for In-Form, namely: (EXPORT and (IMPORT 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 Q 1 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)

PHOENICS User Meeting, Paris, 2008 Transfer-object tests, 1 In-Form This 2 D steady laminar convective and diffusive flow shows how one gets the same answer whether one partitions the domain (case B) or does not (case A) 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 H 1. Here is how one of the three export objects is created PATCH(PAT 1, HIGH, 1, NX, 1, NY, NZ, 1, 1) ! States where it is (EXPORT in TROB 1 at PAT 1) ! Names the file to be used

PHOENICS User Meeting, Paris, 2008 Transfer-object tests, 2 In-Form This 3 D example shows partitioning in two directions. It represents a steady atmospheric boundary layer with a point source of 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.

PHOENICS User Meeting, Paris, 2008 Transfer-object tests, 3; three-dimensional and transient In-Form This example concerns unsteady spread of a finite release of pollutant into the atmosphere. With (lower diagram) and without (higher) partitioning, 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 inletvelocity 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 P 1 at LINLET is CONST*YG^ALPHA)

PHOENICS User Meeting, Paris, 2008 Transfer-object tests, 4; objects of differing shape and size In-Form The individual partitions may be more different from each other, and connected in more complex ways. For example, • the first might be used to compute the flow and heat transfer within, and the output from, a computer cabinet; • 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.

PHOENICS User Meeting, Paris, 2008 Transfer-object tests, 5; computers in a room In-Form Here is the result of computing: • the temperature distribution within, and • the heat output from, a (highly idealised) computer 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, 1, 1) (EXPORT in HIGHTROB at HPAT) PATCH(LPAT, LOW, 1, NX, 1, NY, 1, 1) (EXPORT in LOWTROB at LPAT)

PHOENICS User Meeting, Paris, 2008 The cabinet temperature distribution enlarged for better visibility In-Form

PHOENICS User Meeting, Paris, 2008 Several computers in a room In-Form This is the result of the subsequent simulation of the temperature distribution in a room containing several identical computers 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 CMP 1 L) (IMPORT from LOWTROB at CMP 1 H) where HIGHTROB and LOWTROB are names of transferobject files and CMPIL and CMP 1 H are names of placed VR-objects.

PHOENICS User Meeting, Paris, 2008 The computer room enlarged In-Form

PHOENICS User Meeting, 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. The fire is treated as steady, which is not realistic but suffices to show transfer objects are used. This is Input-File Library case 860. , wherein VR-object settings convey the export information thus: > OBJ, NAME, NWIND 1 > OBJ, POSITION, 6. 000 E+00, 1. 000 E+00 > OBJ, SIZE, ……… > OBJ, EXPORT, wind 1. pob PHOENICS VR-Editor provides menus for transfer-object setting

PHOENICS User Meeting, Paris, 2008 The flow of smoke around the building In-Form Here the smoke is ‘imported’ into the surroundings, which then ‘export’ some of it to other rooms in the building’. • This is library case 861. Here are some relevant statements fom that file: > OBJ, NAME, IMTROB 1 >OBJ, POSITION, 1. 600 E+01, 2. 200 E+01, 1. 000 E+00 > OBJ, IMPORT, wind 1. pob

PHOENICS User Meeting, Paris, 2008 Smoke is imported into another room In-Form Here an adjoining room ‘imports’ smoke through its open windows This is library case 862 which, on inspection, will be found to have the expected import 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. .

PHOENICS User Meeting, Paris, 2008 In-Form opens new research doors, e. g. to the Population Dimension In-Form Other PHOENICS-related presentations have stressed the population dimension as an important new direction of CFD developments. 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 thus: or:

PHOENICS User Meeting, Paris, 2008 Built-in population-dimension features of PHOENICS In-Form PHOENICS has some built-in population-dimension features, notably its multi-fluid model of turbulence, especially useful for simulating chemical-reaction processes. This calculates both one-dimensional and two-dimensional histograms such as the following. But users who have different ideas can express these via In-Form.

PHOENICS User Meeting, Paris, 2008 Turbulent jet-mixing within a circular pipe; library case 781 In-Form Some history: • PLANT entered PHOENICS in 1998. • The multi-fluid model (MFM) entered PHOENICS during 1995 -6. • 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 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.

PHOENICS User Meeting, Paris, 2008 The results for the conventionallycomputed quantities Computed values of usual variables are as expected. Here are the velocity vectors. Here are longitudinal-velocity 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 In-Form

PHOENICS User Meeting, Paris, 2008 Results for unconventional quantities: individual-fluid mass fractions Now for the interesting results: individual-fluid mass fractions. Fluid 1 clearly disappears almost as soon as it enters. Fluid 17 has a longer life; but 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 injectedsubstance content, Fluid 15. In-Form

PHOENICS User Meeting, Paris, 2008 Results for conventional quantities: computed in an unconventional way In-Form And so on for all the other intermediate-richness fluids, which need not however be displayed. From the complete spectrum (pdf) average and RMS fluctuations can be directly deduced Here are the former. The 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.

PHOENICS User Meeting, Paris, 2008 A calculated pdf at one location in the turbulent jet In-Form Here is a calculated probability-density function deduced from knowledge of the individual-fluid mass fractions, One exists for each computational cell. Now that the MFM is available, there is no 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.

PHOENICS User Meeting, Paris, 2008 How the 17 -fluid model is created by In-Form statements In-Form The case-781 Q 1 contains all the necessary statements; some of these will now be shown 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*: RHO 1: *EPKE* ! How compute GENG/(2. 0*: RHO 1: *EPKE+TINY)-G)) where STORED of GENG is 2. 8*: RHO 1: *ENUT* (DFZ+DFY+DFZH+DFYN) ) EPKE=epsilon/k, a standard PHOENICS turbulence-rate term, DFZ and DFY and In-Form-calculated concentration gradients PATCH(PAT 1, CELL, 1, NX, 1, NY, 1, NZ-1, 1, 1) ! Where compute (STORED of DFZ at PAT 1 is ((H 1[, , +1]-H 1)/DZG)^2) ! How It’s tedious to disentangle; but becomes clear in the end.

PHOENICS User Meeting, Paris, 2008 How collision (i. e. coupling & splitting) are represented by In-Form ** Coupling/splitting rates PATCH(i. MIX, PHASEM, 1, NX, 1, NY, 1, NZ, 1, 1) ! where (SOURCE of F 1 at i. MIX is : MMC: *EPKE* (F 3+F 5+F 7+F 9+F 11+F 13+F 15+F 17)*(0. -F 1) 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 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 F 3 at i. MIX is 2. *: MMC: *EPKE*(F 2*F 4+F 1*F 5): MMC: *EPKE*(F 1+F 17+F 5+F 7+F 9+F 11+F 13+F 15)*F 3) 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

PHOENICS User Meeting, Paris, 2008 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 CHARacter declarations being exploited. CHAR(SUM 1, SUM 2) SUM 1=(F 8*F 10+F 7*F 11+F 6*F 12+F 5*F 13+F 4*F 14+F 3*F 15+ F 2*F 16+F 1*F 17) SUM 2=(F 1+F 3+F 5+F 7+F 11+F 13+F 15) (SOURCE of F 9 at i. MIX is 2. *: MMC: *EPKE*: SUM 1: -: MMC: *EPKE*: SUM 2: *F 9) Lastly, SUM 1 and SUM 2 are also used here, where all the fluid mass fractions are summed for output purposes ** Output calculations SUM 1=16. /16. *F 1+15. /16. *F 2+14. /16. *F 3+13. /16. *F 4 SUM 2=12. /16. *F 5+11. /16. *F 6+10. /16. *F 7+9. /16. *F 8+8. /16. *F 9 (STORED of CAV is : SUM 1: +: SUM 2: with IF(ISWEEP. EQ. LSWEEP))

What have we learned from the study of case 781? In-Form PHOENICS User Meeting, Paris, 2008 That PHOENICS is capacious enough to enable users to introduce new stored or solved-for variables at will. That In-Form then allows them to prescribe their values, their sources and their boundary conditions according to arbitrary formulae. 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-yetthought-of novel investigations. PHOENICS is the Thinker’s code.

PHOENICS User Meeting, Paris, 2008 When the fluids do not all have the same density In-Form Multi-fluid models throw much light on chemically-reacting flows; then the distinct fluids have differing compositions, temperatures and densities. The latter effect will now be explored. A single In-Form line added to the case-581 Q 1 allows this: (property rho 1 is (f 1+f 17)*1. 0+(1. -f 17)*0. 1) 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.

PHOENICS User Meeting, Paris, 2008 More results when density of newcreated fluids has been reduced to 0. 1 In-Form Here is the resulting distribution of mixture-average density; here is the consequent velocityvector diagram, which is of 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

PHOENICS User Meeting, Paris, 2008 Further possible directions of investigation opened up by In-Form Because fluids of different density respond differently to pressure gradient, relative velocities arise, expressible via In-Form, which influence collision rate. Different temperatures and compositions lead to 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.

PHOENICS User Meeting, Paris, 2008 Further possible directions of investigation opened up by In-Form Radiation fluxes vary as T**4; and with composition. Therefore hazards from gas explosions require multi-fluid analysis for their prediction. In-Form facilitates this. The built-in MFM of PHOENICS allows 2 D 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

PHOENICS User Meeting, Paris, 2008 User-support in respect of 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 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 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 In-Form text