In-Form the INput of data via FORMulae

1. In-Formthe INput of data via FORMulae However hard they try, creators of CFD codes can never foreseeall 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..

2. In-Form’s predecessors The previous two stageswere: • User programming, (1981) enabling users to add Fortran sub-routines written by themselves. • This facility is still available and used; but it requires a re-compilable version of PHOENICS. • 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.

3. For what In-Form can be used(Examples will be supplied later) In-Form has very many uses, of which some are: 1. creating initial-value distributions; 2. introducing non-linear boundary conditions and 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.

4. How In-Form works 1. In-Form is activated by statements placed by the user in the Q1 (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.

5. Examples of the use of 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. 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.

6. 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 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) / (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.

7. The shell-and tube heat-exchanger;fluid viscosities and Prandtl numbers. The corresponding computed fields of (for example) oil viscosity are shown here. Conventional heat-exchanger-design 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*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.

8. Nusselt numbers deduced from 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. 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) (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.

9. 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: Here are the results: (stored var coes is areadvol* nuss*cond/diam) (stored var coet is areadvol* nust*cont/diam) (stored var coeu is coes* coet/(coes+coet)) shell-side 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

10. Assistance with the understanding of 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) (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) 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.

11. 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.

12. An example: library case 766;a parabolic trajectory The animated picture shows the velocity vectors caused by a body moving in a two-dimensional fluid-filled space. The motion is activated by way of PIL declarations followed by a few 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

13. An example: library case 766;a parabolic trajectory (continued) 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(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.

14. An example: library case 766;a parabolic trajectory (continued) How ensure that its motion is imparted to the fluid? By way of In-Form source statements, one for horizontal velocity u1, and the other for vertical velocity v1. 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”.

15. An example: library case 766;a parabolic trajectory (concluded) “But that’s so difficult”, some may say. ”Why can’t the VR-Editor 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. 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. Whatever PHOENICS supplies, its thoughtful users will think of something else.

16. In-Form sources written by PRELUDE:a source of vertical velocity caused by buoyancy 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-Formsource 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.”

17. In-Form sources written by PRELUDE:a source of vertical velocity caused by buoyancy (concluded) The PRELUDE user need not remember how to write that In-Form statement however; for he can summon a ‘buoyancyobject’, which, when it appears, already has its W1 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 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.

18. Another MOFOR example: when the grid accelerates To simulate flow around accelerating bodies, it is necessary to make the grid accelerate too. In-Form makes this easy. • It must: • make the boundary conditions depend on time; and • 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.

19. Case v207: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.

20. A more unusual example:the ‘In-Form wave tank’ 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.

21. The In-Form wave tank;the mathematical foundation 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 amplitudesigma**2 = g*m*tanh(m*h)g = gravitational accelerationh = mean water depthm = 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.

22. The In-Form wave tank;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 can be recognised. Formula for the potential as function of space and timeform=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*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!

23. The In-Form wave tank;some other clever tricks In order to make sure that the pressures and velocitiesfit the potential-derived values at the boundaries, use is made of the (little-used because little-known)‘greater-than’ patches, i.e.thosewith 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!

24. In-Form computes exact solutions for comparison with numerical computations 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 s202 in the PHOENICS Input-File library In-form enables the numerical and analytical solutions to be compared.

25. In-Form computes exact solutions for comparison with numerical computation 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(form1,form2) ! Useful declarations to shorten lines below (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

26. In-Form computes exact solutions for comparison with numerical computation 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.9e4 and 3.26e4 . Sometimes it’s better to look closely at numbers, not colour plots.

27. Comparison between analytical solutions (concluded) Here then is an extract from the RESULT file: Field Values of SY-T: sy_minus_syth_divided_by_sxth 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 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.

28. Other uses for In-Form connectedwith solid-stress analysis In-Form statements are used in Q1 files to express stress, load or displacement boundary conditions, e.g. in case s202: ***** RIGHT : U - normal ****** char(fU3,fU4,TU2,RU2) RU2=(:R02:/(:LX:^2+YG^2)) TU2=ATAN(YG/:LX:) 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.

29. Representing the atmospheric conditions for wind-farm simulations 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 =: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.

30. Representing the upstream wind-velocity profiles 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: POL6(arg1,arg2,arg3,arg4,arg5,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.

31. Domain partitioning; ‘exporting’ and ‘importing’ via In-Form 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 chemical-plant 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.

32. Using In-Form’s ‘transfer objects’ for import and export 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-objectfile 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)

33. Transfer-object tests, 1 This 2D 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 Librarycase 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

34. Transfer-object tests, 2 This 3D 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-Librarycase 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.

35. Transfer-object tests, 3;three-dimensional and transient 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 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)

36. Transfer-object tests, 4;objects of differing shape and size 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.

37. Transfer-object tests, 5;computers in a room • 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-Formstatements 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)

38. The cabinet temperature distributionenlarged for better visibility

39. Several computers in a room 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 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 .

40. The computer room enlarged

41. A further example: smoke from a room fire spreads through a building 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 how transfer objects are 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

42. The flow of smoke around the building 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, IMTROB1 >OBJ, POSITION, 1.600E+01, 2.200E+01, 1.000E+00 > OBJ, IMPORT, wind1.pob

43. Smoke is imported into another room Here an adjoining room ‘imports’ smoke through its open windows This is library case 862which, 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..

44. In-Form opens new research doors, e.g. to the Population Dimension 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:

45. Built-in population-dimension features of PHOENICS 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.

46. Turbulent jet-mixing within a circular pipe; library case 781 • 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.

47. The results for the conventionally-computed quantities Computed values of usual variables are as expected. Here are the velocity vectors. Here are longitudinal-velocitycontours. 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

48. Results for unconventional quantities: individual-fluid mass fractions Now for the interesting results: individual-fluid mass fractions. Fluid1 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 injected- substance content, Fluid 15.

49. Results for conventional quantities: computed in an unconventional way 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.

50. A calculated pdf at one location in the turbulent jet 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.