Replacing volRegion removes unnecessary functionality duplication and ensures
cell set selection is consistent between functionObjects, fvModels and
fvConstraints for user convenience and reducing the code maintenance overhead.
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 select entry or inferred from the
presence of either a \c cellSet, \c cellZone or \c points entry. The \c
select entry is required to select \c all cells.
Usage
Examples:
\verbatim
// Apply everywhere
select all;
// Apply within a given cellSet
select cellSet; // Optional
cellSet rotor;
// Apply within a given cellZone
select cellZone; // Optional
cellZone rotor;
// Apply in cells containing a list of points
select points; // Optional
points
(
(2.25 0.5 0)
(2.75 0.5 0)
);
\endverbatim
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);
}
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.
This function stops the run when all parcel clouds are empty.
Example of function object specification:
stop
{
type stopAtEmptyClouds;
libs ("liblagrangianFunctionObjects.so");
executeControl timeStep; // <-- Likely only to be needed if injection
startTime 0.500001; // starts after time zero. In which case the
// startTime should be slightly after the
// injection start time.
action nextWrite;
}
A packaged function object is also included, which permits the following
syntax to be used, either with #includeFunc in the system/controlDict,
or with the -func option to foamPostProcess:
stopAtEmptyClouds(startTime=0.500001)
Support for mesh sub-cycling has been removed from Lagrangian. Various
Lagrangian processes already support sub-dividing the time-step. It is
easier and more efficient to extend that support all the way to the
high-level cloud objects, rather than to sub-cycle the mesh.
This has additional benefits. The cloud now no longer needs to reset the
step fraction at the start of every sub-motion. Injection can take
advantage of this by modifying particles' step fractions in order to
distribute them uniformly through the time-step. This is a simple and
efficient method. Previously, injection would track the particles some
distance after injection. This was more expensive to do, it resulted in
spatial artefacts in the injected Lagrangian field, and it did not
correctly handle interactions with patches or parallel transfers.
The lack of injection tracking also means that particles injected
through patches now start their simulation topologically connected to
the face on which they are created. This means that they correctly
trigger cloud functions associated with that face and/or patch.
The injection models now also return barycentric coordinates directly,
rather than the global position of injected particles. For methods that
initially generate locations naturally in terms of barycentric
coordinates, this prevents unnecessary and potentially fragile
conversion from barycentric to Cartesian and back again. These are
typically the methods that "fill" some sort of space; e.g., patch or
cell-zone injections.
This function object writes graphs of patch face values, area-averaged in
planes perpendicular to a given direction. It adaptively grades the
distribution of graph points to match the resolution of the mesh.
Example of function object specification:
patchCutLayerAverage1
{
type patchCutLayerAverage;
libs ("libpatchCutLayerAverageFunctionObject.so");
writeControl writeTime;
writeInterval 1;
patch lowerWall;
direction (1 0 0);
nPoints 100;
interpolate no;
fields (p U);
axis x;
setFormat raw;
}
A packaged function object is also included, which permits the following
syntax to be used, either with #includeFunc in the system/controlDict,
or with the -func option to foamPostProcess:
graphPatchCutLayerAverage
(
funcName=aerofoilLowerPressure,
patch=aerofoilLower,
direction=(0.15 -0.016 0),
nPoints=100,
p
)
The fieldAverage can now average fields that do not exist at
construction time, and it also supports restart on cases in which
the mesh topology is changing.
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.
Also changed the keyword timeVsFile to the more logical fileVsTime with
backward-compatibility.
Class
Foam::functionObjects::timeActivatedFileUpdate
Description
Performs a file copy/replacement once a specified time has been reached.
Usage
Example usage to update the fvSolution dictionary at 0.1, 0.2 and 0.3s
during the run:
\verbatim
fileUpdate1
{
type timeActivatedFileUpdate;
libs ("libutilityFunctionObjects.so");
writeControl timeStep;
writeInterval 1;
fileToUpdate "$FOAM_CASE/system/fvSolution";
fileVsTime
(
(-1 "$FOAM_CASE/system/fvSolution.0")
(0.10 "$FOAM_CASE/system/fvSolution.10")
(0.20 "$FOAM_CASE/system/fvSolution.20")
(0.35 "$FOAM_CASE/system/fvSolution.35")
);
}
\endverbatim
Resolves bug-report https://bugs.openfoam.org/view.php?id=3938
Now that kappa, Cp and Cv fields are cached and Cpv returns either the Cp or Cv
field reference depending on the energy solved and thermal transport is now
fundamentally based on temperature rather energy gradients it is no longer
necessary or useful to provide an abstract function returning alphahe.
The thermodynamic density field is now named "rho" by default and only renamed
"thermo:rho" by solvers that create and maintain a separate continuity density
field which is named "rho". This change significantly simplifies and
standardises the specification of schemes and boundary conditions requiring
density as it is now always named "rho" or "rho.<phase>" unless under some very
unusual circumstances the thermodynamic rather than continuity density is
required for a solver maintaining both.
The advantage of this change is particularly noticeable for multiphase
simulations in which each phase has its own density now named "rho.<phase>"
rather than "thermo:rho.<phase>" as separate phase continuity density fields are
not required so for multiphaseEulerFoam the scheme specification:
"div\(alphaRhoPhi.*,\(p\|thermo:rho.*\)\)" Gauss limitedLinear 1;
is now written:
"div\(alphaRhoPhi.*,\(p\|rho.*\)\)" Gauss limitedLinear 1;
the new fluidThermophysicalTransportModel and solidThermophysicalTransportModel
are derived from thermophysicalTransportModel providing a consistent and unified
interface for heat transport within and between regions. Coupled and external
heat-transfer boundary conditions can now be written independent of the
thermophysical properties or transport modelling of the regions providing
greater flexibility, simpler code and reduces the maintenance overhead.
The previous fluidThermophysicalTransportModel typedef has been renamed
fluidThermoThermophysicalTransportModel as it is instantiated on fluidThermo,
freeing the name fluidThermophysicalTransportModel for the new base-class.
to handle isotropic and anisotropic is a consistent, general and extensible
manner, replacing the horrible hacks which were in solidThermo.
This is entirely consistent with thermophysicalTransportModel for fluids and
provides the q() and divq() for the solid energy conservation equations. The
transport model and properties are specified in the optional
thermophysicalTransport dictionary, the default model being isotropic if this
dictionary file is not present, thus providing complete backward-compatibility
for the common isotropic cases.
Anisotropic thermal conductivity is now handled in a much more general manner by
the anisotropic model:
Class
Foam::solidThermophysicalTransportModels::anisotropic
Description
Solid thermophysical transport model for anisotropic thermal conductivity
The anisotropic thermal conductivity field is evaluated from the solid
material anisotropic kappa specified in the physicalProperties dictionary
transformed into the global coordinate system using default
coordinate system and optionally additional coordinate systems specified
per-zone in the thermophysicalProperties dictionary.
Usage
Example of the anisotropic thermal conductivity specification in
thermophysicalProperties with two zone-based coordinate systems in
addition to the default:
\verbatim
model anisotropic;
// Default coordinate system
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type cylindrical;
e3 (1 0 0);
}
}
// Optional zone coordinate systems
zones
{
coil1
{
type cartesian;
origin (0.1 0.2 0.7);
coordinateRotation
{
type cylindrical;
e3 (0.5 0.866 0);
}
}
coil2
{
type cartesian;
origin (0.4 0.5 1);
coordinateRotation
{
type cylindrical;
e3 (0.866 0.5 0);
}
}
}
\endverbatim
This development required substantial rationalisation of solidThermo,
coordinateSystems and updates to the solid solver module, solidDisplacementFoam,
the wallHeatFlux functionObject, thermalBaffle and all coupled thermal boundary
conditions.
so that the specification of time-step and write-interval are in user-time,
consistent with the controlDict.
Class
Foam::functionObjects::setTimeStepFunctionObject
Description
Updates the time step as a Function1 of time.
If the case is running with userTime specified in controlDict then the
time-step values returned by the Function1 are assumed to be in user-time
rather than real-time.
Class
Foam::functionObjects::setWriteIntervalFunctionObject
Description
Updates the writeInterval as a Function1 of time.
If the case is running with userTime specified in controlDict then the write
interval values returned by the Function1 are assumed to be in user-time
rather than real-time.
Resolves bug-report https://bugs.openfoam.org/view.php?id=3904
Function objects now write to the following path when applied to a
non-default region of a multi-region case:
postProcessing/<regionName>/<functionName>/<time>/
Previously the order of <regionName> and <functionName> was not
consistent between the various function objects.
Resolves bug report https://bugs.openfoam.org/view.php?id=3907
This reference represents unnecessary storage. The mesh can be obtained
from tracking data or passed to the particle evolution functions by
argument.
In addition, removing the mesh reference makes it possible to construct
as particle from an Istream without the need for an iNew class. This
simplifies stream-based transfer, and makes it possible for particles to
be communicated by a polyDistributionMap.
This mode uses the patchToPatch system (the same one used by NCC) for
coupling two patches. It can be selected for a patch (e.g., in a
blockMeshDict) in the following way:
fluid_to_solid
{
type mappedWall;
sampleMode patchToPatch;
sampleRegion solid;
samplePatch solid_to_fluid;
patchToPatchMode intersection;
faces
(
(0 1 2 3)
...
);
}
The "patchToPatchMode" can be one of the following:
"intersection": Values obtained by weighting contributions from
sampled faces with the intersected area between the faces.
Equivalent to the nearestPatchFaceAMI sampleMode (which will be
removed in a future commit).
"inverseDistance": Values obtained by inverse-distance weighting
between a small stencil of nearby sampled faces.
"nearest": Take the value from the nearest sampled face.
"matching": As nearest, but with checks to ensure that the mapping
is one-to-one. To be used for mapping between identical patches.
The intention is that patchToPatch will become the only sampleMode, and
the four options above will become the options which determine how
mapping is performed. Cell-to-patch mapping will be transferred into a
separate class as its use cases essentially never intersect with those
of patch-to-patch mapping.
An extruded region is now contiguous even when specified with multiple
face zones. Edges that border faces in different zones now extrude into
internal faces, rather than a pair of boundary faces. Different zones
now result only in different mapped patches in the extruded and primary
meshes. This means a mesh can be created for a single contiguous
extruded region spanning multiple patches. This might be necessary if,
for example, a film region is needed across multiple walls with
differing thermal boundary conditions.
Disconnected extruded regions can still be constructed by running the
extrudeToRegionMesh utility muiliple times.
The mapped patches created to couple the extruded regions now have
symmetric names similar to those created by splitMeshRegions. For
example, if the mapped patch in the primary region is called
"region0_to_extrudedRegion_f0", then the corresponding patch in the
extruded region is called "extrudedRegion_to_region0_f0" (f0, in this
example is the face zone from which the region was extruded).
Offsetting of the top patch is now handled automatically by a new
mappedExtrudedWallPolyPatch. This refers to the bottom patch and
automatically calculates the sampling offsets by doing a wave across the
extruded mesh layers. This prevents the need to store the offsets in the
patch itself, and makes it possible for the patch to undergo mesh
changes without adding additional functions to the polyPatch (mapping
constructors, autoMap and rmap methods, etc ...).
If a "patch" selection is made for a cyclic patch, surfaceFieldValue now
also selects faces on any associated processor cyclic patches. This
ensures that the serial and parallel operations are equivalent.
The schemesField option:
- To employ the same numerical schemes as another field set
the \c schemesField entry,
works to set discretisation schemes and a standard linear solver and settings
but not MULES for which an entry in fvSolution under the actual field name is
required.
