- Introduction.
- Activation of the GCV method
- Multi-block Settings
- Sliding-Grid Settings
- Control Switches and Default Settings
- Convergence Advice
- Limitations and Ground Coding
- The Application Album entries
- Restarting multi-block runs

The **G**eneral **C**ollocated **V**elocity
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:

- A block-structured
**multi-block**formulation can be used. - GCV can handle
**highly non-orthogonal**grids, being able to secure convergence with included angles as small as 10 degrees, which is much better then is achievable by the standard BFC formulation available in PHOENICS.Library cases B570 and B571 illustrate this.

- The link formulation can handle
**arbitrary block rotations**in computational space. This allows the creation of an unstructured multi-block 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' (
*i.e.*the 'resolutes' of the absolute velocity in the three cell-centre-joining directions), 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 pressure-velocity 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.

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:

- Set GCV=T
- In addition to solution of U1, V1 and W1, solution for the collocated velocities should be activated.(SOLVE(UC1,VC1,WC1) )
- All boundary conditions must be set for the collocated velocities, (UC1, VC1, WC1), and not for U1, V1 or W1.
- Wall functions must be set for all solved collocated velocities, not just those parallel to the wall.
- 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 (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:

- n,m - block numbers;
- ABCD,EFGH - arbitrary letters to distinguish 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 co-ordinates.

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

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 cross-piece.

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