advertisement

GENERAL COLOCATED VELOCITY METHOD (GCV) Contents 1. Introduction. 2. Activation of the GCV method 3. Multiblock Settings 4. Sliding Grid Settings 5. Control Switches and Default Settings 6. Convergence Advice 7. Limitations and Ground Coding 8. The Application Album entries 9. Restarting multi-block runs 10. Summary of LSGx settings 1.Introduction The General Collocated Velocity method (GCV) is an alternative algorithm for solving the Navier-Stokes equations in body-fitted geometries. Distinguishing features of the GCV method are: A block-structured multi-block implementation, with a capability to tackle highly non-orthogonal grids. Convergence can be obtained with included angles as small as 10 degrees, which is better then is achievable by any of the other BFC formulations available in PHOENICS. Library cases B570 and B571 illustrate this capability. The link description can handle arbitrary block rotations in computational space. This allows the creation of an unstructured multiblock grid from relatively simple structured blocks, which can be generated individually (see library case B572 for example). The multi-block link description is based on the over-lapped grid concept; but it requires the extra cell only in computational space, not in physical space. A sliding-grid option enables the simulation of problems where a computational grid is divided into two parts, namely a part which rotates around the Z axis and a part which is at rest. (see library case B578) The choice to solve for either the cell-centre Cartesian velocities or the cell-centre covariant velocity projections, without influencing the result in any way. The choice of either Cartesian or contravariant interpolations for the estimation of mass fluxes on the control volume faces. The contravariant velocity components are used as face velocities. The method uses a segregated pressure-based solver strategy with an additional correction of cell-centre momentum velocity components, which provides faster convergence in comparison with the standard one-step face velocity correction. The pressurevelocity coupling algorithm is based on a linearisation which is similar to the well known SIMPLEC procedure, and is generalised for arbitrary BFC geometries. The linear equation solver is based on the conjugate-residual algorithm with LU preconditioning. The solver works in a block-by-block manner, but takes the links between blocks into account implicitly, thus providing fast convergence. 2. Activation of the GCV method Click here for the input-file library, In the Q1 file, the PIL logical GCV when set to T will activate the GCV method. In the General menu, the GCV method can be activated from the 'Variables to be solved /Equation formulation' panel. GCV only works for body-fitted grids, so the logical variable BFC must be set T (TRUE). Cartesian and polar cases can be solved with GCV, by inserting BFC=T after the grid generation commands, but before the SOLVE commands. If the Q1 is created as normal, Satellite will translate the settings into those required by GCV. This allows most existing Q1 files to be converted to GCV simply by the addition of the GCV=T statement. It also allows the General Menu to be used to create a Q1 file for use with GCV. If a user wishes to make the GCV settings directly in the Q1 (not recommended!), the following rules must be followed: 1. Set GCV=T 2. In addition to solution of U1, V1 and W1, solution for the colocated velocities should be activated.(SOLVE(UC1,VC1,WC1) ) 3. All boundary conditions must be set for the colocated velocities, (UC1, VC1, WC1), and not for U1, V1 or W1. 4. Wall functions must be set for all solved colocated velocities, not just those parallel to the wall. 5. BFC inlet patch names must begin with BFC as usual. The VALUE for P1 in the COVAL statement must be GRND3. GRND3 must be also used to specify inlet covariant velocity projections. Example - solving for Cartesian components: PATCH COVAL COVAL COVAL COVAL COVAL COVAL COVAL (BFCIN, (BFCIN, (BFCIN, (BFCIN, (BFCIN, (BFCIN, (BFCIN, (BFCIN, type, ixf, .... P1, FIXFLU, GRND3) UC1, ONLYMS, UCRTin) VC1, ONLYMS, VCRTin) WC1, ONLYMS, WCRTin) UCRT, ONLYMS, UCRTin) VCRT, ONLYMS, VCRTin) WCRT, ONLYMS, WCRTin) Example - solving for Covariant projections: PATCH COVAL COVAL COVAL COVAL COVAL COVAL COVAL (BFCIN, (BFCIN, (BFCIN, (BFCIN, (BFCIN, (BFCIN, (BFCIN, (BFCIN, type, ixf, .... P1, FIXFLU, GRND3) UC1, ONLYMS, GRND3) VC1, ONLYMS, GRND3) WC1, ONLYMS, GRND3) UCRT, ONLYMS, UCRTin) VCRT, ONLYMS, VCRTin) WCRT, ONLYMS, WCRTin) In addition, all variables will be automatically solved in the whole-field way, and all TERMS for U1,V1 and W1 will be deactivated. These changes are imposed by EARTH if GCV=T, so do not have to be explicitly set in Q1. The translation will be made on exit from satellite, unless the colocated velocities are already SOLVEd or STOREd. In that case, Satellite assumes that the Q1 is already correctly set, and will make no further translations. For this reason, it is best to make all settings in Q1 as if for a normal BFC case, and let Satellite perform all the necessary translations. The Q1 is always written out un-modified. The translations are only written to EARDAT, and can be checked for correctness by inspection of the RESULT ECHO printout. 3. Multiblock settings To set up a multiblock case, the user should specify grids for each block and use the READCO command to assemble the blocks. Extra cells in computational space must be reserved to provide links between the blocks. The geometry for these extra cells does not have to be defined. Only those block faces which are linked to another block (or blocks) need an extra layer of cells. Blocks may be connected in any arbitrary way to other blocks, and/or to themselves. There is no limit to the number of times a block can be linked to another block or to itself. All blocks must be right-handed in physical and computational space. It is not possible to recalculate the normal links during a transient run. All links are defined as pairs of commands using the following format: MPATCH(n,MBLnABCD,typ1,if1,il1,jf1,jl1,kf1,kl1,1,1) MPATCH(m,MBLmEFGH,typ2,if2,il2,jf2,jl2,kf2,kl2,1,1) where: n,m - block numbers; ABCD,EFGH - arbitrary letters to differ one patch from another; typ1,typ2 - patch types (EAST,WEST,NORTH,SOUTH,LOW,HIGH ); i1f,i1l... and i2f,i2l...patch boundaries, in local block IJK coordinates. If the blocks share the same orientation in IJK space, no further settings are needed. If the blocks are rotated relative to each other in IJK space, the block alignment must be specified. This is done with the following command: SPEDAT(SET, GCV, MBLmEFGH, C, ABC) where; MBLmEFGH - name of the second patch, ABC - character string which defines the rotation. SET, GCV, C - required settings. The string defining the block rotation consists of three letters, which may be any of E W N S H L. The individual characters define the relative orientation between the N, E and H faces of the first block of the pair of blocks, and the current block respectively. The default setting is SWL, denoting 'natural' connections. The string ENL would define the connection NORTH->EAST, EAST->NORTH and HIGH->LOW. Examples: ---------------------| E | |N Block 2 S| | W | ---------------------------------------| N | H | |W Block 1 E|N Block 3 S| | S | L | ---------------------------------------- Block 1 - 2 MPATCH (1, MBL1A, NORTH, ...... MPATCH (2, MBL2A, WEST, ...... SPEDAT (SET, GCV, MBL2A, C, WNL) Block 1 - 3 MPATCH (1, MBL1B, EAST, ...... MPATCH (3, MBL3B, NORTH, ...... SPEDAT (SET, GCV, MBL3B, C, LNE) ---------------------| E | |N Block 2 S| | W | ---------------------------------------| N | H | |W Block 1 E|N Block 3 S| | S | L | ---------------------------------------- Block 2 - 3 MPATCH (2, MBL2C, WEST, ...... MPATCH (3, MBL3C, HIGH, ...... SPEDAT (SET, GCV, MBL3C, C, SLE) A full description of the multiblock settings is given in Multi-block Grid and Block Linkage Definition for GCV. 4. Sliding Grid Settings One group of blocks is allowed to rotate relative to another group of blocks. The sliding interface must always be between one stationary and one rotating block. A patch with the name MBS... should be specified for each rotating block. These patches should cover the complete rotating blocks including any dummy edge cells. The link between the outermost rotating block and the innermost stationary block must form the first pair of MBL patches if there is more than one link. The name of the link patch linking the sliding block to the stationary block must be passed to EARTH with the command: SPEDAT(SET, GCVSLD, name_of_patch, L,T) For example, if block 1 is rotating, and block 2 is stationary, the complete link commands would be: MPATCH(1, MBL1.2, NORTH, ...... MPATCH(2, MBL2.1, SOUTH, ...... SPEDAT(SET, GCVSLD, MBL1.2, L,T) MPATCH(1, MBS1, CELL, 1,NX, 1,NY, 1,NZ, 1,LSTEP) The grid distribution along the sliding link must be uniform, and identical on the outer surface of the rotating block, and inner surface of the stationary block. The inner surface will 'click' by one cell relative to the outer surface each time step. This is shown in the following two images. Image 1 shows the grid at the start of the calculation, and image 2 shows the grid after 1/4 rotation. The third image shows the flow field generated by the central crosspiece. Non-uniform grids along the sliding link are tolerated, but the solution will not be exact. The PIL variable RSG2 defines the rotation speed in radians per second. The axis of rotation is always the Z axis (i.e. a line passing through the points (0,0,0) and (0,0,1)). Only clockwise rotation when viewed along the +ve Z axis, looking toward the origin, (VIEW Z in PHOTON) is allowed. All surfaces inside the rotating block should be covered by patches with names starting with ROT... . This will activate boundary condition calculations based on the local surface velocity. ( see library case B578) Sliding grid cases must be solved in transient mode. Only the total number of steps need be set in Q1, as EARTH will calculate the time step size based on the rotation speed and number of cells along the sliding link. Furthermore, sliding grid cases must be solved in the Cartesian frame, i.e. with LSG2=F (the default). Incorrect solutions will be obtained if grid-directed (covariant) components are used (LSG2=T). Note that grid files dumped during the run will contain the rotated geometry. 5. Control Switches and Default Settings LSG1 controls the pressure-velocity coupling method to be used. The non-default option, LSG1=T, often requires some linear relaxation for pressure. LSG2 controls whether Cartesian velocity components or covariant velocity projections are solved. When set to F (the default), GCV will solve for the Cartesian velocity components. When set to T, the covariant velocity will be solved for. This switch is available from the General menu, 'Variables solved/Auxiliary data for GCV'. The sliding grid option requires LSG2=T. Occasionally, convergence will be easier with covariant velocities. LSG5 controls the algorithm employed in calculating the metric coefficients. The default is False. The setting of LSG5=T may help with convergence with highly skewed grids. This switch is available from the General Menu, 'Variables solved/Auxiliary data for GCV'. LSG6 when set to T allows simulation of axisymmetrical problem with NX=1 and swirling flow. In this case the swirling flow component, UC1, will be the covariant velocity projection regardless of the setting of LSG2. This switch is set automatically by Satellite when NX=1, CARTES=F and U1 is solved. LSG8 controls which interpolation is used in estimating the fluxes on the control volume faces. The default (LSG8=F) is Cartesian velocity interpolation. LSG8=T switches to contravariant velocity interpolation. LSG9 controls whether the additional correction of the cell centre velocity is active. By default LSG9=F, there are no corrections. This switch is available from the General Menu, 'Variables solved/Auxiliary data for GCV'. RSG1 sets the linear relaxation factor for the face (contravariant) velocity components. The default is 0.75, but highly skewed grids may require smaller values. This factor is available from the General Menu, 'Variables solved/Auxiliary data for GCV'. 6. Convergence Advice Experience to date has shown that linear relaxation for pressure is only required when LSG1=T, or if the fluid is compressible. For velocities and scalars the inertial factor, dtf, should be 10 or 100 times the DOMAIN residence time. For turbulence, the KELIN=3 linearisation with linear relaxation of 0.5 for KE and EP is recommended. 7. Limitations and Ground Coding The following PHOENICS features are not available in the current implementation of GCV: Fine grid embedding; Two-phase IPSA; GENTRA; Earth generated wall functions (EGWF); SEM; HOL; ASM; ASAP; S2SR; CHEMKIN; Parallel Solver. Users can use Ground coding to provide extra source terms in the momentum equations. For this the patches must be defined for the colocated velocities, and the source term implementation must take into account the choice of the dependent variables for the momentum equations (Cartesian component or covariant velocity projections). Although Satellite will translate COVAL(name, U1, GRND, GRND) to COVAL(name, UC1, GRND, GRND), the user must ensure that statements such as: IF (INDVAR.EQ.U1) THEN ... ENDIF are replaced by: IF(INDVAR.EQ.LBNAME('UC1')) THEN ... ENDIF Similarly, LBNAME('UC1') must be used in place of U1 in L0F and FN routine CALLs. 8. Restarting multi-block runs Some special care is needed when multi-block GCV runs are to be restarted. The reason, and what to do, are explained here, 9. Summary of LSGx settings LSG1 wbs