multiphaseCompressibleTurbulenceModels, twoPhaseCompressibleTurbulenceModels, phaseCompressibleTurbulenceModels: Added LIB_LIBS

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

In most boundary conditions, fvOptions etc. required and optional fields
to be looked-up from the objectRegistry are selected by setting the
keyword corresponding to the standard field name in the BC etc. to the
appropriate name in the objectRegistry.  Usually a default is provided
with sets the field name to the keyword name, e.g. in the
totalPressureFvPatchScalarField the velocity is selected by setting the
keyword 'U' to the appropriate name which defaults to 'U':

        Property     | Description             | Required    | Default value
        U            | velocity field name     | no          | U
        phi          | flux field name         | no          | phi
        .
        .
        .

However, in some BCs and functionObjects and many fvOptions another
convention is used in which the field name keyword is appended by 'Name'
e.g.

        Property     | Description             | Required    | Default value
        pName        | pressure field name     | no          | p
        UName        | velocity field name     | no          | U

This difference in convention is unnecessary and confusing, hinders code
and dictionary reuse and complicates code maintenance.  In this commit
the appended 'Name' is removed from the field selection keywords
standardizing OpenFOAM on the first convention above.

to have the prefix 'write' rather than 'output'

So outputTime() -> writeTime()

but 'outputTime()' is still supported for backward-compatibility.

Also removed the redundant secondary-writing functionality from Time
which has been superseded by the 'writeRegisteredObject' functionObject.

applications/solvers/heatTransfer/chtMultiRegionFoam: Check there are fluid meshes present for the '-postProcess' option

See also commit 30e2f912

to ensure MRF functionality is available for the -postProcess option

See also commit 30e2f912

See also commit 30e2f912

See also commit 30e2f912

See also commit 30e2f912

See also commit 30e2f912

See also commit 30e2f912

See also commit 30e2f912

See also commit 30e2f912

See also commit 30e2f912
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1301

    Executes application functionObjects to post-process existing results.

    If the "dict" argument is specified the functionObjectList is constructed
    from that dictionary otherwise the functionObjectList is constructed from
    the "functions" sub-dictionary of "system/controlDict"

    Multiple time-steps may be processed and the standard utility time
    controls are provided.

This functionality is equivalent to execFlowFunctionObjects but in a
more efficient and general manner and will be included in all the
OpenFOAM solvers if it proves effective and maintainable.

The command-line options available with the "-postProcess" option may be
obtained by

simpleFoam -help -postProcess

Usage: simpleFoam [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
  -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

Henry G. Weller
CFD Direct Ltd.

Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=2073

Patch contributed by Bruno Santos
Resolved bug-report http://www.openfoam.org/mantisbt/view.php?id=2079

GeometricField: Renamed internalField() -> primitiveField() and dimensionedInternalField() -> internalField()

These new names are more consistent and logical because:

primitiveField():
primitiveFieldRef():
    Provides low-level access to the Field<Type> (primitive field)
    without dimension or mesh-consistency checking.  This should only be
    used in the low-level functions where dimensional consistency is
    ensured by careful programming and computational efficiency is
    paramount.

internalField():
internalFieldRef():
    Provides access to the DimensionedField<Type, GeoMesh> of values on
    the internal mesh-type for which the GeometricField is defined and
    supports dimension and checking and mesh-consistency checking.

In order to simplify expressions involving dimensioned internal field it
is preferable to use a simpler access convention.  Given that
GeometricField is derived from DimensionedField it is simply a matter of
de-referencing this underlying type unlike the boundary field which is
peripheral information.  For consistency with the new convention in
"tmp"  "dimensionedInteralFieldRef()" has been renamed "ref()".

Non-const access to the internal field now obtained from a specifically
named access function consistent with the new names for non-canst access
to the boundary field boundaryFieldRef() and dimensioned internal field
dimensionedInternalFieldRef().

See also commit a4e2afa4

provides optional control for solving the pyrolysis region.

Patch contributed by Karl Meredith, FMGlobal.

When the GeometricBoundaryField template class was originally written it
was a separate class in the Foam namespace rather than a sub-class of
GeometricField as it is now.  Without loss of clarity and simplifying
code which access the boundary field of GeometricFields it is better
that GeometricBoundaryField be renamed Boundary for consistency with the
new naming convention for the type of the dimensioned internal field:
Internal, see commit a25a449c

This is a very simple text substitution change which can be applied to
any code which compiles with the OpenFOAM-dev libraries.

Given that the type of the dimensioned internal field is encapsulated in
the GeometricField class the name need not include "Field"; the type
name is "Internal" so

volScalarField::DimensionedInternalField -> volScalarField::Internal

In addition to the ".dimensionedInternalField()" access function the
simpler "()" de-reference operator is also provided to greatly simplify
FV equation source term expressions which need not evaluate boundary
conditions.  To demonstrate this kEpsilon.C has been updated to use
dimensioned internal field expressions in the k and epsilon equation
source terms.

See also commit a4e2afa4

Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1938

Because C++ does not support overloading based on the return-type there
is a problem defining both const and non-const member functions which
are resolved based on the const-ness of the object for which they are
called rather than the intent of the programmer declared via the
const-ness of the returned type.  The issue for the "boundaryField()"
member function is that the non-const version increments the
event-counter and checks the state of the stored old-time fields in case
the returned value is altered whereas the const version has no
side-effects and simply returns the reference.  If the the non-const
function is called within the patch-loop the event-counter may overflow.
To resolve this it in necessary to avoid calling the non-const form of
"boundaryField()" if the results is not altered and cache the reference
outside the patch-loop when mutation of the patch fields is needed.

The most straight forward way of resolving this problem is to name the
const and non-const forms of the member functions differently e.g. the
non-const form could be named:

    mutableBoundaryField()
    mutBoundaryField()
    nonConstBoundaryField()
    boundaryFieldRef()

Given that in C++ a reference is non-const unless specified as const:
"T&" vs "const T&" the logical convention would be

    boundaryFieldRef()
    boundaryFieldConstRef()

and given that the const form which is more commonly used is it could
simply be named "boundaryField()" then the logical convention is

    GeometricBoundaryField& boundaryFieldRef();

    inline const GeometricBoundaryField& boundaryField() const;

This is also consistent with the new "tmp" class for which non-const
access to the stored object is obtained using the ".ref()" member function.

This new convention for non-const access to the components of
GeometricField will be applied to "dimensionedInternalField()" and "internalField()" in the
future, i.e. "dimensionedInternalFieldRef()" and "internalFieldRef()".

Also added the new prghTotalHydrostaticPressure p_rgh BC which uses the
hydrostatic pressure field as the reference state for the far-field
which provides much more accurate entrainment is large open domains
typical of many fire simulations.

The hydrostatic field solution is controlled by the optional entries in
the fvSolution.PIMPLE dictionary, e.g.

    hydrostaticInitialization yes;
    nHydrostaticCorrectors 5;

and the solver must also be specified for the hydrostatic p_rgh field
ph_rgh e.g.

    ph_rgh
    {
        $p_rgh;
    }

Suitable boundary conditions for ph_rgh cannot always be derived from
those for p_rgh and so the ph_rgh is read to provide them.

To avoid accuracy issues with IO, restart and post-processing the p_rgh
and ph_rgh the option to specify a suitable reference pressure is
provided via the optional pRef file in the constant directory, e.g.

    dimensions      [1 -1 -2 0 0 0 0];
    value           101325;

which is used in the relationship between p_rgh and p:

    p = p_rgh + rho*gh + pRef;

Note that if pRef is specified all pressure BC specifications in the
p_rgh and ph_rgh files are relative to the reference to avoid round-off
errors.

For examples of suitable BCs for p_rgh and ph_rgh for a range of
fireFoam cases please study the tutorials in
tutorials/combustion/fireFoam/les which have all been updated.

Henry G. Weller
CFD Direct Ltd.