Also added the new prghTotalHydrostaticPressure p_rgh BC which uses the
hydrostatic pressure field as the reference state for the far-field
which provides much more accurate entrainment is large open domains
typical of many fire simulations.
The hydrostatic field solution is controlled by the optional entries in
the fvSolution.PIMPLE dictionary, e.g.
hydrostaticInitialization yes;
nHydrostaticCorrectors 5;
and the solver must also be specified for the hydrostatic p_rgh field
ph_rgh e.g.
ph_rgh
{
$p_rgh;
}
Suitable boundary conditions for ph_rgh cannot always be derived from
those for p_rgh and so the ph_rgh is read to provide them.
To avoid accuracy issues with IO, restart and post-processing the p_rgh
and ph_rgh the option to specify a suitable reference pressure is
provided via the optional pRef file in the constant directory, e.g.
dimensions [1 -1 -2 0 0 0 0];
value 101325;
which is used in the relationship between p_rgh and p:
p = p_rgh + rho*gh + pRef;
Note that if pRef is specified all pressure BC specifications in the
p_rgh and ph_rgh files are relative to the reference to avoid round-off
errors.
For examples of suitable BCs for p_rgh and ph_rgh for a range of
fireFoam cases please study the tutorials in
tutorials/combustion/fireFoam/les which have all been updated.
Henry G. Weller
CFD Direct Ltd.
e.g. (fvc::interpolate(HbyA) & mesh.Sf()) -> fvc::flux(HbyA)
This removes the need to create an intermediate face-vector field when
computing fluxes which is more efficient, reduces the peak storage and
improved cache coherency in addition to providing a simpler and cleaner
API.
The boundary conditions of HbyA are now constrained by the new "constrainHbyA"
function which applies the velocity boundary values for patches for which the
velocity cannot be modified by assignment and pressure extrapolation is
not specified via the new
"fixedFluxExtrapolatedPressureFvPatchScalarField".
The new function "constrainPressure" sets the pressure gradient
appropriately for "fixedFluxPressureFvPatchScalarField" and
"fixedFluxExtrapolatedPressureFvPatchScalarField" boundary conditions to
ensure the evaluated flux corresponds to the known velocity values at
the boundary.
The "fixedFluxPressureFvPatchScalarField" boundary condition operates
exactly as before, ensuring the correct flux at fixed-flux boundaries by
compensating for the body forces (gravity in particular) with the
pressure gradient.
The new "fixedFluxExtrapolatedPressureFvPatchScalarField" boundary
condition may be used for cases with or without body-forces to set the
pressure gradient to compensate not only for the body-force but also the
extrapolated "HbyA" which provides a second-order boundary condition for
pressure. This is useful for a range a problems including impinging
flow, extrapolated inlet conditions with body-forces or for highly
viscous flows, pressure-induced separation etc. To test this boundary
condition at walls in the motorBike tutorial case set
lowerWall
{
type fixedFluxExtrapolatedPressure;
}
motorBikeGroup
{
type fixedFluxExtrapolatedPressure;
}
Currently the new extrapolated pressure boundary condition is supported
for all incompressible and sub-sonic compressible solvers except those
providing implicit and tensorial porosity support. The approach will be
extended to cover these solvers and options in the future.
Note: the extrapolated pressure boundary condition is experimental and
requires further testing to assess the range of applicability,
stability, accuracy etc.
Henry G. Weller
CFD Direct Ltd.
fvOptions does not have the appropriate structure to support MRF as it
is based on option selection by user-specified fields whereas MRF MUST
be applied to all velocity fields in the particular solver. A
consequence of the particular design choices in fvOptions made it
difficult to support MRF for multiphase and it is easier to support
frame-related and field related options separately.
Currently the MRF functionality provided supports only rotations but
the structure will be generalized to support other frame motions
including linear acceleration, SRF rotation and 6DoF which will be
run-time selectable.
Relaxation and solution parameters for the final iteration in PIMPLE loops are
now selected according to the value of the "finalIteration" entry in the
mesh::data dictionary.
rhoPimpleFoam significantly updates and now replaces rhoPisoFoam.