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