Search **web-archive-uk.com**:

Find domain in archive system:

Find domain in archive system:

web-archive-uk.com » UK » C » CHAM.CO.UK Total: 682 Choose link from "Titles, links and description words view": Or switch to
"Titles and links view". |

- CONVERG.HTM

should users introduce via In Form PLANT or their own GROUND coding representations of unusual forces acting on the fluid they should themselves take steps to prevent divergence For example If the In Form source formulation is being employed the with line i e linearisation option should be employed whenever the source formula contains the dependent variable itself b The choice of solution method In three dimensional problems or even two dimensional ones for which NZ exceeds 1 switching from the slab wise to the whole field solution procedure usually promotes convergence This is something which happens automatically if CONWIZ is set true For body fitted co ordinate problems I is always wise to choose the GCV T option for this takes especially accurate account of the departures from orthogonality which may sometimes occur It is especially important for flow over natural terrain problems for steep gradients of just one part of the ground surface may suffice to cause divergence if GCV is left at its default value namely F c The choice of maximum and minimum values Divergence sometimes occurs because near the beginning of a calculation implausibly large positive or negative values of velocity or temperature arise from which the solution procedure cannot recover An example is this It is desired to calculate the steady state flow and tenperature within a living room There is a heat source within the room and there is an open window But air circulation results from natural convection alone The user relies on PHOENICS to find out what the velocity distribution and therefore leaves the initial values at their defaults namely 1 0e At the very first sweep PHOENICS finds that there are cells with the finite heat sources which the user prescribed but no flow to carry the heat away It therefore compute enormous temperatures for those cells and large buoyancy forces ensue especially of the otherwise reasonable Boussinesq approximation is in use Resulting next sweep high velocities trigger divergence The setting of the PIL variables VARMIN and VARMIX can prevent this from occurring Of the two modes of using these variables that which sets limits to the increments variables is the preferable Thus if VARMIN temperature is set to 1 e 11 to trigger that mode and VARMAX temperature to 10 0 deg Celsius the above second sweep divergence will simply be unable to occur d The choice of initial guesses If one knew the solutions to the equations at the start and could insert the corresponding variable field values as initial guesses convergence would be immediate Of course the solutions never are known however if initial guesses can be made which are close to these solutions convergence is likely to be rapid It is therefore usually worthwhile to set values of the initial fields by way of FIINIT which are as close as possible to the expected average values of the solutions It is possible to do even better if the PATCH and INIT commands are used for these

Original URL path: http://www.cham.co.uk/phoenics/d_polis/d_enc/converg.htm (2016-02-15)

Open archived version from archive - COORD.HTM

of the plot You can change the orientation of the plot using the VIEW and UP commands The location of quantities within the solution domain is defined in terms of grid coordinate space I J K For non BFC cases the I J K axes will coincide with X Y Z but for BFC cases the curvilinear nature of the grid may mean that I J K bears a complex

Original URL path: http://www.cham.co.uk/phoenics/d_polis/d_enc/coord.htm (2016-02-15)

Open archived version from archive - CORA3.HTM

variables are not significant for example if radiation is to be ignored the relevant equations are easily eradicated The space co ordinates of CORA3 are either Cartesian x y and z or else cylindrical x r and q CORA3 uses a fixed grid system evaluating variables at locations of fixed x y and z or x r and q These locations are arranged on a rectangular or cylindrical grid the spacing of which may be non uniform The boundaries of the domain of integration can be arbitrary this means that they need not conform to a rectangular or cylindrical shape but may exhibit inclinations curves etc Input Requirements The user of CORA3 specifies the following Geometrical shape of the combustion equipment including details such as i length ii cross sectional dimensions iii location and size of entry ports for fuel and air iv location of size of exit port v size and location of baffles if any A set of thermodynamic transport chemical kinetic and radiative properties of fluids such as specific heat density viscosity diffusivity heat of reaction emissivity etc These quantities may be specified as constant or as a function of local thermodynamic properties Information regarding dependent variables

Original URL path: http://www.cham.co.uk/phoenics/d_polis/d_enc/cora3.htm (2016-02-15)

Open archived version from archive - COSP: Constant Optimising Software Package

118 3 3 2 973 4 4 2 886 5 5 2 832 The task At the start of the searching process an arbitrary initial value 2 has been given and the searching range has been set as 1 J at x 1 8 The task of COSP is to find the best boundary value J at x 1 ideally the value should be 4 which makes the difference between the prediction and experiments be regarded as negligible Results For this case the grid of 40x2 has been used The boundary values chosen by COSP at different number of runs are shown in the table 2 where F is the objective function which is used to measure the difference between predictions and experiments and its tolerance can be specified by the user Table 2 NoRun F J at x 1 1 0 1458 2 00 10 0 109 2 50 50 0 019 4 24 105 0 001 3 99 COSP stopped at 105th run as the tolerance for F has been set to 0 001 The best value at the boundary x 1 found by COSP is 3 99 which is very close to the theoretical value 4 The comparison between the exact solution and the calculated values at x 0 5 for various number of runs are shown in the table 3 Table 3 Pe J 1 J 10 J 50 J 105 J exact 1 2 601 2 790 3 448 3 353 3 357 2 2 576 2 712 3 187 3 118 3 118 3 2 602 2 697 3 023 2 975 2 973 4 2 643 2 704 2 920 2 888 2 886 5 2 677 2 717 2 855 2 835 2 832 The run time for 105 runs took 107 sec on a Petium III 600MHz Case 2 Optimisation of the constants in the wall function for 2D pipe turbulent flow This example is to show how COSP has been applied to a 2D pipe turbulent flow for optimisation of two constants in the wall function calculation Experimental data The following expression by Filonenko has been employed to provide the experimental data with which the PHOENICS predictions should agree DP exp A L 2 Rp 0 065 Rho Wo 2 2 where A 1 1 82 Lg Re 1 64 2 Re Wo 2 Rp Vis L and Rp is the length and radius of the pipe respectively Rho is the density Vis is the viscosity and Wo is the velocity At L 5 m Rp 0 5 m Rho 1 22 kg m3 Vis 1 465E 5 m2 s the values of DP at 6 different velocities W 0 10 20 30 40 50 60 m s are given in the table 4 These values serve a prescribed set of data for the comparison with predictions during the COSP searching process Table 4 NoVar W 0 m s DP exp Pa 1 10 63 489 2 20 221 31

Original URL path: http://www.cham.co.uk/phoenics/d_polis/d_docs/cosp/cosp.htm (2016-02-15)

Open archived version from archive - CYCLIC.HTM

the one in which cyclic boundary conditions are provided Strictly speaking in the x 0 to 360 degree case it is only when flow is expected across the x 0 surface which is the same as the x 360 surface that cyclic boundary conditions are appropriate This would commonly come about as a consequence of some overall swirling motion resulting for example from finite angular velocity in one of the incoming fluid streams If this is not the case ie if no flow is expected to occur across the x 0 surface the appropriate boundary condition is the default zero flux one for a symmetry plane Indeed it would usually then not be necessary to solve over the range x 0 to 360 symmetry considerations will allow a smaller angular extent to be considered Cyclic conditions are appropriate not only when x 0 to 360 is considered but also when repetition is present in the flow to be analysed The general rule is that whenever identical conditions are to be expected at x 0 and x last x and finite flow is to be expected through that surface then the boundaries are cyclic This might occur for example in an otherwise symmetrical cylindrical combustion chamber in which the incoming streams are swirling and into which dilution air is introduced through eight circular apertures equally spaced around the periphery of the chamber at a particular axial distance It is appropriate then to solve from x 0 to 45 degrees ie from the axial plane passing through the centre of one of the apertures to that passing through the centre of the next and to treat the x 0 and 45 surfaces as cyclic The EARTH program automatically calculates the u velocity at the cyclic surface from an appropriate momentum balance equation

Original URL path: http://www.cham.co.uk/phoenics/d_polis/d_enc/cyclic.htm (2016-02-15)

Open archived version from archive - EXIT.HTM

to the vector set menu Exit Photon Help Exit causes the system to quit the current TEXT editor and return to the TEXT menu Remember to save the modification before you exit Exit Photon Help Exit causes the system to quit the current contour setting and return to the CONTOUR menu Exit Photon Help Exit causes the system to quit the current CONTOUR editor and return to CONTOUR sub menu

Original URL path: http://www.cham.co.uk/phoenics/d_polis/d_enc/exit.htm (2016-02-15)

Open archived version from archive - MULTI.HTM

kind of a solver The unstructured linear equations solver is developed on the basis of preconditioned conjugate residuals algorithm 3 By default the LU preconditioning is used User can change it on the 2 step Jacobi preconditioning by setting LSG5 T The LU peconditioning usually provides faster convergence than 2 step Jacobi however it requires more additional memory For this reason 2 step Jacobi preconditioning can be recommended when there is lack of computer memory available 2 5 New Collocated CCM method for CFD problems For the CFD problems MBFGE solver employs CCM solver CCM is a segregated Navier Stokes equation solver based on the collocated grid arrangement and covariant velocity projections as dependent variables The coupling of equations is achieved by a global iteration algorithm which employs SIMPLE like procedure 1 and Rhie Chow like interpolation 8 This entails that cell centered velocity projections Uc Vc and Wc are solved for variables They are aligned with the grid lines The grid line direction in the center of a cell is defined by line connecting the centers of appropriate opposite faces In CCM MBFGE notation the first phase velocities are UC1 VC1 and WC1 thus Q1 should comprise SOLVE UC1 VC1 WC1 command The face centered velocity projections have exactly the same meaning as in the staggered PHOENICS solver they are convection flux velocities However in CCM they are not solved for but calculated using Rhie Chow like interpolation procedure The face centered velocity projections are stored in U1 V1 and W1 respectively Cartesian velocity components UCRT VCRT and WCRT calculated for curvilinear grids are attributed to the cell centers 2 6 Alternative discretisation Schemes for convection The general transport equations solved by PHOENICS includes transient convection diffusion and source terms To derive finite volume equations certain numerical schemes are used for discretisation of these terms see 6 or appropriate entries in POLIS By default the numerical schemes used in MBFGE CCM for the approximation of the diffusion and convection contributions are exactly the same as in standard staggered PHOENICS solver Thus the diffusion convection interaction is accounted for by the hybrid interpolation scheme see DIFCUT entry to PHENC or 6 which resolves into the classical upwind differencing scheme UDS scheme for convection dominant flows The UDS scheme is very robust but in the CFD simulation of the convection dominated physical problems it usually suffers from the severe numerical diffusion which can prevent from receiving the accurate solution especially for the problems with rather strong gradients of variables The collocated MBFGE CCM solver includes a set of optional alternative convection schemes to alleviate the influence of the numerical diffusion by introducing the treatment of the convection terms with a high accuracy The schemes available at present are briefly described below The straightforward approach to increase the approximation order of the UDS scheme for example to second order in SOU scheme 10 or third order in QUICK scheme 11 resulted in algorithms which tend to give rise to random oscillations of the solution in the regions of strong gradients This fact is in the agreement with the conclusion of the Godunov s 1959 theorem 12 concerning the inevitable production of oscillations by linear convective scheme of accuracy higher than first order The MBFGE CCM solver includes as an option QUICK scheme In recent years a set of the non linear algorithms has been proposed by various authors to suppress the parasitic oscillations All these methods are based on the analysis of the local solution behavior and can be described as a sequel to the Godunov s first order Lagrangean scheme 12 The first robust monotonic second order convective scheme was the monotonic piecewise linear scheme MINMOD scheme of Van Leer 13 where the slab averaging of the solved variable is used instead of mesh point values as in Gogunov s scheme and monotonicity is enforced by suitably adjusting the second order terms Better results in resolving the sharp gradient regions were achieved by the monotonic second order upwind algorithm SUPER BB scheme of Roe 14 which has been originally developed for the prediction of the inviscid compressible flows Both schemes belong to the class of TVD schemes TVD stands for Total Variation Diminishing and are included into the CCM MBFGE convection schemes set Among the recently proposed procedures to express and develop TVD schemes it is worth mentioning the notion of NVD Normalized Variable Diagrams of Leonard 15 The NVD representation can significantly simplify the test on whether some convective scheme is TVD or not Using the NVD technique Leonard developed the new SHARP scheme Simple High Accuracy Resolution Program which is a monotonic version of his QUICK scheme Similar to SHARP is the simpler SMART scheme of Gaskell and Lau 16 which is based on piecewise characteristics The MBFGE CCM solver includes as an option SMART scheme The alternative convection schemes are implemented in the CCM MBFGE solver using the deferred correction method It means that all the additional terms arising in the general transport equation after it is discretized using some higher order convection scheme instead of default UDS scheme are calculated on the solution from the previous iteration and added to the source term All the convection schemes available in the CCM MBFGE solver i e QUICK MINMOD SUPER BB and SMART schemes can be applied to any solved variable including collocated velocities provided that the convective term is active for it Details of their activation can be found in p 2 6 3 Activation and use of MBFGE CCM method 3 1 MBFGE CCM library To help and simplify the familiarisation with and learning of the CCM MBFGE method SATELLITE library includes CCM MBFGE library This library can be accessed either through submenu Library of SATELLITE menu or by typing SEELIB F on the SATELLITE command mode prompt The library file resides in D SATELL D OPT D MBFGE subdirectory of main PHOENICS directory Cases included into CCM MBFGE library can be loaded either through submenu Library of SATELLITE menu or by entering LOAD Fnnn where nnn is the case number on the SATELLITE command mode prompt The CCM MBFGE library consists of two parts CCM library and MBFGE library First part includes cases set on one domain grids to run with CCM solver Most of the cases included in it are set to be simulated either with CCM solver or PHOENICS staggered solver to chose the latter user should set PIL variable LCCM defined in Q1 to FALSE The MBFGE library includes cases set on multiblock grids including grids with fine grid grids embedding These cases can be run with MBFGE solver It is recommended to the user to study them not only as examples of MBFGE solver activation but as the examples of the MBFGE grid generation Along with cases set for some CFD problems the CCM MBFGE library includes the case case F150 which is essentially the set of PIL commands to activate solution for collocated covariant velocity projections or CCM MBFGE methods This case can be loaded in Q1 by the following PIL commands NOWIPE T LOAD F150 It is recommended to load it after the grid generation part of a Q1 but before settings of boundary conditions Examples of its use can be found in the most of CCM MBFGE library cases 3 2 Grid generation Both CCM and staggered PHOENICS solvers are based on structured computational grids They can employ grids of three distinct kinds namely cartesian cylindrical polar and curvilinear or BFC The details of the grid specification as well as grid generation using SATELLITE can be found under appropriate entries of PHOENICS manuals TR100 TR200 and TR219 and encyclopedia In addition to SATELLITE user may also employ any other available to him grid generator to build BFC grids That alternative grid generator must be able to create grid file in XYZ format MBFGE solver is based on the computational grids which are built as a union of structured grids created for each of the blocks using the standard grid generation technique Grids are connected through common surfaces At present overlapping is not permitted Cells faces at the interface can be connected either one to one or one to many many must be whole number of cells NOTE that at the surfaces defined as a LINK details see below all cells has to be connected in the same way i e either one to one or one to two or one to three etc If it is desirable to have regions with different connections along the same common surface user should introduce several LINKs instead of one Note the difference between PHOENICS specification of cartesian or cylindrical polar grids and that of curvilinear grids which is important for MBFGE method The first two kinds of grids are defined using fraction arrays there is no special arrays to store coordinate of cells vertices X Y Z arrays On the contrary BFC grids are defined using X Y Z arrays which provides the way to store grid information for all domains of multiblock grid Thus All the multiblock grids or MBFGE grids are defined as the BFC grids in PHOENICS even though the actual geometry of all blocks is cartesian or polar cylindrical At present the generation of the MBFGE grid can be schematically represented as three successive steps grid generation for each of the subdomains stacking of the separate grids into one computational grid and definition introduction of necessary links Let s consider these steps in details implying that SATELLITE will be used for the second and third steps It is possible for the user to create and use alternative grid generator and or GROUND coding for SATELLITE which will incorporate all steps In the latter case it is desirable to obtain additional information which is available from CHAM development team The SATELLITE treats grids for the subdomains independently while stacking them into one MBFGE grid thus all subgrids have to be present in the working directory as separate XYZ files XYZ files should be named as NAME1 NAME2 NAMEn where NAME string of up to four letters is common name for all subgrids of a multiblock grid n is the total number of blocks The numbering order of subgrids is not important All NAMEi files has to be created at the first step or copied from a library of previously created grids If SATELLITE grid generator is used to build subgrids the steps are as follows declare grid as the BFC grid by setting BFC T in Q1 or choosing that grid type from PHOENICS menu introduce necessary PIL commands into Q1 or create geometry in the PHOENICS grid generator menu exit SATELLITE and rename produced XYZ file Note that all subgrids can be created in the single Q1 It can be achieved by dumping each created subgrid to disk by DUMPC NAMEi PIL command All MBFGE examples in the CCM MBFGE library had been created using that method In case of an alternative grid generator user should follow its instructions to create subgrids and write them to disk in PHOENICS XYZ format Once all subgrids had been created it is possible to proceed to the second step As a result of this step SATELLITE will stack separate subgrids together and create single MBFGE computational grid It is achieved by the following PIL commands BFC T NUMBLK n READCO NAME READCO command will read in NUMBLK XYZ files with names NAME1 NAMEn and put them them into single grid file using rules described in pp 2 1 and 2 2 By default subgrids are stacked by SATELLITE either along Z axis or along X axis for cases set in X Y plane It is possible to change the stacking direction by specifying the new one in the argument of READCO READCO NAME X or READCO NAME Y or READCO NAME Z Note that for 2D cases the alternative direction must be present The third step consists in the definition of necessary links which is achieved by the MBLINK commands The formats of MBLINK command are as follows MBLINK m SOUTH n NORTH or MBLINK j IN k First command defines LINK between domain m at its SOUTH side and domain n at its NORTH side while the second defines domain j as embedded into domain k After processing READCO NAME and MBLINK commands SATELLITE creates PATCHes with MBD and MBL names accordingly see pp 2 1 and 2 2 User can check positions of defined PATCHes by investigating contents of RESULT file after the run of EAREXE to initialize Q1 contents print out into RESULT file user should put ECHO T in it It can be recommended to check positions of LINK PATCHes introduced by SATELLITE before proceeding to the setting and simulation of the problem itself To summarize the MBFGE grid generation consider possible scheme of Q1 which incorporates three steps described above Create local grids for all defined subdomains BFC T GSET D NX1 NY1 NZ1 LX1 LY1 LZ1 GSET commands necessary to create grid for the 1st somain DUMPC MBGR1 GSET D NX2 NY2 NZ2 LX2 LY2 LZ2 GSET commands necessary to create grid for the 2nd somain DUMPC MBGR2 And so on for all domains NOTE separate grids might be created using SATELLITE menu Combine local grids into the single computational space NUMBLK N READCO MBGR Set necessary links between subdomains MBLINK 2 IN 1 MBLINK 2 EAST 3 WEST etc All examples of Q1 in MBFGE library are built according to that scheme 3 3 MBFGE CCM activation The PIL commands used for the CCM MBFGE activation may be divided into four groups First group comprises settings which has to be used to activate CCM MBFGE solver and are the same with minor variations for all MBFGE or CCM cases The second group includes setttings which are used to define grid geometry type The third group consists of switches to activate special techniques available in CCM MBFGE high order convection schemes the NX 1 simulation of swirling flows etc The first and second groups are described in this paragraph The third type settings are detailed in pp 3 6 and 3 7 All other PIL commands which are usually used in Q1 and are not specific to CCM MBFGE for example initialization of variables activation of various physical models etc may be attributed to the fourth group Their description can be found under appropriate entries of PHENC Some notes on their use for MBFGE can be found in pp 3 4 and 3 5 PIL commands to activate CCM MBFGE solver are as follows Settings common for CCM and MBFGE CSG3 LCRU This line activates CCM MBFGE solver the problems is simulated by CCM MBFGE algorithm using LU preconditioned conjugate residuals solver as linear equation solver The latter might be substituted by 2 step Jacobi preconditioned one if LSG5 T Activate if necessary solution for collocated velocities SOLVE UC1 VC1 WC1 Activate whole field solution for all solved variables for example SOLUTN P1 Y Y Y P P P etc Additional setting for MBFGE Store volume porosity STORE VPOR PIL commands to specify the kind of geometry for CCM MBFGE solver are as follows For the CCM solver or one domain simulation all standard PIL variables are valid to specify the type of orthogonal geometry CARTES T cartesian grid CARTES F polar cylindrical grid BFC T orthogonal curvilinear grid By default all MBFGE grids are treated as cartesian despite the fact that BFC T There is special variable to specify the grid as curvilinear thus switch on the appropriate treatment LSG3 T orthogonal curvilinear grid The treatment of nonorthogonal grids in CCM MBFGE solvers is different from that in PHOENICS To activate this treatment user should use the following commands NONORT F LSG3 T LSG4 T NOTE LSG3 T settings is necessary only if convection is present in the case For the case with diffusion only LSG4 T is enough 3 4 Activation of physical models and built in source terms Most of physical models built in or GREX coded sources for scalar variables and models to introduce thermo physical properties of media available for PHOENICS solver are also available for CCM MBFGE solver User should refer to the approprite encyclopedia entry to find the description of PIL commands necessary to activate the model under question The list of available models includes Calculation of thermophysical properties of gases fluids and solids through PROPS file and GREX subroutines The built in pressure source term in the enthalpy or temperature balance equation Conjugate heat transfer model All available in PHOENICS models of turbulence except Reynolds stress and flux transport model NOTE necessary boundary condition should be set for the collocated velocity projection instead of the stagerred ones Coriolis forces for horizontal flows which are activated by CORIOL parameter At present CHEMKIN GENTRA stresses in solids model and radiation model based on the view factors calculation are not available for use with CCM MBFGE There are certain differences in the activation of the following physical models Centrifugal and coriolis forces due to the frame rotation can be introduced in two ways For CCM case set on polar cylindrical grid user may define ROTA patch as for PHOENICS solver but with COVAL command for collocated velocity projections and specify values of ANGVEL ROTAXA ROTAYA ROTAZA ROTAXB ROTAYB and ROTAZB see appropriate entry to PHENC For any other type of CCM MBFGE grids including mentioned above case user should only specify values of ANGVEL ROTAXA ROTAYA ROTAZA ROTAXB ROTAYB and ROTAZB special patch is not necessary Buoyancy force for CCM MBFGE is also introduced without special patch The cartesian components of the gravity acceleration should be set as for PHOENICS solver BUOYA Gx BUOYB Gy BUOYC Gz There are the following options of buoyancy source term BUOYD 0 and BUOYE 0 sets the source term equal to Rho G resolute BUOYD 0 and BUOYE 0 sets the source term equal to Rho Rho ref G resolute where Rho ref BUOYE BUOYD 0 and BUOYE 0 sets the source term equal to Rho Beta T ref T G resolute where T ref BUOYE and Beta BUOYD while T can be either temperature or enthalpy IBUOYB 0 and IBUOYC 0 sets the source term equal to Rho BUOYA BUOYB F IBUOYB BUOYC F IBUOYC More details of the coriolis and centrifugal as well as buoyancy forces activation can be found in MBFGRN FOR file which resides in phoenics d earth d opt d mbfge subdirectory In general if some physical model available as part of PHOENICS installation or coded by user for PHOENICS solver is implemented as an algorithm user should consult CHAM development team to check for its applicability to CCM MBFGE There are the following rules for the models based on additional source terms to PHOENICS equations which can be used to check on whether or not some model in question can be applied without modifications to CCM or MBFGE Special consideration should be given to the velocity components or projections used if any in the model If model is based on calculations of derivatives of some stored variable it needs modification to provide proper treatment of linked boundaries This modification can be done using LINK subroutines described in p 3 8 3 5 Initial and boundary conditions In CCM MBFGE solver initial and boundary conditions as well as additional sources are introduced in exactly the same manner as these for PHOENICS solver Thus user should specify appropriate PATCHes and set COVAL statements for solved variable However there are certain differences described below No slip boundary conditions should be applied to all solved collocated velocity projections UC1 VC1 or WC1 To specify uniform initial flow field on curvilinear grids or set inlet at the curvilinear surface details can be found either in PHENC or source file of GXBFC subroutine user should set GRND2 as VALue for P1 UC1 VC1 and WC1 instead of GRND1 for PHOENICS solver For MBFGE grids user may use MPATCH command instead of standard PATCH It has the following format MPATCH NB NAME TYPE IXF IXL IYF IYL IZF IZL ITF ITL Here NB is the number of the domain at which the patch NAME is set Other arguments have exactly the same meaning as for PATCH The difference is in the fact that IXF IXL IZL should be specified as IX IY IZ local for NB domain SATELLITE will process MPATCH and transform IXF IXL IZL into global IX IY IZ according to the stacking used by it NOTE in the RESULT file all MPATCHes are printed out as standard PATCHes with global IX IY IZ 3 6 Use of alternative convection schemes At present the following high order numerical schemes are included in CCM MBFGE solver as optional instead of default UDS scheme for the approximation of convection terms QUICK scheme by Leonard 11 MINMOD scheme by Van Leer 13 SUPER BB scheme by Roe 14 SMART scheme by Gaskell and Lau 16 Details of the mathematical formulation of these schemes can be found either in the appropriate references or in the entry SCHeMe of PHOENICS encyclopedia Current implementation has the following main features Any alternative convection algorithm is applied to the whole computational domain i e up to domain boundaries All the possible obstacles in the computational domain are treated automatically It is understood by the obstacle blockage the settings of VPOR to 0 or PRPS to solid value or the face porosities EPOR NPOR HPOR to 0 All patches related to the convection transport of the variable under consideration are treated automatically To activate the alternative convection treatment in the MBFGE CCM solver user should set LSG7 T in Q1 Than it is necessary to provide the information on which scheme must be applied to what solved variable It should be done by introducing into Q1 the following lines SCHMBEGIN VARNAM VAR1 SCHEME MINMOD VARNAM VAR2 SCHEME SUPERB VARNAM VAR3 SCHEME SMART VARNAM VAR4 SCHEME QUICK SCHMEND Here SCHMBEGIN and SCHMEND are keyword brackets VARNAM and SCHEME fixed keywords VAR1 VAR4 are the names of solved variables and MINMOD SUPERB SMART or QUICK are keywords to designate the appropriate numerical algorithm which will be applied to the variable provided that convection term for it is active It is necessary to note the following If the variable is solved but its name is not included in that list the convection term for it is treated by the default UDS scheme High order convection schemes can be applied as to all solved scalar variables like KE EP temperature etc as well as to the collocated velocities UC1 VC1 or WC1 User can apply either the same scheme to all solved variable with active convection terms or use any mixture of schemes For example UC1 and VC1 are treated by SUPERB scheme while KE and EP by MINMOD scheme By default alternative convection schemes are applied to the variable starting from the first solution sweep However user can specify other sweep as a starting point by assigning its number to the ISG1 variable in Q1 User is advised to study various examples of schemes activations and use which can be found in MBFGE CCM library 3 7 Activation and use of special options 3 7 1 Swirling flow simulation The CCM MBFGE module provides special option for the simulation of laminar or turbulent swirling flows taking place in axisymmetric geometries The problem should be defined and set as 2D problem using Z as axis of symmetry Y as radial direction and X as circumferential direction NX 1 Along with VC1 and WC1 velocity projections which are normally solved for in the cases set in Y Z plane user should activate solution for UC1 Set no slip or other suitable boundary conditions for UC1 To activate treatment of UC1 as swirling velocity component user should specify in Q1 file LSG6 T Other CCM MBFGE variables for example LSG4 to activate the traetment of nonorthogonality etc should be set according to the problem under consideration Examples of cases set to simulate swirling flows using described option can be found in CCM MBFGE library cases 105 and 110 for CCM cases 208 and 215 for MBFGE NOTE that swirling flow problems can be simulated as 3D problem NX 1 without using LSG6 variable However if the flow is uniform in circumferential direction the speed of convergence is very low For these reason 3D simulation of swirling flows can be recommended only if there are flow variations in circumferential direction 3 7 2 Sliding grid simulation The MBFGE method provides the special type of a link to simulate the flows which take place in domains one part of which is moving in respect to the other That type of flows can be found for example in stirring reactors turbines etc The fact that one domain is moving in respect to the other is accounted for by the SLIDING link and special patch which covers the moving domain Sliding link is introduced by changing the standard part of the link patch i e MBL to MBS For example the following link between domain M and N is sliding MPATCH m MBSm n NORTH 1 NXm NYm NYm 1 NZm 1 LSTEP MPATCH n MBSn m SOUTH 1 NXn 1 1 1 NZn 1 LSTEP At present only one sliding link per multi block grid is permitted by MBFGE solver Moreover the sliding link has to be introduced between the NORTH face of one domain and SOUTH face of the other domain It means for example that the geometry of the multi block grid to represent the rotation of one domain in respect to the other should be build using X as circumferential coordinate Y as readial direction and Z as axis of rotation see MBFGE library cases 218 219 and 220 There two patches with fixed names SLIDRT and SLIDMV to mark the moving domain see cases 218 219 220 and 221 MPATCH n SLIDRTn CELL 1 NXn 1 NYn 1 NZn 1 LSTEP MPATCH n SLIDMVn CELL 1 NXn 1 NYn 1 NZn 1 LSTEP Both patches should be set to cover the whole extent of the moving domain Patch SLIDRT marks domain as rotating domain Values of angular velocity and position of the axis of rotation are set through PIL variables ANGVEL ROTAXA ROTAYA ROTAZA ROTAXB ROTAYB and ROTAZB see ROTA entry to PHENC and library cases The angular velocity vector is directed along Z axis angular velocity is positive when rotation of cartesian X axis to Y axis is counter clock wise as seen from the end of the vector Patch SLIDMV marks domain as domain which moves along the surface of other domain with transitional velocity U Its value is passed to MBFGE solver through PIL variable RSG2 Positive U value means that the domain is moving in the positive direction of X axis In transitional cases and rotational cases set for only a sector of axisymmetric geometry user should introduce XCYCLE condition It is achieved by using READCO Y command and choosing the same number of cells across the sliding link see library cases 3 7 3 Darcy flows Current release of CCM MBFGE method includes special treatment to provide for Darcy flows simulation There is no special switch to turn it on The treatment is automatically activated once user set patches on UC1 VC1 or WC1 to introduce flow resistance Case 108 in CCM MBFGE library gives an example of the Darcy flow simulation 3 7 4 Shallow flow models The CCM MBFGE module provides two special models for the simulation of shallow flows The 3D flow can be defined as shallow if its geometrical size in one dimension or depth is much smaller than the sizes in two other dimensions The water flows in rivers or sea bays are examples of shallow flows In general that kind of flows can be simulated using full 3D Navier Stokes equations by CCM MBFGE solver However the fact that the flow depth is much smaller than the characteristic width and length can be used to simplify the Navier Stokes equations and provide more robust algorithm NOTE that at present the coordinate direction adopted as shallow in CCM MBFGE module is that along Z axis It means that only the cases set using Z to define flow depth can be treated by CCM MBFGE shallow flow option There are two logical parameters to activate shallow water models available in the CCM MBFGE module The parameters and the models are described below LSG8 when set to TRUE activates the 2D shallow flow model for the solution of 3D Navier Stokes equations The 2D shallow flow model consists in the following The pressure correction equation is solved in 2D form which is deduced from the full 3D equation by integrating along the Z direction Accordingly the Wc velocity component is calculated by the integrating the continuity equation The momentum equations for Uc and Vc components are solved in the 3D form However certain terms which has Depth Length order and thus they are negligible for the shallow flows are omitted Transport equations for all other solved variables are solved in ordinary 3D form LSG10 when set to TRUE activates the 3D shallow flow model for the solution of 3D Navier Stokes equations This model consists in the following The momentum equations for Uc Vc and Wc velocity components are solved in the truncated form The truncation is related to the terms which has Depth Length order of magnitude It should be noted that the form of Uc and Vc equations is exactly the same as mentioned above for 2D shallow model All the other equations including the pressure correction equation are solved in the standard 3D form NOTE that 2D shallow flow model is implemented for CCM problems only i e for one domain simulations and can not be used for multiblock grids The 3D shallow flow model LSG10 T can be used as for CCM as for MBFGE cases Examples of the use of the 2D and 3D shallow flow models for a 3D flow simulation can be found in the CCM MBFGE library 3 8 GROUND influence on CCM MBFGE calculations The CCM MBFGE module can be influenced by user in practically the same manner as all others PHOENICS modules Thus the presentation of this paragraph is based on the presumption that the reader is well familiar with main rules of FORTRAN programming for PHOENICS If it is not the case user should start reading from appropriate paragraphs of PHOENICS lectures manuals or encyclopedia entries Two kind of FORTRAN module are accessible to the user the MAIN program of EARTH and GROUND GREX subroutines There are only two parameters in the MAIN program which are specific for dimensioning the arrays used in MBFGE module NDM set the maximum number of blocks in the MBFGE grid NDMB set the maximum number of links per block By default NDM 10 and NDMB 6 The user may increase decrease these values and rebuild EARTH in the standard way All the ways to influence EARTH through FORTRAN coding introduced into GROUND GREX subroutines are also available to the user of CCM MBFGE method i e user may modify solved equations by adding new source terms or modifying coefficients introduce necessary thermo dynamic properties of media set complex boundary conditions and etc The general rules of the use of GROUND groups of retrieving placing information from to F array and of the work with PHOENICS arrays indices are exactly the same as in standard EARTH However there are several remarks worth mentioning Momentum equations solved in CCM MBFGE module are formulated for collocated velocity components UC1 VC1 and WC1 Accordingly all the related modifications should be introduced into equations solved for UC1 VC1 or WC1 Block location indices for collocated velocities may be easily retrieved using LBNAME function for example IUC1 LBNAME UC1 CCM method works on one domain grids thus FORTRAN coding may be created in absolutely the same manner as for standard PHOENICS solver MBFGE method differs from CCM in the presence of linked cells For a writer of GROUND coding it basically means that special attention should be paid to the way of getting values from the neighboring cells Accordingly if user GROUND coding involves only in cell calculations i e formulae to be coded do not include derivatives of variables then the FORTRAN coding can be created using the same technique as for standard PHOENICS For the GROUND coding which involves inter cell calculations the user should use a set of special subroutines provided in MBFGE for links treatment These subroutines are described below The organisation of the solution algorithm in CCM MBFGE method differs from that in staggered PHOENICS solver For this reason user should pay special care to the modifications which can affect it There is a set of special subroutines to provide the user with the tools for the treatment of links in GROUND coding It includes the following subroutines and functions Logical functions LDMN IX IY IZ returns TRUE if IX IY IZ cell belongs to one of the domains It can be also used for CCM than it returns TRUE if 1 IX NX 1 IY NY and 1 IZ NZ LLINK0 IJK returns TRUE if IJK cell has at least one link IJK is a whole field index of IX IY IZ cell i e IJK IY IX 1 NY IZ 1 NX NY LLINK IDIR IJK returns TRUE if IJK cell has a link in the IDIR direction IDIR has the same meaning as for PHOENICS solver namely IDIR 1 corresponds to NORTH direction 2 SOUTH 3 EAST 4 WEST 5 HIGH and 6 LOW Integer functions LINKD IDIR IJK NF NL returns the direction of the linked face for the cells from NF to NL linked to the IDIR face of a current IJK cell NOTE call to LINKD must be preceded by the call to GETFLI moreover the signs of NF NL are important Real functions SSCLNK IDIR IJK ISC0 returns an average value of the scalar variable for the cells linked to the IDIR face of a current IJK cell Here ISC0 is absolute zero location index of the variable for slab wise arrays it is zero location index of the first slab Sign of IJK defines type of the variable if IJK 0 then ISC0 variable is slab wise else it is whole field There are two types of averaging if ISC0 0 then SSCLNK returns volume average else it returns an arithmetic average Subroutines GETFLI IDIR IJK NF NL returns first NF and last NL indices of cells linked to the IDIR face of the current IJK cell NF NL IJK are whole field indices NOTE that GETFLI can be called only if LLINK IDIR IJK is true NOTE that NF NL could be negative for unnatural links GETIJK IJK NX NY IX IY IZ returns IX IY and IZ for a whole field index IJK NOTE IJK must be positive There is also set of auxiliarily subroutines which can be used in GROUND coding for CCM MBFGE module These subroutines provide check for the presence of blocked cells in the computational region and they can be subdivided into two groups the subroutines to carry out check for a current cell and that to check neighboring cells Current cell is treated as blocked if the value of VPOR 0 or value of PRPS SOLPRP The cell neighboring to the current cell is treated as blocked if it has either VPOR 0 or PRPS SOLPRP or if the value of face porosiry array in the appropriate direction is zero All subroutines are pared the other subroutine in a pair does not check for PRPS value if the variable under consideration is a temperature TEM1 or TEM2 The

Original URL path: http://www.cham.co.uk/phoenics/d_polis/d_enc/multi.htm (2016-02-15)

Open archived version from archive - SCHEMES FOR CONVECTION DISCRETIZATION

5 r 2 HQUICK harmonic QUICK B r 2 r r r 3 OSPRE B r 3 r 2 r 2 r 2 r 1 VANL2 or VANLH B r r r r 1 VANALB B r r 2 r r 2 1 MINMOD B r max 0 min r 1 SUPBEE Superbee B r max 0 min 2 r 1 min r 2 UMIST bounded QUICK B r max 0 min 2 r 0 25 0 75 r 0 75 0 25 r 2 HCUS B r 1 5 r r r 2 CHARM bounded QUICK B r r 3r 1 r 1 2 for r 0 B r 0 for r 0 4 Implementation in PHOENICS a What the user must do When the user has decided which discretization scheme he wishes to use for each solved for variable he should either make his selection via the General Menu or insert the appropriate SCHEME command in the Q1 file as follows SCHEME scheme name variable name 1 variable name 2 etc That is all because everything else is performed automatically including to mention those things which become visible the creation of the patch command PATCH HOCS CELL 1 NX 1 NY 1 NZ 1 LSTEP and corresponding COVALs for example COVAL HOCS H1 FIXFLU GRND1 b What happens thereafter The coding which is activated thereby when EARTH execution starts is in the open source GXHOCS F file which forms part of the advanced numerical algorithms option The file contains subroutine GXHOCS and its ancillary subroutines GXHOEN GXHOHL GXFLPS and BLKSLD The acronym HOCS stands for higher order convection schemes This coding ensures that extra source terms are supplied at each relevant cell and for each relevant variable to make up the differences between the effects of the in EARTH default convection fluxes and those which are appropriate to the selected schemes One detail to note is that when ANY use of schemes is made the in EARTH default becomes the upwind rather than the hybrid scheme This is effected by the automatically made setting DIFCUT 0 0 The treatment is valid for non uniform meshes and for body fitting coordinates Waterson 1994 c Some details of the GXHOCS coding In Group 1 Section 1 GXHOCS forms the array INLCS NPHI and allocates storage for several geometrical quantities The array INLCS contains an integer which defines for each variable the scheme selected by the user in Q1 via the SCHEME PIL command In Group 1 Section 2 GXHOCS computes and stores the position vectors for all cells in the solution domain as these are required in Group 13 for BFC calculations In Group 13 the deferred correction source terms are calculated in Section 13 for linear schemes and in Section 14 for non linear schemes Subroutine GXHOEN computes the east west and north south cell face contributions to the source term and Subroutine GXHOHL computes the low and high cell face contributions Subroutine GXFLPS is called directly from Subroutines GXHOEN and GXHOHL so as to calculate the flux limiter function for the non linear schemes Function BLKSLD is used by subroutines GXHOEN and GXHOHL so as to detect the presence of blocked faces and solid cells within the stencil used to calculate the higher order correction for a single cell face If BLKSLD is TRUE then no higher order correction is calculated and the scheme reduces to the UDS 5 Performance of the schemes a An example Cases N121 and N122 from the PHOENICS Input File Library enable the performance of all the schemes to be compared Both concern the computation of the value of a scalar variable downstream of a point source in a stream of uniform velocity which has a direction diagonal to the grid from south west to north east The second makes a comparison with the Conservative Low Dispersion Algorithm and it allows the angle of the flow to be varied The concentrations of the scalar will be displayed The exact solution which the CLDA can produce perfectly would consist of a diagonal band with the value of the scalar equal to 10 5 with zero value regions on either side The two points to examine are does the band spread unduly and do the values lie within the range from 10 5 to 0 Note The figures displayed result from an older version of library case n122 however the conclusions remain valid as can be seen by running the current version of that case UDS The expected numerical diffusion is evident but the range of values from 0 to 10 5 is correct UDS LUS Numerical diffusion is low but a negative value of 0 2 appears and the maximum is only 7 8 LUS FROMM Numerical diffusion is low but a negative value of 1 5 appears The maximum value is nearly correct FROMM CUS Numerical diffusion is low but a negative value of 2 7 appears and maximum of 12 7 CUS QUICK Numerical diffusion is low but a negative value of 3 8 appears and a maximum of 14 6 QUICK CDS As expected of the central difference scheme these results are unsatisfactory from all points of view CDS SMART Numerical diffusion is low and the upper and lower limits are correct SMART KOREN Numerical diffusion is low and the upper and lower limits are correct KOREN VLEER1 Numerical diffusion is low and the upper and lower limits are correct VLEER1 HQUICK Numerical diffusion is low and the upper and lower limits are correct hquick OSPRE Numerical diffusion is low but the upper limit is 14 0 OSPRE VLEER2 Numerical diffusion is low and the upper and lower limits are correct VLEER2 VANALB Numerical diffusion is low but the upper limit is 11 7 VANALB MINMOD Numerical diffusion is low and the upper and lower limits are correct MINMOD SUPBEE Numerical diffusion is very low and the upper and lower limits are correct SUPBEE UMIST Numerical diffusion is low and the

Original URL path: http://www.cham.co.uk/phoenics/d_polis/d_enc/enc_schm.htm (2016-02-15)

Open archived version from archive

web-archive-uk.com, 2016-10-22