Warnings about initialisation of particles with locations outside of the
mesh and about the positional inaccuracy of NCC transfers are now
accumulated and printed once per time-step. This way, the log isn't
obscured by hundreds of such warnings.
Also, the pattern in which warnings are silenced after some arbitrary
number (typically 100) have been issued has been removed. This pattern
means that user viewing the log later in the run may be unaware that a
problem is still present. Accumulated warnings are concise enough that
they do not need to be silenced. They are generated every time-step, and
so remain visible throughout the log.
at Function1s of time.
Underlying this new functionObject is a generalisation of the handling of the
maximum time-step in the modular solvers to allow complex user-specification of
the maximum time-step used in a simulation, not just the time-dependency
provided by fluidMaxDeltaT but functions of anything in the simulation by
creating a specialised functionObject in which the maxDeltaT function is
defined.
The chemical and combustion time-scale functionObjects adjustTimeStepToChemistry
and adjustTimeStepToCombustion have been updated and simplified using the above
mechanism.
Also provide fields and curFields functions which return the list of registered
fields not including the geometryFields and current registered fields not
including the geometryFields or old-time fields to simplify mapping code for
NCC, mesh-to-mesh mapping and load-balancing.
The purpose of these operations was unclear, and there was no
documentation or examples of their usage. The differences between these
operations behaviours for scalar and vector input seemed arbitrary.
These operations have in some cases become the subject of confusion.
They have therefore been removed.
Equivalent functionality could be easily reinstated as and when a clear
need and application becomes apparent.
setFormat no longer defaults to the value of graphFormat optionally set in
controlDict and must be set in the functionObject dictionary.
boundaryFoam, financialFoam and pdfPlot still require a graphFormat entry in
controlDict but this is now read directly rather than by Time.
This avoids potential hidden run-time errors caused by solvers running with
boundary conditions which are not fully specified. Note that "null-constructor"
here means the constructor from patch and internal field only, no data is
provided.
Constraint and simple BCs such as 'calculated', 'zeroGradient' and others which
do not require user input to fully specify their operation remain on the
null-constructor table for the construction of fields with for example all
'calculated' or all 'zeroGradient' BCs.
A special version of the 'inletOutlet' fvPatchField named 'zeroInletOutlet' has
been added in which the inlet value is hard-coded to zero which allows this BC
to be included on the null-constructor table. This is useful for the 'age'
functionObject to avoid the need to provide the 'age' volScalarField at time 0
unless special inlet or outlet BCs are required. Also for isothermalFilm in
which the 'alpha' field is created automatically from the 'delta' field if it is
not present and can inherit 'zeroInletOutlet' from 'delta' if appropriate. If a
specific 'inletValue' is require or other more complex BCs then the 'alpha'
field file must be provided to specify these BCs as before.
Following this improvement it will now be possible to remove the
null-constructors from all fvPatchFields not added to the null-constructor
table, which is most of them, thus reducing the amount of code and maintenance
overhead and making easier and more obvious to write new fvPatchField types.
It is now possible to calculate field values of VolInternalFields, e.g. the
cached kEpsilon:G field in the
tutorials/modules/incompressibleFluid/pitzDailySteady case:
#includeFunc cellMax(kEpsilon:G)
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);
}
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.
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 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.
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.
