for consistency with fvModels and fvConstraints, to simplify code and case
maintenance and to avoid the potentially complex functions entries being
unnecessarily parsed by utilities for which functionObject evaluation is
disabled.
The functions entry in controlDict is still read if the functions file is not
present for backward-compatibility, but it is advisable to migrate cases to use
the new functions file.
This lets calling code determine the difference between a polyMesh
topology change and a re-stitch. This prevents unnecessary
post-processing output in a few cases when using NCC; most notably the
generation of cellProc fields by reconstructPar.
Application
engineCompRatio
Description
Calculate the compression ratio of the engine combustion chamber
If the combustion chamber is not the entire mesh a \c cellSet or
\c cellZone name of the cells in the combustion chamber can be provided.
Usage
\b engineCompRatio [OPTION]
- \par -cellSet \<name\>
Specify the cellSet name of the combustion chamber
- \par -cellZone zoneName
Specify the cellZone name of the combustion chamber
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 new class hierarchy replaces the distributions previously provided
by the Lagrangian library.
All distributions (except fixedValue) now require a "size exponent", Q,
to be specified along with their other coefficients. If a distribution's
CDF(x) (cumulative distribution function) represents what proportion of
the distribution takes a value below x, then Q determines what is meant
by "proportion":
- If Q=0, then "proportion" means the number of sampled values expected
to be below x divided by the total number of sampled values.
- If Q=3, then "proportion" means the expected sum of sampled values
cubed for values below x divided by the total sum of values cubed. If
x is a length, then this can be interpreted as a proportion of the
total volume of sampled objects.
- If Q=2, and x is a length, then the distribution might represent the
proportion of surface area, and so on...
In addition to the user-specification of Q defining what size the given
distribution relates to, an implementation that uses a distribution can
also programmatically define a samplingQ to determine what sort of
sample is being constructed; whether the samples should have an equal
number (sampleQ=0), volume (sampleQ=3), area (sampleQ=2), etc...
A number of fixes to the distributions have been made, including fixing
some fundamental bugs in the returned distribution of samples, incorrect
calculation of the distribution means, renaming misleadingly named
parameters, and correcting some inconsistencies in the way in which
tabulated PDF and CDF data was processed. Distributions no longer
require their parameters to be defined in a sub-dictionary, but a
sub-dictionary is still supported for backwards compatibility.
The distributions can now generate their PDF-s as well as samples, and a
test application has been added (replacing two previous applications),
which thoroughly checks consistency between the PDF and the samples for
a variety of combinations of values of Q and sampleQ.
Backwards incompatible changes are as follows:
- The standard deviation keyword for the normal (and multi-normal)
distribution is now called 'sigma'. Previously this was 'variance',
which was misleading, as the value is a standard deviation.
- The 'massRosinRammler' distribution has been removed. This
functionality is now provided by the standard 'RosinRammler'
distributon with a Q equal to 0, and a sampleQ of 3.
- The 'general' distribution has been split into separate distributions
based on whether PDF or CDF data is provided. These distributions are
called 'tabulatedDensity' and 'tabulatedCumulative', respectively.
The new option takes a value indicating which cell types should be
written out as polyhedra. The values are as follows:
none: No polyhedral cells are written. Cells which match specific
shapes (hex, pyramid, prism, ...) are written as their
corresponding VTK cell types. Arbitrary polyhedral cells
that do not match a specific shape are decomposed into
tetrahedra.
polyhedra: Only arbitrary polyhedral cells are written as a VTK
polyhedron. Cells that match specific shapes are written as
their corresponding VTK cell types.
all: All cells are written as a VTK polyhedron.
The default is 'none', which retains the previous default behaviour.
#includeModel includes an fvModel configuration file into the fvModels file
#includeConstraint includes an fvModel configuration file into the fvConstraints file
These operate in the same manner as #includeFunc does for functionObjects and
search the etc/caseDicts/fvModels and etc/caseDicts/fvConstraints directories
for configuration files and apply optional argument substitution.
Class
Foam::functionEntries::includeFvModelEntry
Description
Specify a fvModel dictionary file to include, expects the
fvModel name to follow with option arguments (without quotes).
Searches for fvModel dictionary file in user/group/shipped
directories allowing for version-specific and version-independent files
using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/caseDicts/fvModels
- ~/.OpenFOAM/caseDicts/fvModels
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/etc/caseDicts/fvModels
- $WM_PROJECT_SITE/etc/caseDicts/fvModels
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/etc/caseDicts/fvModels
- $WM_PROJECT_INST_DIR/site/etc/caseDicts/fvModels
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/caseDicts/fvModels
The optional field arguments included in the name are inserted in 'field' or
'fields' entries in the fvModel dictionary and included in the name
of the fvModel entry to avoid conflict.
Examples:
\verbatim
#includeModel clouds
#includeModel surfaceFilms
\endverbatim
Other dictionary entries may also be specified using named arguments.
See also
Foam::includeFvConstraintEntry
Foam::includeFuncEntry
Class
Foam::functionEntries::includeFvConstraintEntry
Description
Specify a fvConstraint dictionary file to include, expects the
fvConstraint name to follow with option arguments (without quotes).
Searches for fvConstraint dictionary file in user/group/shipped
directories allowing for version-specific and version-independent files
using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/caseDicts/fvConstraints
- ~/.OpenFOAM/caseDicts/fvConstraints
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/etc/caseDicts/fvConstraints
- $WM_PROJECT_SITE/etc/caseDicts/fvConstraints
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/etc/caseDicts/fvConstraints
- $WM_PROJECT_INST_DIR/site/etc/caseDicts/fvConstraints
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/caseDicts/fvConstraints
The optional field arguments included in the name are inserted in 'field' or
'fields' entries in the fvConstraint dictionary and included in the name
of the fvConstraint entry to avoid conflict.
Examples:
\verbatim
#includeConstraint limitPressure(minFactor=0.1, maxFactor=2)
#includeConstraint limitTemperature(min=101, max=1000)
\endverbatim
or for a multiphase case:
\verbatim
#includeConstraint limitLowPressure(min=1e4)
#includeConstraint limitTemperature(phase=steam, min=270, max=2000)
#includeConstraint limitTemperature(phase=water, min=270, max=2000)
\endverbatim
Other dictionary entries may also be specified using named arguments.
See also
Foam::includeFvModelEntry
Foam::includeFuncEntry
Replaces MeshObject, providing a formalised method for creating demand-driven
mesh objects, optionally supporting update functions called by the mesh
following mesh changes.
Class
Foam::DemandDrivenMeshObject
Description
Templated abstract base-class for demand-driven mesh objects used to
automate their allocation to the mesh database and the mesh-modifier
event-loop.
DemandDrivenMeshObject is templated on the type of mesh it is allocated
to, the type of the mesh object (TopologicalMeshObject, GeometricMeshObject,
MoveableMeshObject, DistributeableMeshObject, UpdateableMeshObject) and the
type of the actual object it is created for example:
\verbatim
class leastSquaresVectors
:
public DemandDrivenMeshObject
<
fvMesh,
MoveableMeshObject,
leastSquaresVectors
>
{
.
.
.
//- Delete the least square vectors when the mesh moves
virtual bool movePoints();
};
\endverbatim
MeshObject types:
- TopologicalMeshObject: mesh object to be deleted on topology change
- GeometricMeshObject: mesh object to be deleted on geometry change
- MoveableMeshObject: mesh object to be updated in movePoints
- UpdateableMeshObject: mesh object to be updated in topoChange or
movePoints
- PatchMeshObject: mesh object to be additionally updated patch changes
DemandDrivenMeshObject should always be constructed and accessed via the New
methods provided so that they are held and maintained by the objectRegistry.
To ensure this use constructors of the concrete derived types should be
private or protected and friendship with the DemandDrivenMeshObject
base-class declared so that the New functions can call the the constructors.
Additionally the mesh-object types (TopologicalMeshObject, GeometricMeshObject,
MoveableMeshObject, DistributeableMeshObject, UpdateableMeshObject) can now be
used as mix-in types for normally allocated objects providing the same interface
to mesh-change update functions, see the Fickian fluid
thermophysicalTransportModel or anisotropic solid thermophysicalTransportModel.
This new approach to adding mesh-update functions to classes will be applied to
other existing classes and future developments to simplify the support and
maintenance of run-time mesh changes, in particular mesh refinement/unrefinement
and mesh-to-mesh mapping.
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.
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 reduces duplication and inconsistency between the List, Field, Map,
and PtrList variants. It also allows for future extension to other
container types such as DynamicList.
foamToVTK now supports cases with non-conformal patches. These are
excluded from the final output because their faces do not correspond to
anything in the conformal polyMesh.
In addition, patches are now excluded due to type or selection
consistently, regardless of the presence of the -allPatches option.
Application
foamPostProcess
Description
Execute the set of functionObjects specified in the selected dictionary
(which defaults to system/controlDict) or on the command-line for the
selected set of times on the selected set of fields.
The functionObjects are either executed directly or for the solver
optionally specified as a command-line argument.
Usage
\b foamPostProcess [OPTION]
- \par -dict <file>
Read control dictionary from specified location
- \par -solver <name>
Solver name
- \par -libs '(\"lib1.so\" ... \"libN.so\")'
Specify the additional libraries loaded
-\par -region <name>
Specify the region
- \par -func <name>
Specify the name of the functionObject to execute, e.g. Q
- \par -funcs <list>
Specify the names of the functionObjects to execute, e.g. '(Q div(U))'
- \par -field <name>
Specify the name of the field to be processed, e.g. U
- \par -fields <list>
Specify a list of fields to be processed,
e.g. '(U T p)' - regular expressions not currently supported
- \par -time <ranges>
comma-separated time ranges - eg, ':10,20,40:70,1000:'
- \par -latestTime
Select the latest time
- \par -list
List the available configured functionObjects
Example usage:
- Print the list of available configured functionObjects:
\verbatim
foamPostProcess -list
\endverbatim
- Execute the functionObjects specified in the controlDict of the
fluid region for all the available times:
\verbatim
foamPostProcess -region fluid
\endverbatim
- Execute the functionObjects specified in the controlDict
for the 'fluid' solver in the 'cooling' region for the latest time only:
\verbatim
foamPostProcess -solver fluid -region cooling -latestTime
\endverbatim
A postProcess redirection script is provided for backward-compatibility.
This has required implementation of finer control of stitching in the
fvMesh read constructor and readUpdate methods. Stitching is now
controlled independently of the mesh changers. Full-geometric stitching
is now always the default unless explicitly overridden in the calls to
fvMesh's read methods.
fvMesh::update() now executes at the beginning of the time-step, before time is
incremented and handles topology change, mesh to mesh mapping and redistribution
without point motion. Following each of these mesh changes fields are mapped
from the previous mesh state to new mesh state in a conservative manner. These
mesh changes not occur at most once per time-step.
fvMesh::move() is executed after time is incremented and handles point motion
mesh morphing during the time-step in an Arbitrary Lagrangian Eulerian approach
requiring the mesh motion flux to match the cell volume change. fvMesh::move()
can be called any number of times during the time-step to allow iterative update
of the coupling between the mesh motion and field solution.
This new mapping structure is designed to support run-time mesh-to-mesh mapping
to allow arbitrary changes to the mesh structure, for example during extreme
motion requiring significant topology change including region disconnection etc.
This is a map data structure rather than a class or function which performs the
mapping operation so polyMeshDistributionMap is more logical and comprehensible
than mapDistributePolyMesh.
