- Could be related to interrupted builds.
  So if there are any parts of the build that rely on an explicit
  'wmakeLnInclude', make sure that the contents are properly updated.

--

ENH: improved feedback from top-level Allwmake

- Report which section (libraries, applications) is being built.

- Provide final summary of date, version, etc, which can be helpful
  for later diagnosis or record keeping.

- The -log=XXX option for Allwmake now accepts a directory name
  and automatically appends an appropriate log name.
  Eg,
      ./Allwmake -log=logs/  ->> logs/log.linux64GccDPInt32Opt

  The default name is built from the value of WM_OPTIONS.

--

BUG: shell not exiting properly in combination with -log option

- the use of 'tee' causes the shell to hang around.
  Added an explicit exit to catch this.

--

- Detecting the '-k' (-non-stop) option at the top-level Allwmake, which
  may improve robustness.

- Explicit continue-on-error for foamyMesh (as optional component)

- unify format of script messages for better readability

COMP: reduce warnings when building Pstream (old-style casts in openmpi)

'set -x' should be used for debugging.

Added command printing into wmake and Allwmake as a replacement for
'set -x' to log current target.

- existed, but was not being called

Patch contributed by Mattijs Janssens

Resolves bug-report http://bugs.openfoam.org/view.php?id=2120

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.

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

Do not link the fvOptions library into the TurbulenceModels libraries
due to cyclic dependency

- shm: have displacementMotionSolver as alternative mesh shrinker
  (instead of medialAxis).
- updated iglooWithFridges tutorial to use displacementLaplacian
- selectable interpolation from cells to points in the motion solvers
  using the 'interpolation' keyword:
    interpolation volPointInterpolation;    // default
    or
    interpolation patchCorrected (lowerWall upperWall);
- wrapped up mesh shrinkers (see above) for use as a displacementMotionSolver
  (i.e. the opposite of the displacementMotionSolver mesh shrinker)

- shm: have displacementMotionSolver as alternative mesh shrinker
  (instead of medialAxis).
- updated iglooWithFridges tutorial to use displacementLaplacian
- selectable interpolation from cells to points in the motion solvers
  using the 'interpolation' keyword:
    interpolation volPointInterpolation;    // default
    or
    interpolation patchCorrected (lowerWall upperWall);
- wrapped up mesh shrinkers (see above) for use as a displacementMotionSolver
  (i.e. the opposite of the displacementMotionSolver mesh shrinker)

The old separate incompressible and compressible libraries have been removed.

Most of the commonly used RANS and LES models have been upgraded to the
new framework but there are a few missing which will be added over the
next few days, in particular the realizable k-epsilon model.  Some of
the less common incompressible RANS models have been introduced into the
new library instantiated for incompressible flow only.  If they prove to
be generally useful they can be templated for compressible and
multiphase application.

The Spalart-Allmaras DDES and IDDES models have been thoroughly
debugged, removing serious errors concerning the use of S rather than
Omega.

The compressible instances of the models have been augmented by a simple
backward-compatible eddyDiffusivity model for thermal transport based on
alphat and alphaEff.  This will be replaced with a separate run-time
selectable thermal transport model framework in a few weeks.

For simplicity and ease of maintenance and further development the
turbulent transport and wall modeling is based on nut/nuEff rather than
mut/muEff for compressible models so that all forms of turbulence models
can use the same wall-functions and other BCs.

All turbulence model selection made in the constant/turbulenceProperties
dictionary with RAS and LES as sub-dictionaries rather than in separate
files which added huge complexity for multiphase.

All tutorials have been updated so study the changes and update your own
cases by comparison with similar cases provided.

Sorry for the inconvenience in the break in backward-compatibility but
this update to the turbulence modeling is an essential step in the
future of OpenFOAM to allow more models to be added and maintained for a
wider range of cases and physics.  Over the next weeks and months more
turbulence models will be added of single and multiphase flow, more
additional sub-models and further development and testing of existing
models.  I hope this brings benefits to all OpenFOAM users.

Henry G. Weller

avoid recursive dependency with thermo and turbulence libraries

energyRegionCoupledFvPatchScalarField and GAMG interfaces

createShellMesh and introducing io::READ_IF_PRESENT option
in polyMesh constructor from components

- also simplify setting makeType in the Allwmake scripts