for e.g. load-balancing. The fvMeshDistributor is selected via the new optional
distributor entry in dynamicMeshDict, e.g.
distributor
{
type decomposer;
libs ("libfvMeshDistributors.so");
}
Note that currently only the framework is included in this commit, the
fvMeshDistributors library is not yet fully functional and hence not released
yet.
This improves convergence of some steady-state chtMultiRegionFoam (which uses
the pEqn.H from buoyantPimpleFoam) cases but does not affect transient
simulations unless aggressive pressure relaxation is applied, i.e. transient
SIMPLE.
When limiting the pressure in p_rgh based solvers p typically has calculated BCs
which are now supported when calculating the max and min pressure from maxFactor
and minFactor.
The surfaceVectorField Uf is used instead of the flux field phi for ddtPhiCorr
in moving mesh cases to handle linear and rotating motion and must mapped from
the volVectorField U to new faces created by cell splitting or merging in mesh
refinement/unrefinement.
With the general run-time selectable fvMeshMovers engine compression simulations
can be performed with reactingFoam so there is no longer any need for engine
specific solvers or engineMesh.
An engineFoam script is provided to redirect users to reactingFoam with
instructions.
PDRFoam is a Xi combustion model solver including porosity distributed
resistance and shares code with XiFoam so it is more logical that it should be
in a sub-directory of XiFoam to simplify compilation dependency.
With the general run-time selectable fvMeshMovers engine compression simulations
can be performed with rhoPimpleFoam so there is no longer any need for engine
specific solvers.
A coldEngineFoam script is provided to redirect users to rhoPimpleFoam with
instructions.
With the addition of mesh-motion to XiFoam and the new engine fvMeshMover the
XiEngineFoam kivaTest simple IC engine example now runs in XiFoam and
XiEngineFoam has been removed. This simplifies maintenance provides greater
extensibility.
with the run-time selectable engine userTime embedded in Time.
All parts of the original engineTime relating to the engine geometry have been
moved to engineMesh. This is part of the process of integrating engine
simulations within the standard moving-mesh solvers.
The floatingObject tutorial has been update to demonstrate this functionality by
adding the following topoChanger entry to dynamicMeshDict:
topoChanger
{
type refiner;
libs ("libfvMeshTopoChangers.so");
// How often to refine
refineInterval 1;
// Field to be refinement on
field alpha.water;
// Refine field in between lower..upper
lowerRefineLevel 0.001;
upperRefineLevel 0.999;
// Have slower than 2:1 refinement
nBufferLayers 1;
// Refine cells only up to maxRefinement levels
maxRefinement 1;
// Stop refinement if maxCells reached
maxCells 200000;
// Flux field and corresponding velocity field. Fluxes on changed
// faces get recalculated by interpolating the velocity. Use 'none'
// on surfaceScalarFields that do not need to be reinterpolated.
correctFluxes
(
(phi none)
(nHatf none)
(rhoPhi none)
(alphaPhi.water none)
(meshPhi none)
(ghf none)
);
// Write the refinement level as a volScalarField
dumpLevel true;
}
Note that currently only single rigid body motion is supported (but multi-body
support will be added shortly) and the Crank-Nicolson scheme is not supported.
This boundary condition specifies a slip velocity on moving walls. It
works similarly to movingWallVelocity, except that the tangential
velocity is not constrained. It can be specified as follows:
<patchName>
{
type movingWallSlipVelocity;
value uniform (0 0 0); // Initial value
}
Description
Limits the specified pressure field to be between specified minimum and
maximum limits.
Usage
Example usage:
\verbatim
limitp
{
type limitPressure;
// p p_rgh; // Optional entry to specify the pressure
min 200;
max 500;
}
\endverbatim
MULES no longer synchronises the limiter field using syncTools. Surface
boundary field synchronisation is now done with a surface-field-specific
communication procedure that should result in scaling benefits relative
to syncTools. This change also means that the limiter does not need to
be continuous face field which is then sliced; it can be a standard
surface field.
Description
Evolves a passive scalar transport equation.
- To specify the field name set the \c field entry
- To employ the same numerical schemes as another field set
the \c schemesField entry,
- The \c diffusivity entry can be set to \c none, \c constant, \c viscosity
- A constant diffusivity is specified with the \c D entry,
- If a momentum transport model is available and the \c viscosity
diffusivety option specified an effective diffusivity may be constructed
from the laminar and turbulent viscosities using the diffusivity
coefficients \c alphal and \c alphat:
\verbatim
D = alphal*nu + alphat*nut
\endverbatim
Example:
\verbatim
#includeFunc scalarTransport(T, alphaD=1, alphaDt=1)
\endverbatim
For incompressible flow the passive scalar may optionally be solved with the
MULES limiter and sub-cycling or semi-implicit in order to maintain
boundedness, particularly if a compressive, PLIC or MPLIC convection
scheme is used.
Example:
\verbatim
#includeFunc scalarTransport(tracer, diffusion=none)
with scheme specification:
div(phi,tracer) Gauss interfaceCompression vanLeer 1;
and solver specification:
tracer
{
nCorr 1;
nSubCycles 3;
MULESCorr no;
nLimiterIter 5;
applyPrevCorr yes;
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-8;
relTol 0;
diffusion
{
solver smoothSolver;
smoother symGaussSeidel;
tolerance 1e-8;
relTol 0;
}
}
\endverbatim
With this change each functionObject provides the list of fields required so
that the postProcess utility can pre-load them before executing the list of
functionObjects. This provides a more convenient interface than using the
-field or -fields command-line options to postProcess which are now redundant.
