The General Colocated Velocity Method (GCV) is an alternative
algorithm for solving the Navier-Stokes equations in body-fitted
geometries.
Distinguishing features of the GVC method are:
it is tolerant of highly skewed grids;
it has an unstructured multi-block capability;and
a sliding grid option.
Its solver is robust and efficient.
(Other relevant PHENC entries are: Multi-Block and Colocated
Cartesian Velocities.)
Contents of this Entry on GCV
Opening Remarks
Activation of the GCV method
Multiblock Settings
Sliding-Grid Settings
Control Switches and Default Settings
Convergence Advice
Limitations
1. Opening Remarks - Novelty of GVC
Few things are fundamentally novel; and GCV is no different, because
it employs KNOWN:
colocated pressures and velocities;
Cartesian velocity components as variables (in one option);
a SIMPLE-type solution algorithm;
a conjugate-residual-gradient linear-equation solver;
the PHOENICS data structure and user interface.
The speed of convergence and numerical accuracy ARE novel,
surpassing all three of the other treatments of PHOENICS
(viz. improved-staggered-grid, CCM, and CCV).
The true novelty resides in the DETAIL of implementation, and the
care taken to employ accurate geometric formulae.
When to choose the GCV method
Normally the staggered-grid approach is to be preferred.
Three reasons for this are:
calculations involving staggered grids use more information
and are therefore inherently better;
the staggered-grid approach is more robust; and,
calculations close to solid boundaries tend to be more accurate.
However there are geometries where the GCV method performs better than
the staggered-grid approach, namely:
when highly-skewed grids are present;
when unstructured multiblock grids are employed; and,
when the sliding grid option is actived in PHOENICS.
Tolerance of Highly-Skewed grids
The GCV method has been formulated with poor-quality grids
especially in mind.
Convergence can be obtained with included angles as small as 5
degrees. This is not possible with any of the other BFC formulations
available in PHOENICS.
Examples of highly-skewed grids in the BFC Input-File Library are:
Flow in a duct with choice of skew angle (Case B570)
Cavity with moving lid, choice of angle (Case B571)
The link description can handle arbitrary block rotations in
computational space.
This permits the creation of an unstructured multiblock grid
from relatively simple structured bocks, which can be generated
individually.
There are two common approaches to introduce domain decomposition
in a computational domain: with and without overlapping cells. For
GCV, the multiblock link description is based on the overlapped-grid
conception.
Multiblock Settings
To set up a multiblock case, the user should specify grids for
each block and use the READCO command (see Section 3) to
assemble the blocks.
Extra cells in the 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.
The sliding grid option in PHOENICS permits the simulation of problems
where a computational grid is divided into two parts, one of which
rotates around an axis and one of which is at rest.
An example of flow-simulation, where the sliding grid option is used,
can be found as Library case B578.
For this example to be run using the GCV method, the command GCV=T
has to be included in Q1
GCV can solve for either the cell-centred Cartesian velocities or
the cell-centred covariant velocity projections, without influencing
the result in any way.
The choice between using cell-centred Cartesian velocities and
the cell-centred covariant velocity projections is made by setting
the control switch LSG2 to the appropriate logical value.
If LSG2 = T then the cell-centred covariant velocities will be
solved for.
The default is to solve for cell-centred Cartesian velocities
(LSG2=T), but for swirling flows, and sliding grids, it is more
convenient to solve for covariants as they lie in the local grid
directions.
Solver Strategy
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
generalized 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.
GCV works for body-fitted grids, so the logical variable BFC
must be set to T (TRUE). Cartesian and polar cases can be solved
with GCV, by forcing the Satellite to create an equivalent BFC grid.
The user has to only set GCV=T.
Indeed, most existing Q1 files can be converted for use by the GCV
method, simply by the addition of the GCV=T statement.
The adjustments necessary for calculation using the GCV method will
be made on exit from Satellite, unless the colocated velocities are
already present. If that is the case, Satellite assumes that Q1 is
already correctly set, and will make no further additions.
The Q1 is always written out un-modified. The adjustments are only
written to EARDAT, but may be checked for correctness by inspection
of the RESULT printout.
Inserting GCV settings directly into Q1
If a user wishes to make the GCV settings directly in the Q1,
the following rules must be followed:
a) Set GCV=T
b) In addition to solution of U1, V1 and W1, solution for the
colocated velocities should be activated.(SOLVE(UC1,VC1,WC1) )
c) All boundary conditions must be set for the colocated velocities,
(UC1, VC1, WC1 ), rather than for U1, V1 or W1.
d) Wall functions must be set for all solved colocated velocities,
not just those parallel to the wall.
Inserting GCV settings directly into Q1 (continued)
e) 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.
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. They do not have to
be explicitly set in Q1.
Important notes
If the Cartesian velocity option is taken, the covariant velocities
still have to be specified in the boundary conditions, as these are
the velocities solved for in the GCV algorithm.
For the Cartesian velocity option, the velocities UCRT, VCRT and WCRT
create the boundary conditions necessary to calculate the mass flux
for the pressure correction equation.
In the covariant projection option, the velocities UCRT, VCRT and WCRT
are used both for the calculation of mass flux for the pressure
correction equation, and as boundary conditions for the calculations
of the UC1, VC1 and WC1 velocities.
3. Multiblock settings
To set up a multiblock case, the user should specify grids for
each block and use the READCO command (described below) 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.
Using the READCO Command
READCO is the PIL command which reads the corner coordinates of a
body-fitted grid from a file.
In multi-block cases, it is used to read a sequence of block grid
files, and assemble them into a single computational space. If
the grid files for three blocks are BLK1, BLK2 and BLK3, they
would be assembled with:
NUMBLK=3
READCO(BLK+)
By default, the 'stacking' of blocks to form the single computational
space is in the K (IZ) direction. Stacking in the I or J directions
can be forced with READCO(BLK+X) or READCO(BLK+Y).
Input File to READCO Format
The grids for each block can be created in Satellite in the normal
way.
Once created, the command DUMPC will write out a grid file. The argument
of DUMPC is the name of thefile to be written. Thus
DUMPC(BLK1)
will create the grid file BLK1.
The mesh generation, including DUMPC, is repeated for each block.
Each block canbe generated by a separate Q1, or all can be done
in a single file, as the user finds convenient.
Definition of links
READCO assembles the blocks, but does not create links between
them. This is done as follows.
All links are defined as pairs of commands using the following
format:
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.
When blocks are rotated
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.
If some blocks are to rotate relative to others, extra patches with
names starting MBS... should be specified. These patches should cover
the rotating blocks.
Rotation is always about the Cartesian Z axis.
The single link between the stationary and rotating blocks must form
the first pair of MBL patches if there is more than one link.
The PIL variable RSG2 defines the rotation speed in radians
per second. A clockwise rotation when viewed along the +ve
Z axis, looking toward the origin (VIEW Z in PHOTON) is
obtained by a -ve value of RSG2.
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)
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 commponents.
When set to T, the covariant velocity will be solved for.
This switch is available from the General menu. The sliding grid
option requires LSG2=T. Occasionaly, 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 avaialable from the General Menu.
Control Switches and Default Settings (continued)
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.
LSG8
controls which interpolation is used in estimating the fluxes on
the control volume faces. The default (LSG8=F) is Carteseian
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 avaialable from the General Menu.
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.
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
The following PHOENICS features are not available in the current
implementation of GCV:
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).
Further Limitations
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
Similarily, LBNAME('UC1') must be used in place of U1 in L0F and
FN routine CALLs.
