- fits better into the general sampling framework, improves flexibilty
  and allows code reduction.

ENH: include surface fields on sampledSurfaces that support it

- The writers have changed from being a generic state-less set of
  routines to more properly conforming to the normal notion of a writer.
  These changes allow us to combine output fields (eg, in a single
  VTK/vtp file for each timestep).

  Parallel data reduction and any associated bookkeeping is now part
  of the surface writers.
  This improves their re-usability and avoids unnecessary
  and premature data reduction at the sampling stage.

  It is now possible to have different output formats on a per-surface
  basis.

- A new feature of the surface sampling is the ability to "store" the
  sampled surfaces and fields onto a registry for reuse by other
  function objects.

  Additionally, the "store" can be triggered at the execution phase
  as well

- complete any pending initialisation on write().
  Allows lazier evaluation until when the surfaces are actually needed.

- more dictionary-like methods, enforce keyType::LITERAL for all
  lookups to avoid any spurious keyword matching.

- new readEntry, readIfPresent methods

- The get() method replaces the now deprecate lookup() method.

- Deprecate lookupOrFailsafe()
  Failsafe behaviour is now an optional parameter for lookupOrDefault,
  which makes it easier to tailor behaviour at runtime.

- output of the names is now always flatted without line-breaks.
  Thus,

     os << flatOutput(someEnumNames.names()) << nl;
     os << someEnumNames << nl;

  both generate the same output.

- Constructor now uses C-string (const char*) directly instead of
  Foam::word in its initializer_list.

- Remove special enum + initializer_list constructor form since
  it can create unbounded lookup indices.

- Removd old hasEnum, hasName forms that were provided during initial
  transition from NamedEnum.

- Added static_assert on Enum contents to restrict to enum or
  integral values.  Should not likely be using this class to enumerate
  other things since it internally uses an 'int' for its values.

  Changed volumeType accordingly to enumerate on its type (enum),
  not the class itself.

Style changes:
    - use lookupObjectRef instead of using const_cast
    - use tmp::New factory

- affects surfaceFieldValue, volFieldValue.

  Use 'none' (if desired) to explicitly suppress the weightField, but
  generally better to use a different operation.

- can be useful either for flow-rate weighting where backflow
  is to be ignored in the average, or for flow-rate weighting
  on surfaces with inconsistent orientation.

  Reworked to code to make better use of Enum (the NamedEnum
  replacement). Enum doesn't require contiguous enumeration values,
  which lets us use bitmasking of similar operations to reduce
  duplicate code.

- Remove the unused enums() method since it delivers wholly unreliable
  results. It is not guaranteed to cover the full enumeration range,
  but only the listed names.

- Remove the unused strings() method.
  Duplicated functionality of the words(), but was never used.

- Change access of words() method from static to object.
  Better code isolation. Permits the constructor to take over
  as the single point of failure for bad input.

- Add values() method

- do not expose internal (HashTable) lookup since it makes it more
  difficult to enforce constness and the implementation detail should
  not be exposed. However leave toc() and sortedToc() for the interface.

STYLE: relocated NamedEnum under primitives (was containers)

- internal typedef as 'value_type' for some consistency with STL conventions

Henry Weller authored Jun 22, 2017 and Andrew Heather committed Jun 22, 2017

"pos" now returns 1 if the argument is greater than 0, otherwise it returns 0.
This is consistent with the common mathematical definition of the "pos" function:

https://en.wikipedia.org/wiki/Sign_(mathematics)

However the previous implementation in which 1 was also returned for a 0
argument is useful in many situations so the "pos0" has been added which returns
1 if the argument is greater or equal to 0.  Additionally the "neg0" has been
added which returns 1 if if the argument is less than or equal to 0.

- this makes it possible to perform additional operations
  on surface values that have been previously sampled.

- support vectorField for weighting operations.

- reduce overhead by avoiding creation of weight fields, Sf fields
  and combined surface geometries unless they are actually required.

- extend some similar concepts and operations to volFieldValue

Patch contributed by Timo Niemi, VTT.
Resolves patch request https://bugs.openfoam.org/view.php?id=2452

- currently only 'none' or 'sqrt', which can be useful in combination
  with integrate or averaging functions.

See http://bugs.openfoam.org/view.php?id=2356

Patch contributed by Bruno Santos
Resolves bug-report http://bugs.openfoam.org/view.php?id=2216

Renamed the original volRegion -> volFieldValue to clarify the purpose
of this class to process vol fields on a volRegion.

functionObjects: Further simplification and rationalization using the fvMeshFunctionObject base-class

Requires gcc version 4.7 or higher

functionObjects::surfaceRegion: Write the surface geometry for formats in which the data is in separate files

Replaced the 'postProcess' argument to the 'write' and 'execute'
functions with the single static member 'postProcess' in the
functionObject base-class.

The use of the term 'source' in the context of post-processing is
confusing and does not properly describe the process of region
selection.  The new names 'surfaceRegion' and 'volRegion' better
describe the purpose of the functionObjects which is to provide field
processing functionality limited to a specified region of space, either
a surface or volume.

The keyword 'source' is renamed 'regionType' which better describes the
purpose which is to specify the method by which the surface or volume
region is selected.

The keyword to select the name of the surface or volume region is
renamed from 'sourceName' to 'name' consistent with the other
name-changes above.

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.

regionFunctionObject: moved 'log_' to public 'log' to support the 'Log' macro

  - 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'.

Construction failure and recovery is not handled with exceptions in functionObjectList

functionObjects: Moved into the functionObjects namespace and rationalized and simplified failable construction

Rather than requiring each functionObject to handle failed construction
internally (using the active_ flag) the static member function "viable"
is provided which returns true if construction of the functionObject is
likely to be successful.  Failed construction is then handled by the
wrapper-class which constructs the functionObject,
e.g. "OutputFilterFunctionObject".