Horizontal mixers have been renamed to mixerVesselHorizontal2D. The
incompressible mixerVessel2D has been reinstated to provide a comparison
with the corresponding MRF case. All rotational speeds have been
standardised at 60 rpm, except for the compressible case in which the
higher speed is justified in order to demonstrate the simulation of
compressibility effects.
The codedFunctionObjectTemplate is based on regionFunctionObject requiring
fvMesh.H and most manipulate volFields so it makes sense for volFields.H to be
included by default.
genericPatches is linked into mesh generation and manipulation utilities but not
solvers so that the solvers now check for the availability of the specified
patch types. Bugs in the tutorials exposed by this check have been corrected.
Two pitzDaily variants have been added; pitzDailySteadyMappedToPart, and
pitzDailySteadyMappedToRefined. These demonstrate usage of workflows
which involve mapping between cases with mapFieldsPar.
The pitzDailySteadyMappedToPart case demonstrates mapping onto a small
section of the mesh; in this case in the vicinity of the the corner of
the backstep. This mesh is not consistent with the source data, so
fields are required in the zero directory and cutting patches are used
to specify the properties at the inlets.
The pitzDailySteadyMappedToRefined case demonstrates mapping onto a
geometrically similar case with a different mesh density. This mesh is
consistent with the source, so no fields are needed and no cutting
patches are used. This case does, however, perturb the geometry of the
block mesh a bit, so that some of the refined case is not overlapping
the original case. This provides a test of the stabilisation
procedures within the mesh-to-mesh mapping functions.
The '-region' option has been leveraged to significantly simplify the
meshing and decomposition in the movingCone cases. These cases have also
been corrected to restore the variation in decomposition between the
different meshes, which is important for thoroughly testing the patch
field mapping. The shockFluid case has also had its duration extended a
little in order to span the final mesh mapping time.
The keyword 'select' is now used to specify the cell, face or point set
selection method consistently across all classes requiring this functionality.
'select' replaces the inconsistently named 'regionType' and 'selectionMode'
keywords used previously but backwards-compatibility is provided for user
convenience. All configuration files and tutorials have been updated.
Examples of 'select' from the tutorial cases:
functionObjects:
cellZoneAverage
{
type volFieldValue;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
writeInterval 1;
fields (p);
select cellZone;
cellZone injection;
operation volAverage;
writeFields false;
}
#includeFunc populationBalanceSizeDistribution
(
name=numberDensity,
populationBalance=aggregates,
select=cellZone,
cellZone=outlet,
functionType=numberDensity,
coordinateType=projectedAreaDiameter,
allCoordinates=yes,
normalise=yes,
logTransform=yes
)
fvModel:
cylinderHeat
{
type heatSource;
select all;
q 5e7;
}
fvConstraint:
momentumForce
{
type meanVelocityForce;
select all;
Ubar (0.1335 0 0);
}
This is a more intuitive keyword than "funcName" or "entryName". A
function object's name and corresponding output directory can now be
renamed as follows:
#includeFunc patchAverage
(
name=cylinderT, // <-- was funcName=... or entryName=...
region=fluid,
patch=fluid_to_solid,
field=T
)
Some packaged functions previously relied on a "name" argument that
related to an aspect of the function; e.g., the name of the faceZone
used by the faceZoneFlowRate function. These have been disambiguated.
This has also made them consistent with the preferred input syntax of
the underlying function objects.
Examples of the changed #includeFunc entries are shown below:
#includeFunc faceZoneAverage
(
faceZone=f0, // <-- was name=f0
U
)
#includeFunc faceZoneFlowRate
(
faceZone=f0 // <-- was name=f0
)
#includeFunc populationBalanceSizeDistribution
(
populationBalance=bubbles,
regionType=cellZone,
cellZone=injection, // <-- was name=injection
functionType=volumeDensity,
coordinateType=diameter,
normalise=yes
)
#includeFunc triSurfaceAverage
(
triSurface=mid.obj, // <-- was name=mid.obj
p
)
#includeFunc triSurfaceVolumetricFlowRate
(
triSurface=mid.obj // <-- was name=mid.obj
)
#includeFunc uniform
(
fieldType=volScalarField,
fieldName=alpha, // <-- was name=alpha
dimensions=[0 0 0 0 0 0 0],
value=0.2
)
so that the same option with a rational name is also available for #includeModel
and #includeConstraint. Support for funcName is maintained for
backwards-compatibility.
particleFoam has been superseded and replaced by the more general functions
solver module executed by the foamRun application:
foamRun -solver functions
The incompressibleFluid solver specified by either the subSolver or if not
present the solver entry in the controlDict is instantiated to provide the
physical fields needed by fvModel functionObject in which the clouds fvModel is
selected to evolve the Lagrangian particles. See:
tutorials/modules/incompressibleFluid/hopperParticles
tutorials/modules/incompressibleFluid/mixerVessel2DParticles
rhoParticleFoam has been superseded and replaced by the more general functions
solver module executed by the foamRun application:
foamRun -solver functions
The isothermalFluid solver specified by either the subSolver or if not present
the solver entry in the controlDict is instantiated to provide the physical
fields needed by fvModel functionObject in which the clouds fvModel is selected
to evolve the Lagrangian particles.
Description
Solver module to execute the \c functionObjects for a specified solver
The solver specified by either the \c subSolver or if not present the \c
solver entry in the \c controlDict is instantiated to provide the physical
fields needed by the \c functionObjects. The \c functionObjects are then
instantiated from the specifications are read from the \c functions entry in
the \c controlDict and executed in a time-loop also controlled by entries in
\c controlDict and the \c maxDeltaT() returned by the sub-solver.
The fields and other objects registered by the sub-solver are set to
NO_WRITE as they are not changed by the execution of the functionObjects and
should not be written out each write-time. Fields and other objects created
and changed by the execution of the functionObjects are written out.
solvers::functions in conjunction with the scalarTransport functionObject
replaces scalarTransportFoam and provide more general handling of the scalar
diffusivity.
The new optional PIMPLE control transportPredictionFirst is used to select if
the transport modelling predictor is executed ever PIMPLE iteration or only on
the first, which is the default.
Also the transportCorr() function has been renamed correctTransport() for
consistency and the tutorials updated to use the new control name
transportCorrectionFinal instead of the previous name turbOnFinalIterOnly;
support for turbOnFinalIterOnly is maintained for backwards-compatibility.
angleUnits is a more logical name for the user-input as it specifies the units
of the angles written rather than the format of the numbers. The previous name
angleFormat is supported for backwards-compatibility
Class
Foam::functionObjects::rigidBodyState
Description
Writes the rigid body motion state.
Usage
\table
Property | Description | Required | Default value
type | type name: rigidBodyState | yes |
angleUnits | degrees or radians | no | radians
\endtable
Example of function object specification:
\verbatim
rigidBodyState
{
type rigidBodyState;
libs ("librigidBodyState.so");
angleUnits degrees;
}
\endverbatim
Class
Foam::functionObjects::sixDoFRigidBodyState
Description
Writes the 6-DoF motion state.
Example of function object specification:
\verbatim
sixDoFRigidBodyState
{
type sixDoFRigidBodyState;
libs ("libsixDoFRigidBodyState.so");
angleUnits degrees;
}
\endverbatim
Usage
\table
Property | Description | Required | Default value
type | type name: sixDoFRigidBodyState | yes |
angleUnits | degrees or radians | no | radian
\endtable
The timeName() function simply returns the dimensionedScalar::name() which holds
the user-time name of the current time and now that timeName() is no longer
virtual the dimensionedScalar::name() can be called directly. The timeName()
function implementation is maintained for backward-compatibility.
A set of routines for cutting polyhedra have been added. These can cut
polyhedral cells based on the adjacent point values and an iso-value
which defines the surface. The method operates directly on the
polyhedral cells; it does not decompose them into tetrahedra at any
point. The routines can compute the cut topology as well as integrals of
properties above and below the cut surface.
An iso-surface algorithm has been added based on these polyhedral
cutting routines. It is significantly more robust than the previous
algorithm, and produces compact surfaces equivalent to the previous
algorithm's maximum filtering level. It is also approximately 3 times
faster than the previous algorithm, and 10 times faster when run
repeatedly on the same set of cells (this is because some addressing is
cached and reused).
This algorithm is used by the 'isoSurface', 'distanceSurface' and
'cutPlane' sampled surfaces.
The 'cutPlane' sampled surface is a renaming of 'cuttingPlane' to make
it consistent with the corresponding packaged function. The name
'cuttingPlane' has been retained for backwards compatibility and can
still be used to select a 'cutPlane' surface. The legacy 'plane' surface
has been removed.
The 'average' keyword has been removed from specification of these
sampled surfaces as cell-centred values are no longer used in the
generation of or interpolation to an iso-surface. The 'filtering'
keyword has also been removed as it relates to options within the
previous algorithm. Zone support has been reinstated into the
'isoSurface' sampled surface. Interpolation to all these sampled
surfaces has been corrected to exactly match the user-selected
interpolation scheme, and the interpolation procedure no longer
unnecessarily re-generates data that is already available.
The mappedPatchBase has been separated into a type which maps from
another patch (still called mappedPatchBase) and one that maps from
internal cell values (mappedInternalPatchBase). This prevents the user
needing to specify settings for mapping procedures that are not being
used, and potentially don't even make sense given the context in which
they are being applied. It also removes a lot of fragile logic and error
states in the mapping engine and its derivatives regarding the mode of
operation. Mapping from any face in the boundary is no longer supported.
Most region-coupling mapping patches are generated automatically by
utilities like splitMeshRegions and extrudeToRegionMesh. Cases which
create region-coupling mapped patches in this way will likely require no
modification.
Explicitly user-specified mapping will need modifying, however. For
example, where an inlet boundary is mapped to a downstream position in
order to evolve a developed profile. Or if a multi-region simulation is
constructed manually, without using one of the region-generating
utilities.
The available mapped patch types are now as follows:
- mapped: Maps values from one patch to another. Typically used for
inlets and outlets; to map values from an outlet patch to an inlet
patch in order to evolve a developed inlet profile, or to permit
flow between regions. Example specification in blockMesh:
inlet
{
type mapped;
neighbourRegion region0; // Optional. Defaults to the same
// region as the patch.
neighbourPatch outlet;
faces ( ... );
}
Note that any transformation between the patches is now determined
automatically. Alternatively, it can be explicitly specified using
the same syntax as for cyclic patches. The "offset" and "distance"
keywords are no longer used.
- mappedWall: As mapped, but treated as a wall for the purposes of
modelling (wall distance). No transformation. Typically used for
thermally coupling different regions. Usually created automatically
by meshing utilities. Example:
fluid_to_solid
{
type mappedWall;
neighbourRegion solid;
neighbourPatch solid_to_fluid;
method intersection; // The patchToPatch method. See
// below.
faces ( ... );
}
- mappedExtrudedWall: As mapped wall, but with corrections to account
for the thickness of an extruded mesh. Used for region coupling
involving film and thermal baffle models. Almost always generated
automatically by extrudeToRegionMesh (so no example given).
- mappedInternal: Map values from internal cells to a patch. Typically
used for inlets; to map values from internal cells to the inlet in
order to evolve a developed inlet profile. Example:
inlet
{
type mappedInternal;
distance 0.05; // Normal distance from the patch
// from which to map cell values
//offset (0.05 0 0); // Offset from the patch from
// which to map cell values
faces ( ... );
}
Note that an "offsetMode" entry is no longer necessary. The mode
will be inferred from the presence of the distance or offset
entries. If both are provided, then offsetMode will also be required
to choose which setting applies.
The mapped, mappedWall and mappedExtrudedWall patches now permit
specification of a "method". This selects a patchToPatch object and
therefore determines how values are transferred or interpolated between
the patches. Valid options are:
- nearest: Copy the value from the nearest face in the neighbouring
patch.
- matching: As nearest, but with checking to make sure that the
mapping is one-to-one. This is appropriate for patches that are
identically meshed.
- inverseDistance: Inverse distance weighting from a small stencil of
nearby faces in the neighbouring patch.
- intersection: Weighting based on the overlapping areas with faces in
the neighbouring patch. Equivalent to the previous AMI-based mapping
mode.
If a method is not specfied, then the pre-existing approach will apply.
This should be equivalent to the "nearest" method (though in most such
cases, "matching" is probably more appropriate). This fallback may be
removed in the future once the patchToPatch methods have been proven
robust.
The important mapped boundary conditions are now as follows:
- mappedValue: Maps values from one patch to another, and optionally
modify the mapped values to recover a specified average. Example:
inlet
{
type mappedValue;
field U; // Optional. Defaults to the same
// as this field.
average (10 0 0); // The presence of this entry now
// enables setting of the average,
// so "setAverage" is not needed
value uniform 0.1;
}
- mappedInternalValue: Map values from cells to a patch, and
optionally specify the average as in mappedValue. Example:
inlet
{
type mappedValue;
field k; // Optional. Defaults to the same
// as this field.
interpolationScheme cell;
value uniform 0.1;
}
- mappedFlowRateVelocity: Maps the flow rate from one patch to
another, and use this to set a patch-normal velocity. Example:
inlet
{
type mappedFlowRate;
value uniform (0 0 0);
}
Of these, mappedValue and mappedInternalValue can override the
underlying mapped patch's settings by additionally specifying mapping
information (i.e., the neighbourPatch, offset, etc... settings usually
supplied for the patch). This also means these boundary condtions can be
applied to non-mapped patches. This functionality used to be provided
with a separate "mappedField" boundary condition, which has been removed
as it is no longer necessary.
Other mapped boundary conditions are either extremely niche (e.g.,
mappedVelocityFlux), are always automatically generated (e.g.,
mappedValueAndPatchInternalValue), or their usage has not changed (e.g.,
compressible::turbulentTemperatureCoupledBaffleMixed and
compressible::turbulentTemperatureRadCoupledMixed). Use foamInfo to
obtain further details about these conditions.
Description
General cell set selection class for models that apply to sub-sets
of the mesh.
Currently supports cell selection from a set of points, a specified cellSet
or cellZone or all of the cells. The selection method can either be
specified explicitly using the \c selectionMode entry or inferred from the
presence of either a \c cellSet, \c cellZone or \c points entry. The \c
selectionMode entry is required to select \c all cells.
Usage
Examples:
\verbatim
// Apply everywhere
selectionMode all;
// Apply within a given cellSet
selectionMode cellSet; // Optional
cellSet rotor;
// Apply within a given cellZone
selectionMode cellZone; // Optional
cellSet rotor;
// Apply in cells containing a list of points
selectionMode points; // Optional
points
(
(2.25 0.5 0)
(2.75 0.5 0)
);
\endverbatim
Also used as the base-class for fvCellSet which additionally provides and
maintains the volume of the cell set.
Description
General cell set selection class for models that apply to sub-sets
of the mesh.
Currently supports cell selection from a set of points, a specified cellSet
or cellZone or all of the cells. The selection method can either be
specified explicitly using the \c selectionMode entry or inferred from the
presence of either a \c cellSet, \c cellZone or \c points entry. The \c
selectionMode entry is required to select \c all cells.
Usage
Examples:
\verbatim
// Apply everywhere
selectionMode all;
// Apply within a given cellSet
selectionMode cellSet; // Optional
cellSet rotor;
// Apply within a given cellZone
selectionMode cellZone; // Optional
cellSet rotor;
// Apply in cells containing a list of points
selectionMode points; // Optional
points
(
(2.25 0.5 0)
(2.75 0.5 0)
);
\endverbatim
All tutorials updated and simplified.
Description
User convenience class to handle the input of time-varying rotational speed
in rad/s if \c omega is specified or rpm if \c rpm is specified.
Usage
For specifying the rotational speed in rpm of an MRF zone:
\verbatim
MRF
{
cellZone rotor;
origin (0 0 0);
axis (0 0 1);
rpm 60;
}
\endverbatim
or the equivalent specified in rad/s:
\verbatim
MRF
{
cellZone rotor;
origin (0 0 0);
axis (0 0 1);
rpm 6.28319;
}
\endverbatim
or for a tabulated ramped rotational speed of a solid body:
\verbatim
mover
{
type motionSolver;
libs ("libfvMeshMovers.so" "libfvMotionSolvers.so");
motionSolver solidBody;
cellZone innerCylinder;
solidBodyMotionFunction rotatingMotion;
origin (0 0 0);
axis (0 1 0);
rpm table
(
(0 0)
(0.01 6000)
(0.022 6000)
(0.03 4000)
(100 4000)
);
}
\endverbatim
The following classes have been updated to use the new Function1s::omega class:
solidBodyMotionFunctions::rotatingMotion
MRFZone
rotatingPressureInletOutletVelocityFvPatchVectorField
rotatingTotalPressureFvPatchScalarField
rotatingWallVelocityFvPatchVectorField
and all tutorials using these models and BCs updated to use rpm where appropriate.
MRF (multiple reference frames) can now be used to simulate SRF (single
reference frame) cases by defining the MRF zone to include all the cells is the
mesh and applying appropriate boundary conditions. The huge advantage of this
is that MRF can easily be added to any solver by the addition of forcing terms
in the momentum equation and absolute velocity to relative flux conversions in
the formulation of the pressure equation rather than having to reformulate the
momentum and pressure system based on the relative velocity as in traditional
SRF. Also most of the OpenFOAM solver applications and all the solver modules
already support MRF.
To enable this generalisation of MRF the transformations necessary on the
velocity boundary conditions in the MRF zone can no longer be handled by the
MRFZone class itself but special adapted fvPatchFields are required. Although
this adds to the case setup it provides much greater flexibility and now complex
inlet/outlet conditions can be applied within the MRF zone, necessary for some
SRF case and which was not possible in the original MRF implementation. Now for
walls rotating within the MRF zone the new 'MRFnoSlip' velocity boundary
conditions must be applied, e.g. in the
tutorials/modules/incompressibleFluid/mixerVessel2DMRF/constant/MRFProperties
case:
boundaryField
{
rotor
{
type MRFnoSlip;
}
stator
{
type noSlip;
}
front
{
type empty;
}
back
{
type empty;
}
}
similarly for SRF cases, e.g. in the
tutorials/modules/incompressibleFluid/mixerSRF case:
boundaryField
{
inlet
{
type fixedValue;
value uniform (0 0 -10);
}
outlet
{
type pressureInletOutletVelocity;
value $internalField;
}
rotor
{
type MRFnoSlip;
}
outerWall
{
type noSlip;
}
cyclic_half0
{
type cyclic;
}
cyclic_half1
{
type cyclic;
}
}
For SRF case all the cells should be selected in the MRFproperties dictionary
which is achieved by simply setting the optional 'selectionMode' entry to all,
e.g.:
SRF
{
selectionMode all;
origin (0 0 0);
axis (0 0 1);
rpm 1000;
}
In the above the rotational speed is set in RPM rather than rad/s simply by
setting the 'rpm' entry rather than 'omega'.
The tutorials/modules/incompressibleFluid/rotor2DSRF case is more complex and
demonstrates a transient SRF simulation of a rotor requiring the free-stream
velocity to rotate around the apparently stationary rotor which is achieved
using the new 'MRFFreestreamVelocity' velocity boundary condition. The
equivalent simulation can be achieved by simply rotating the entire mesh and
keeping the free-stream flow stationary and this is demonstrated in the
tutorials/modules/incompressibleFluid/rotor2DRotating case for comparison.
The special SRFSimpleFoam and SRFPimpleFoam solvers are now redundant and have
been replaced by redirection scripts providing details of the case migration
process.
Field settings can now be specified within
createNonConformalCouplesDict. This allows for patchType overrides; for
example to create a jump condition over the coupling.
An alternate syntax has been added to facilitate this. If patch fields
do not need overriding then the old syntax can be used where patches
that are to be coupled are specified as a pair of names; e.g.:
fields yes;
nonConformalCouples
{
fan
{
patches (fan0 fan1);
transform none;
}
}
If patch fields do need overriding, then instead of the "patches" entry,
separate "owner" and "neighbour" sub-dictionaries should be used. These
can both contain a "patchFields" section detailing the boundary
conditions that apply to the newly created patches:
fields yes;
nonConformalCouples
{
fan
{
owner
{
patch fan0;
patchFields
{
p
{
type fanPressureJump;
patchType nonConformalCyclic;
jump uniform 0;
value uniform 0;
jumpTable polynomial 1((100 0));
}
}
}
neighbour
{
patch fan1;
patchFields
{
$../../owner/patchFields;
}
}
transform none;
}
}
In this example, only the pressure boundary condition is overridden on
the newly created non-conformal cyclic. All other fields will have the
basic constraint type (i.e., nonConformalCyclic) applied.
Settings for the individual non-conformal couples can now be put in a
"nonConformalCouples" sub-dictionary of the
system/createNonConformalCouplesDict. For example:
fields no;
nonConformalCouples // <-- new sub-dictionary
{
nonConformalCouple_none
{
patches (nonCouple1 nonCouple2);
transform none;
}
nonConformalCouple_30deg
{
patches (nonCoupleBehind nonCoupleAhead);
transform rotational;
rotationAxis (-1 0 0);
rotationCentre (0 0 0);
rotationAngle 30;
}
}
This permits settings to be #include-d from files that themselves
contain sub-dictionaries without the utility treating those
sub-dictionaries as if they specify a non-conformal coupling. It also
makes the syntax more comparable to that of createBafflesDict.
The new "nonConformalCouples" sub-dictionary is optional, so this change
is backwards compatible. The new syntax is recommended, however, and all
examples have been changed accordingly.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces pimpleFoam, pisoFoam and simpleFoam and all
the corresponding tutorials have been updated and moved to
tutorials/modules/incompressibleFluid.
Class
Foam::solvers::incompressibleFluid
Description
Solver module for steady or transient turbulent flow of incompressible
isothermal fluids with optional mesh motion and change.
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
Optional fvModels and fvConstraints are provided to enhance the simulation
in many ways including adding various sources, constraining or limiting
the solution.
Reference:
\verbatim
Greenshields, C. J., & Weller, H. G. (2022).
Notes on Computational Fluid Dynamics: General Principles.
CFD Direct Ltd.: Reading, UK.
\endverbatim
SourceFiles
incompressibleFluid.C
See also
Foam::solvers::fluidSolver
Foam::solvers::isothermalFluid
