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.

See also commit 30e2f912

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()".

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()".

e.g. (fvc::interpolate(HbyA) & mesh.Sf()) -> fvc::flux(HbyA)

This removes the need to create an intermediate face-vector field when
computing fluxes which is more efficient, reduces the peak storage and
improved cache coherency in addition to providing a simpler and cleaner
API.

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

Contributed by Bruno Santos
Resolves patch report http://www.openfoam.org/mantisbt/view.php?id=2023

Update online documentation http://openfoam.github.io/Documentation-dev/html/

The deprecated non-const tmp functionality is now on the compiler switch
NON_CONST_TMP which can be enabled by adding -DNON_CONST_TMP to EXE_INC
in the Make/options file.  However, it is recommended to upgrade all
code to the new safer tmp by using the '.ref()' member function rather
than the non-const '()' dereference operator when non-const access to
the temporary object is required.

Please report any problems on Mantis.

Henry G. Weller
CFD Direct.

To be used instead of zeroGradientFvPatchField for temporary fields for
which zero-gradient extrapolation is use to evaluate the boundary field
but avoiding fields derived from temporary field using field algebra
inheriting the zeroGradient boundary condition by the reuse of the
temporary field storage.

zeroGradientFvPatchField should not be used as the default patch field
for any temporary fields and should be avoided for non-temporary fields
except where it is clearly appropriate;
extrapolatedCalculatedFvPatchField and calculatedFvPatchField are
generally more suitable defaults depending on the manner in which the
boundary values are specified or evaluated.

The entire OpenFOAM-dev code-base has been updated following the above
recommendations.

Henry G. Weller
CFD Direct

The boundary conditions of HbyA are now constrained by the new "constrainHbyA"
function which applies the velocity boundary values for patches for which the
velocity cannot be modified by assignment and pressure extrapolation is
not specified via the new
"fixedFluxExtrapolatedPressureFvPatchScalarField".

The new function "constrainPressure" sets the pressure gradient
appropriately for "fixedFluxPressureFvPatchScalarField" and
"fixedFluxExtrapolatedPressureFvPatchScalarField" boundary conditions to
ensure the evaluated flux corresponds to the known velocity values at
the boundary.

The "fixedFluxPressureFvPatchScalarField" boundary condition operates
exactly as before, ensuring the correct flux at fixed-flux boundaries by
compensating for the body forces (gravity in particular) with the
pressure gradient.

The new "fixedFluxExtrapolatedPressureFvPatchScalarField" boundary
condition may be used for cases with or without body-forces to set the
pressure gradient to compensate not only for the body-force but also the
extrapolated "HbyA" which provides a second-order boundary condition for
pressure.  This is useful for a range a problems including impinging
flow, extrapolated inlet conditions with body-forces or for highly
viscous flows, pressure-induced separation etc.  To test this boundary
condition at walls in the motorBike tutorial case set

    lowerWall
    {
        type            fixedFluxExtrapolatedPressure;
    }

    motorBikeGroup
    {
        type            fixedFluxExtrapolatedPressure;
    }

Currently the new extrapolated pressure boundary condition is supported
for all incompressible and sub-sonic compressible solvers except those
providing implicit and tensorial porosity support.  The approach will be
extended to cover these solvers and options in the future.

Note: the extrapolated pressure boundary condition is experimental and
requires further testing to assess the range of applicability,
stability, accuracy etc.

Henry G. Weller
CFD Direct Ltd.

Provides support for running laminar.

It is better to declare the namespace of each function in the C file
rather than "open" the namespace as this may lead to inconsistencies
between the declaration in the H files and definition in the C file.

fvOptions are transferred to the database on construction using
fv::options::New which returns a reference.  The same function can be
use for construction and lookup so that fvOptions are now entirely
demand-driven.

The abstract base-classes for fvOptions now reside in the finiteVolume
library simplifying compilation and linkage.  The concrete
implementations of fvOptions are still in the single monolithic
fvOptions library but in the future this will be separated into smaller
libraries based on application area which may be linked at run-time in
the same manner as functionObjects.

See also commit 82ccde32

Simplifies lookup of RAS or LES models

Avoids the clutter and maintenance effort associated with providing the
function signature string.

Now consistent with constructors.

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

to simplify construction of dimensionedScalar properties and avoid the
duplication of the name string in the constructor call.

Added calls to setFluxRequired for p, p_rgh etc. in all solvers which
avoids the need to add fluxRequired entries in fvSchemes dictionaries.

    Select LTS via the ddtScheme:

        ddtSchemes
        {
            default         localEuler rDeltaT;
        }

See tutorials/compressible/rhoSimpleFoam/squareBend

SIMPLE
{
    nNonOrthogonalCorrectors 0;
    rhoMin          0.1;
    rhoMax          1.0;
    transonic       yes;
    consistent      yes;

    residualControl
    {
        p               1e-3;
        U               1e-4;
        e               1e-3;

        // possibly check turbulence fields
        "(k|epsilon|omega)" 1e-3;
    }
}

relaxationFactors
{
    fields
    {
        p               1;
        rho             1;
    }
    equations
    {
        p               1;
        U               0.9;
        e               0.9;
        k               0.9;
        epsilon         0.9;
    }
}

e.g. in tutorials/compressible/rhoPimpleFoam/ras/angledDuctLTS

PIMPLE
{
    momentumPredictor   yes;
    transonic           no;
    nOuterCorrectors    50;
    nCorrectors         1;
    nNonOrthogonalCorrectors 0;
    consistent          yes;

    rhoMin          0.5;
    rhoMax          2.0;

    residualControl
    {
        "(U|k|epsilon)"
        {
            relTol          0;
            tolerance       0.0001;
        }
    }

    turbOnFinalIterOnly off;
}

relaxationFactors
{
    fields
    {
        "p.*"           0.9;
        "rho.*"         1;
    }
    equations
    {
        "U.*"           0.9;
        "h.*"           0.7;
        "(k|epsilon|omega).*" 0.8;
    }
}

LTS is selected by the ddt scheme e.g. in the
tutorials/multiphase/interFoam/ras/DTCHull case:

ddtSchemes
{
    default         localEuler rDeltaT;
}

LTSInterFoam is no longer needed now that interFoam includes LTS
support.

Select LTS via the ddtScheme:

ddtSchemes
{
    default         localEuler rDeltaT;
}

The LTS algorithm is controlled with the standard settings in
controlDict, e.g.:

maxCo           0.5;
maxDeltaT       2e-8;

with the addition of the optional rDeltaT smoothing coefficient:

rDeltaTSmoothingCoeff 0.02;

which defaults to 0.02.

For cases with reasonably uniform meshes like the forwardStep tutorial
LTS does not provide much benefit but for cases with large variation in
cell-size like the biconic25-55Run35 tutorial LTS provides significant
speed-up to convergence particularly if started from uniform conditions.

Reverted changes proposed in
http://openfoam.org/mantisbt/view.php?id=1548 as it adversely affects
fixed-value BCs and is formulated to fix an issue with an unphysical
case.  Further analysis of the handling of fixed pressure outlet
conditions as the Mach number approaches 1 is required.

Now consistent with the way the Courant number is calculated for other solvers

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