Presentation on theme: "PHOENICS User Meeting, Paris, 2008 In-Form In-Form the INput of data via FORMulae It represents the third stage in the process of enabling users to extend."— Presentation transcript:
PHOENICS User Meeting, Paris, 2008 In-Form In-Form the INput of data via FORMulae It represents the third stage in the process of enabling users to extend the simulation capability of PHOENICS in any direction they choose.. things of before 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.
PHOENICS User Meeting, Paris, 2008 In-Form In-Forms predecessors The previous two stages were: 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. 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. 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 re- compilable version of PHOENICS.
PHOENICS User Meeting, Paris, 2008 In-Form 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; sources 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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. 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. That is all that the user has to do; and even this labour can be reduced if PRELUDE is employed (of which more later).
PHOENICS User Meeting, Paris, 2008 In-Form 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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 5 th -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.
PHOENICS User Meeting, Paris, 2008 In-Form 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.
PHOENICS User Meeting, Paris, 2008 In-Form Nusselt numbers deduced from empirical formulae 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)) 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 users choice. 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 In-Form 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: shell-side tube-side overall wherein: areadvol is area divided by volume, coes, coet and coeu are the three coefficients, etc. (stored var coes is areadvol* nuss*cond/diam) (stored var coet is areadvol* nust*cont/diam) (stored var coeu is coes* coet/(coes+coet)) Recall: all this from Q1 statements alone!
PHOENICS User Meeting, Paris, 2008 In-Form Assistance with the understanding of print-out: In-Forms 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 users convenience. More could be provided. Users suggestions are welcome.
PHOENICS User Meeting, Paris, 2008 In-Form 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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
PHOENICS User Meeting, Paris, 2008 In-Form 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 previous slide showed xce linear with time and yce quadratic. Hence the parabolic trajectory. The PATCH arguments allow the sphere to travel anywhere; and the SPHERE function has coordinates and radius as arguments
PHOENICS User Meeting, Paris, 2008 In-Form An example: library case 766; a parabolic trajectory (continued) 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. 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.
PHOENICS User Meeting, Paris, 2008 In-Form An example: library case 766; a parabolic trajectory (concluded) The answer is that it could be programmed to do so; but only for particular trajectories. But remember Rodins 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. But thats so difficult, some may say. Why cant the VR- Editor enable me to set up the problem by way of dialogue boxes?
PHOENICS User Meeting, Paris, 2008 In-Form In-Form sources written by PRELUDE: a source of vertical velocity caused by buoyancy In such circumstances, buoyancy plays an important role. How is it to be introduced? The picture shows what a user might see when using PRELUDE to set up the simulation of heat and air flow in a room. 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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 buoyancy object, 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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: 1.make the boundary conditions depend on time; and 2.Create a body force everywhere. Case v207 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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 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 In-Form 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.743 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*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 Its tedious to type; but easier than Fortran or c++ programming!
PHOENICS User Meeting, Paris, 2008 In-Form The In-Form wave tank; 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 (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 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 librarys202 In-form enables the numerical and analytical solutions to be compared.
PHOENICS User Meeting, Paris, 2008 In-Form 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
PHOENICS User Meeting, Paris, 2008 In-Form 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 its better to look closely at numbers, not colour plots.
PHOENICS User Meeting, Paris, 2008 In-Form 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.
PHOENICS User Meeting, Paris, 2008 In-Form Other uses for In-Form connected 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: ***** 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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,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.
PHOENICS User Meeting, Paris, 2008 In-Form 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 aredumped 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 In-Form Using In-Forms 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-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)
PHOENICS User Meeting, Paris, 2008 In-Form 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 Library case 856.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
PHOENICS User Meeting, Paris, 2008 In-Form 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-Library case 858., in whichcase 858. 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 In-Form 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:case 859 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)
PHOENICS User Meeting, Paris, 2008 In-Form 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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-Form statements are:case 863 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)
PHOENICS User Meeting, Paris, 2008 In-Form The cabinet temperature distribution enlarged for better visibility
PHOENICS User Meeting, Paris, 2008 In-Form 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:case 864 (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, Paris, 2008 In-Form The computer room enlarged
PHOENICS User Meeting, Paris, 2008 In-Form 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:case 860 > 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
PHOENICS User Meeting, Paris, 2008 In-Form 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.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
PHOENICS User Meeting, Paris, 2008 In-Form Smoke is imported into another room 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.862 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 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:
PHOENICS User Meeting, Paris, 2008 In-Form 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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 Zhubrins model in terms of In-Form in 2001. Library case 781 uses Zhubrins 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 In-Form The results for the conventionally- computed 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
PHOENICS User Meeting, Paris, 2008 In-Form Results for unconventional quantities: individual-fluid mass fractions the 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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.
PHOENICS User Meeting, Paris, 2008 In-Form 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.
PHOENICS User Meeting, Paris, 2008 In-Form How the 17-fluid model is created by In-Form statements The case-781 Q1 contains all the necessary statements; some of these will now be showncase-781 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 GENG/(2.0*:RHO1:*EPKE+TINY)-G)) Its tedious to disentangle; but becomes clear in the end. 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
PHOENICS User Meeting, Paris, 2008 In-Form How collision (i.e. coupling & splitting) 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* (F3+F5+F7+F9+F11+F13+F15+F17)*(0.-F1) with LINE) ! How (SOURCE of F3 at iMIX is 2.*:MMC:*EPKE*(F2*F4+F1*F5)- :MMC:*EPKE*(F1+F17+F5+F7+F9+F11+F13+F15)*F3) Fluid 3 is both created and destroyed. Here is Zhubrins proposal for its nett source: 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 Fluid 1 is never created, only destroyed by colliding with fluids 3, 5, 7, 9, 11, etc. Not 4, 6, 8 etc. ? Thats Zhubrins concept; the built-in MFM allows more; In-Form users decide for themselves.
PHOENICS User Meeting, Paris, 2008 In-Form More of the same 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(SUM1,SUM2) SUM1=(F8*F10+F7*F11+F6*F12+F5*F13+F4*F14+F3*F15+ F2*F16+F1*F17) 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))
PHOENICS User Meeting, Paris, 2008 In-Form What have we learned from the study of case 781? That PHOENICS is capacious enough to enable users to introduce new stored or solved-for variables at will. 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 Thinkers code. 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.
PHOENICS User Meeting, Paris, 2008 In-Form When the fluids do not all have the same density 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 Q1 allows this: (property rho1 is (f1+f17)*1.0+(1.-f1-f17)*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 In-Form More results when density of new- created fluids has been reduced to 0.1 Here is the resulting distribution of mixture-average density; here is the consequent velocity- vector 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 In-Form 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 In-Form 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 2D 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 In-Form 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? CHAMs 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