- Less looping when detecting lagrangian clouds and their fields.
- Avoid using Time::setTime() and IOobjectList in tight loops.
They both kill performance immensely.
ENH: provide a -noLagrangian option to foamToEnsight and foamToEnsightParts
for even more control.
- The new field needs initialization with a dimensioned<Type> not just
the dimensionSet.
- The new field was also incorrectly being registered, which could
cause issues later.
Old code:
Found 10990 time steps
Search for moving mesh ... no moving mesh detected.
Startup in 329.09 s
Updated:
Found 10990 time steps
Search for moving mesh ... no moving mesh detected.
Startup in 1.6 s
- Cause was checking "polyMesh/points" via an IOobject.
Short-circuit with a check for a polyMesh/ directory first.
Limit the check to the master-node as well to further reduce
load on the file-system.
------------------------------
ENH: improve per-step conversion times for foamToEnsight.
Old code:
Converting 11001 time steps
Time [0] = 0 Wrote in 1.53 s
Time [1] = 1 Wrote in 1.52 s
...
Time [100] = 100 Elapsed time 205.35 s
Updated:
Converting 11001 time steps
Time [0] = 0 Wrote in 1.4 s
Time [1] = 1 Wrote in 0.07 s
...
Time [100] = 100 Elapsed time 42.4 s
- Speedup by hashing test results from the first conversion step
instead of checking each time.
Check data on all nodes to avoid problems with incomplete writes.
------------------------------
BUG: moving mesh detection failed for foamToEnsightParts
- adjusted to agree with updated foamToEnsight
------------------------------
Note:
- foamToEnsightParts (serial) still has about twice the throughput of
foamToEnsight.
- Default is a width of 8 characters, but this can be extended up to 31
characters via the '-width' command-line option.
- Now use a similar structure as foamToEnsightParts for the masking.
This reduces the clutter within the directory, makes it easier to
selectively delete some time steps (using shell commands).
- Added in a "time" information data in each sub-directory to
make it possible to reconstruct the case file with an external
script.
- Conversion of cloud data should now also work in parallel
(may need more testing).
- Support binary output for cloud data.
- Better avoidance of illegal ensight variable names.
But still partially incomplete (due to patch fields).
==================================================
Example of NEW file structure:
EnSight/verticalChannel.case # case name
EnSight/geometry # for non-moving geometry
EnSight/data/ # time-varying data
EnSight/data/00000000/
EnSight/data/00000001/
...
Fields are stored by name within the data/********/ directories:
EnSight/data/00000001/time # human-readable time info
EnSight/data/00000001/U
EnSight/data/00000001/p
...
EnSight/data/00000001/geometry # for moving geometry
Clouds are stored at the next sub-directory level:
EnSight/data/00000001/lagrangian/<cloudName>/positions
EnSight/data/00000001/lagrangian/<cloudName>/U
...
==================================================
The old structure was significantly more cluttered:
EnSight/verticalChannel.case
EnSight/verticalChannel.0000.mesh
EnSight/verticalChannel.0001.p
EnSight/verticalChannel.0001.<cloudName>
EnSight/verticalChannel.0001.<cloudName>.U
==================================================
The normal library system() command uses 'fork', which causes
problems on IB+OPENMPI.
STYLE: add Foam:: qualifier to system calls to make them easier to spot.
- remove old VTK_CONVEX_POINT_SET code, since VTK_POLYHEDRON exists
since several years
ENH: improve robustness of paraFoam script
- only check the relevant plugin types,
fallback to native reader if needed/possible.
To re-use existing 'sampleDict' files simply add the following entries:
type sets;
libs ("libsampling.so");
and run
postProcess -func sampleDict
It is probably better to also rename 'sampleDict' -> 'sample' and then run
postProcess -func sampleDict
Replaced the 'postProcess' argument to the 'write' and 'execute'
functions with the single static member 'postProcess' in the
functionObject base-class.
with the more general and flexible 'postProcess' utility and '-postProcess' solver option
Rationale
---------
Both the 'postProcess' utility and '-postProcess' solver option use the
same extensive set of functionObjects available for data-processing
during the run avoiding the substantial code duplication necessary for
the 'foamCalc' and 'postCalc' utilities and simplifying maintenance.
Additionally consistency is guaranteed between solver data processing
and post-processing.
The functionObjects have been substantially re-written and generalized
to simplify development and encourage contribution.
Configuration
-------------
An extensive set of simple functionObject configuration files are
provided in
OpenFOAM-dev/etc/caseDicts/postProcessing
and more will be added in the future. These can either be copied into
'<case>/system' directory and included into the 'controlDict.functions'
sub-dictionary or included directly from 'etc/caseDicts/postProcessing'
using the '#includeEtc' directive or the new and more convenient
'#includeFunc' directive which searches the
'<etc>/caseDicts/postProcessing' directories for the selected
functionObject, e.g.
functions
{
#includeFunc Q
#includeFunc Lambda2
}
'#includeFunc' first searches the '<case>/system' directory in case
there is a local configuration.
Description of #includeFunc
---------------------------
Specify a functionObject dictionary file to include, expects the
functionObject name to follow (without quotes).
Search for functionObject dictionary file in
user/group/shipped directories.
The search scheme allows for version-specific and
version-independent files using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/caseDicts/postProcessing
- ~/.OpenFOAM/caseDicts/postProcessing
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/caseDicts/postProcessing
- $WM_PROJECT_SITE/caseDicts/postProcessing
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/caseDicts/postProcessing
- $WM_PROJECT_INST_DIR/site/caseDicts/postProcessing
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/caseDicts/postProcessing
An example of the \c \#includeFunc directive:
\verbatim
#includeFunc <funcName>
\endverbatim
postProcess
-----------
The 'postProcess' utility and '-postProcess' solver option provide the
same set of controls to execute functionObjects after the run either by
reading a specified set of fields to process in the case of
'postProcess' or by reading all fields and models required to start the
run in the case of '-postProcess' for each selected time:
postProcess -help
Usage: postProcess [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-dict <file> read control dictionary from specified location
-field <name> specify the name of the field to be processed, e.g. U
-fields <list> specify a list of fields to be processed, e.g. '(U T p)' -
regular expressions not currently supported
-func <name> specify the name of the functionObject to execute, e.g. Q
-funcs <list> specify the names of the functionObjects to execute, e.g.
'(Q div(U))'
-latestTime select the latest time
-newTimes select the new times
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list, has precedence
over the -withZero option
-parallel run in parallel
-region <name> specify alternative mesh region
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
pimpleFoam -postProcess -help
Usage: pimpleFoam [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-dict <file> read control dictionary from specified location
-field <name> specify the name of the field to be processed, e.g. U
-fields <list> specify a list of fields to be processed, e.g. '(U T p)' -
regular expressions not currently supported
-func <name> specify the name of the functionObject to execute, e.g. Q
-funcs <list> specify the names of the functionObjects to execute, e.g.
'(Q div(U))'
-latestTime select the latest time
-newTimes select the new times
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list, has precedence
over the -withZero option
-parallel run in parallel
-postProcess Execute functionObjects only
-region <name> specify alternative mesh region
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
The functionObjects to execute may be specified on the command-line
using the '-func' option for a single functionObject or '-funcs' for a
list, e.g.
postProcess -func Q
postProcess -funcs '(div(U) div(phi))'
In the case of 'Q' the default field to process is 'U' which is
specified in and read from the configuration file but this may be
overridden thus:
postProcess -func 'Q(Ua)'
as is done in the example above to calculate the two forms of the divergence of
the velocity field. Additional fields which the functionObjects may depend on
can be specified using the '-field' or '-fields' options.
The 'postProcess' utility can only be used to execute functionObjects which
process fields present in the time directories. However, functionObjects which
depend on fields obtained from models, e.g. properties derived from turbulence
models can be executed using the '-postProcess' of the appropriate solver, e.g.
pisoFoam -postProcess -func PecletNo
or
sonicFoam -postProcess -func MachNo
In this case all required fields will have already been read so the '-field' or
'-fields' options are not be needed.
Henry G. Weller
CFD Direct Ltd.
Generally fields and objects are selected using the 'field[s]' and
'object[s]' keywords but this was not consistent between all
functionObject, fvOptions etc. and now fixed by applying the following
renaming:
fieldName -> field
fieldNames -> fields
objectName -> object
objectNames -> objects
the equivalent functionality is provided by the writeRegisteredObject
functionObject in a MUCH simpler, easier and extensible manner.
functionObject: Removed the now redundant 'timeSet' function.
This changes simplifies the specification of functionObjects in
controlDict and is consistent with the 'libs' option in controlDict to
load special solver libraries.
Support for the old 'functionObjectLibs' name is supported for backward compatibility.
- Avoids the need for the 'OutputFilterFunctionObject' wrapper
- Time-control for execution and writing is now provided by the
'timeControlFunctionObject' which instantiates the processing
'functionObject' and controls its operation.
- Alternative time-control functionObjects can now be written and
selected at run-time without the need to compile wrapped version of
EVERY existing functionObject which would have been required in the
old structure.
- The separation of 'execute' and 'write' functions is now formalized in the
'functionObject' base-class and all derived classes implement the
two functions.
- Unnecessary implementations of functions with appropriate defaults
in the 'functionObject' base-class have been removed reducing
clutter and simplifying implementation of new functionObjects.
- The 'coded' 'functionObject' has also been updated, simplified and tested.
- Further simplification is now possible by creating some general
intermediate classes derived from 'functionObject'.
splitMeshRegions: handle flipping of faces for surface fields
subsetMesh: subset dimensionedFields
decomposePar: use run-time selection of decomposition constraints. Used to
keep cells on particular processors. See the decomposeParDict in
$FOAM_UTILITIES/parallel/decomposePar:
- preserveBaffles: keep baffle faces on same processor
- preserveFaceZones: keep faceZones owner and neighbour on same processor
- preservePatches: keep owner and neighbour on same processor. Note: not
suitable for cyclicAMI since these are not coupled on the patch level
- singleProcessorFaceSets: keep complete faceSet on a single processor
- refinementHistory: keep cells originating from a single cell on the
same processor.
decomposePar: clean up decomposition of refinement data from snappyHexMesh
reconstructPar: reconstruct refinement data (refineHexMesh, snappyHexMesh)
reconstructParMesh: reconstruct refinement data (refineHexMesh, snappyHexMesh)
redistributePar:
- corrected mapping surfaceFields
- adding processor patches in order consistent with decomposePar
argList: check that slaves are running same version as master
fvMeshSubset: move to dynamicMesh library
fvMeshDistribute:
- support for mapping dimensionedFields
- corrected mapping of surfaceFields
parallel routines: allow parallel running on single processor
Field: support for
- distributed mapping
- mapping with flipping
mapDistribute: support for flipping
AMIInterpolation: avoid constructing localPoints
