The General Collocated Velocity
method (GCV) solves the flow equations in
body-fitted geometries in a way which differs from the PHOENICS-standard one in important respects.
Distinguishing features of the GCV method are:
Library cases B570 and B571 illustrate this.
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.
The solver works in a block-by-block manner, but takes the links between blocks into account implicitly, thus providing fast convergence.
It should be noted that, like the other conjugate-gradient solvers with which PHOENICS is equipped, GCV is incompatible with the use of MIGAL.
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 (which is not recommended!), the following rules must be followed:
Example - solving for Cartesian components:
PATCH (BFCIN, type, ixf, .... COVAL (BFCIN, P1, FIXFLU, GRND3) COVAL (BFCIN, UC1, ONLYMS, UCRTin) COVAL (BFCIN, VC1, ONLYMS, VCRTin) COVAL (BFCIN, WC1, ONLYMS, WCRTin) COVAL (BFCIN, UCRT, ONLYMS, UCRTin) COVAL (BFCIN, VCRT, ONLYMS, VCRTin) COVAL (BFCIN, WCRT, ONLYMS, WCRTin)
Example - solving for Covariant projections (i.e. resolutes):
PATCH (BFCIN, type, ixf, .... COVAL (BFCIN, P1, FIXFLU, GRND3) COVAL (BFCIN, UC1, ONLYMS, GRND3) COVAL (BFCIN, VC1, ONLYMS, GRND3) COVAL (BFCIN, WC1, ONLYMS, GRND3) COVAL (BFCIN, UCRT, ONLYMS, UCRTin) COVAL (BFCIN, VCRT, ONLYMS, VCRTin) COVAL (BFCIN, 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 collocated 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.
To set up a multi-block 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:
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;
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 multi-block settings is given in Multi-block Grid and Block Linkage Definition for GCV.
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
The third image
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.
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 F. 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'.
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.
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, patches must be defined for the collocated 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.
Some special care is needed when multi-block GCV runs are to be re-started. The reason, and what to do, are explained here,
wbs