with backward-compatibility so that the previous keyword "solver" is supported.

Corrected the geometry directory name from "triSurface" to "geometry".

Resolves bug-report https://bugs.openfoam.org/view.php?id=2529

Resolves bug report https://bugs.openfoam.org/view.php?id=2486

except turbulence and lagrangian which will also be updated shortly.

For example in the nonNewtonianIcoFoam offsetCylinder tutorial the viscosity
model coefficients may be specified in the corresponding "<type>Coeffs"
sub-dictionary:

transportModel  CrossPowerLaw;

CrossPowerLawCoeffs
{
    nu0         [0 2 -1 0 0 0 0]  0.01;
    nuInf       [0 2 -1 0 0 0 0]  10;
    m           [0 0 1 0 0 0 0]   0.4;
    n           [0 0 0 0 0 0 0]   3;
}

BirdCarreauCoeffs
{
    nu0         [0 2 -1 0 0 0 0]  1e-06;
    nuInf       [0 2 -1 0 0 0 0]  1e-06;
    k           [0 0 1 0 0 0 0]   0;
    n           [0 0 0 0 0 0 0]   1;
}

which allows a quick change between models, or using the simpler

transportModel  CrossPowerLaw;

nu0         [0 2 -1 0 0 0 0]  0.01;
nuInf       [0 2 -1 0 0 0 0]  10;
m           [0 0 1 0 0 0 0]   0.4;
n           [0 0 0 0 0 0 0]   3;

if quick switching between models is not required.

To support this more convenient parameter specification the inconsistent
specification of seedSampleSet in the streamLine and wallBoundedStreamLine
functionObjects had to be corrected from

    // Seeding method.
    seedSampleSet   uniform;  //cloud; //triSurfaceMeshPointSet;

    uniformCoeffs
    {
        type        uniform;
        axis        x;  //distance;

        // Note: tracks slightly offset so as not to be on a face
        start       (-1.001 -0.05 0.0011);
        end         (-1.001 -0.05 1.0011);
        nPoints     20;
    }

to the simpler

    // Seeding method.
    seedSampleSet
    {
        type        uniform;
        axis        x;  //distance;

        // Note: tracks slightly offset so as not to be on a face
        start       (-1.001 -0.05 0.0011);
        end         (-1.001 -0.05 1.0011);
        nPoints     20;
    }

which also support the "<type>Coeffs" form

    // Seeding method.
    seedSampleSet
    {
        type        uniform;

        uniformCoeffs
        {
            axis        x;  //distance;

            // Note: tracks slightly offset so as not to be on a face
            start       (-1.001 -0.05 0.0011);
            end         (-1.001 -0.05 1.0011);
            nPoints     20;
        }
    }

Radiative heat transfer may now be added to any solver in which an energy
equation is solved at run-time rather than having to change the solver code.

For example, radiative heat transfer is now enabled in the SandiaD_LTS
reactingFoam tutorial by providing a constant/fvOptions file containing

radiation
{
    type            radiation;
    libs ("libradiationModels.so");
}

and appropriate settings in the constant/radiationProperties file.

For example the porosity coefficients may now be specified thus:

porosity1
{
    type            DarcyForchheimer;

    cellZone        porosity;

    d   (5e7 -1000 -1000);
    f   (0 0 0);

    coordinateSystem
    {
        type    cartesian;
        origin  (0 0 0);
        coordinateRotation
        {
            type    axesRotation;
            e1      (0.70710678 0.70710678 0);
            e2      (0 0 1);
        }
    }
}

rather than

porosity1
{
    type            DarcyForchheimer;
    active          yes;
    cellZone        porosity;

    DarcyForchheimerCoeffs
    {
        d   (5e7 -1000 -1000);
        f   (0 0 0);

        coordinateSystem
        {
            type    cartesian;
            origin  (0 0 0);
            coordinateRotation
            {
                type    axesRotation;
                e1      (0.70710678 0.70710678 0);
                e2      (0 0 1);
            }
        }
    }
}

support for which is maintained for backward compatibility.

for consistency with the other energy sources.

For example the actuationDiskSource fvOption may now be specified

disk1
{
    type            actuationDiskSource;

    fields      (U);

    selectionMode   cellSet;
    cellSet         actuationDisk1;
    diskDir         (1 0 0);    // Orientation of the disk
    Cp              0.386;
    Ct              0.58;
    diskArea        40;
    upstreamPoint   (581849 4785810 1065);
}

rather than

disk1
{
    type            actuationDiskSource;
    active          on;

    actuationDiskSourceCoeffs
    {
        fields      (U);

        selectionMode   cellSet;
        cellSet         actuationDisk1;
        diskDir         (1 0 0);    // Orientation of the disk
        Cp              0.386;
        Ct              0.58;
        diskArea        40;
        upstreamPoint   (581849 4785810 1065);
    }
}

but this form is supported for backward compatibility.

The standard naming convention for heat flux is "q" and this is used for the
conductive and convective heat fluxes is OpenFOAM.  The use of "Qr" for
radiative heat flux is an anomaly which causes confusion, particularly for
boundary conditions in which "Q" is used to denote power in Watts.  The name of
the radiative heat flux has now been corrected to "qr" and all models, boundary
conditions and tutorials updated.

by combining with and rationalizing functionality from
turbulentHeatFluxTemperatureFvPatchScalarField.
externalWallHeatFluxTemperatureFvPatchScalarField now replaces
turbulentHeatFluxTemperatureFvPatchScalarField which is no longer needed and has
been removed.

Description
    This boundary condition applies a heat flux condition to temperature
    on an external wall in one of three modes:

      - fixed power: supply Q
      - fixed heat flux: supply q
      - fixed heat transfer coefficient: supply h and Ta

    where:
    \vartable
        Q  | Power [W]
        q  | Heat flux [W/m^2]
        h  | Heat transfer coefficient [W/m^2/K]
        Ta | Ambient temperature [K]
    \endvartable

    For heat transfer coefficient mode optional thin thermal layer resistances
    can be specified through thicknessLayers and kappaLayers entries.

    The thermal conductivity \c kappa can either be retrieved from various
    possible sources, as detailed in the class temperatureCoupledBase.

Usage
    \table
    Property     | Description                 | Required | Default value
    mode         | 'power', 'flux' or 'coefficient' | yes |
    Q            | Power [W]                   | for mode 'power'     |
    q            | Heat flux [W/m^2]           | for mode 'flux'     |
    h            | Heat transfer coefficient [W/m^2/K] | for mode 'coefficent' |
    Ta           | Ambient temperature [K]     | for mode 'coefficient' |
    thicknessLayers | Layer thicknesses [m] | no |
    kappaLayers  | Layer thermal conductivities [W/m/K] | no |
    qr           | Name of the radiative field | no | none
    qrRelaxation | Relaxation factor for radiative field | no | 1
    kappaMethod  | Inherited from temperatureCoupledBase | inherited |
    kappa        | Inherited from temperatureCoupledBase | inherited |
    \endtable

    Example of the boundary condition specification:
    \verbatim
    <patchName>
    {
        type            externalWallHeatFluxTemperature;

        mode            coefficient;

        Ta              uniform 300.0;
        h               uniform 10.0;
        thicknessLayers (0.1 0.2 0.3 0.4);
        kappaLayers     (1 2 3 4);

        kappaMethod     fluidThermo;

        value           $internalField;
    }
    \endverbatim

Description
    Temperature-dependent surface tension model in which the surface tension
    function provided by the phase Foam::liquidProperties class is used.

Usage
    \table
        Property     | Description               | Required    | Default value
        phase        | Phase name                | yes         |
    \endtable

    Example of the surface tension specification:
    \verbatim
        sigma
        {
            type    liquidProperties;
            phase   water;
        }
    \endverbatim

for use with e.g. compressibleInterFoam, see
tutorials/multiphase/compressibleInterFoam/laminar/depthCharge2D

Combining a Function1 temperature dependency with a distributionModel stochastic
perturbation.

Resolves bug-report https://bugs.openfoam.org/view.php?id=2513

These models have been particularly designed for use in the VoF solvers, both
incompressible and compressible.  Currently constant and temperature dependent
surface tension models are provided but it easy to write models in which the
surface tension is evaluated from any fields held by the mesh database.

Resolves bug-report https://bugs.openfoam.org/view.php?id=2514

This update does not change the operation or controls of the regionModels, it is
to aid understanding of the code.

Created a base-class from contactAngleForce from which the
distributionContactAngleForce (for backward compatibility) and the new
temperatureDependentContactAngleForce are derived:

Description
    Temperature dependent contact angle force

    The contact angle in degrees is specified as a \c Function1 type, to
    enable the use of, e.g.  contant, polynomial, table values.

See also
    Foam::regionModels::surfaceFilmModels::contactAngleForce
    Foam::Function1Types

SourceFiles
    temperatureDependentContactAngleForce.C

according to

        Bai et al, `Modelling of gasoline spray impingement', Atom. Sprays,
        vol 12, pp 1-27, 2002

Resolves bug-report https://bugs.openfoam.org/view.php?id=2478

    Off-centering is specified via the mandatory coefficient \c ocCoeff in the
    range [0,1] following the scheme name e.g.
    \verbatim
    ddtSchemes
    {
        default         CrankNicolson 0.9;
    }
    \endverbatim
    or with an optional "ramp" function to transition from the Euler scheme to
    Crank-Nicolson over a initial period to avoid start-up problems, e.g.
    \verbatim
    ddtSchemes
    {
        default         CrankNicolson
        ocCoeff
        {
            type scale;
            scale linearRamp;
            duration 0.01;
            value 0.9;
        };
    }
    \endverbatim

Note this functionality is experimental and the specification and implementation
may change if issues arise.

Patch contributed by Timo Niemi, VTT.
Resolves bug-report https://bugs.openfoam.org/view.php?id=2510

Resolves bug-report https://bugs.openfoam.org/view.php?id=2512

Applied to eigen-value calculations. Fixed repeated-eigen-value issues
in eigen-vector generation.

Resolves bug-report https://bugs.openfoam.org/view.php?id=2507

For example in the potentialFreeSurfaceFoam/oscillatingBox tutorial it is
cleaner to apply the "linearRamp" function to the "sine" function rather than
using an amplitude table:

    floatingObject
    {
        type            fixedNormalInletOutletVelocity;

        fixTangentialInflow false;

        normalVelocity
        {
            type            uniformFixedValue;

            uniformValue
            {
                type        scale;

                value
                {
                    type sine;

                    frequency   1;
                    amplitude   0.025;
                    scale       (0 1 0);
                    level       (0 0 0);
                }

                scale
                {
                    type linearRamp;

                    duration 10;
                }
            }
        }

        value           uniform (0 0 0);
    }

with more general forms of those functions.

coupled patches, to prevent rebound/stick/etc... on these patches. Also
added "none" interaction type to LocalInteraction, which reverts the
patch interaction to the fundamental behaviour. This is primarily useful
for non-coupled constraint types.

Resolves https://bugs.openfoam.org/view.php?id=2458

including support for TDAC and ISAT for efficient chemistry calculation.

Description
    Eddy Dissipation Concept (EDC) turbulent combustion model.

    This model considers that the reaction occurs in the regions of the flow
    where the dissipation of turbulence kinetic energy takes place (fine
    structures). The mass fraction of the fine structures and the mean residence
    time are provided by an energy cascade model.

    There are many versions and developments of the EDC model, 4 of which are
    currently supported in this implementation: v1981, v1996, v2005 and
    v2016.  The model variant is selected using the optional \c version entry in
    the \c EDCCoeffs dictionary, \eg

    \verbatim
        EDCCoeffs
        {
            version v2016;
        }
    \endverbatim

    The default version is \c v2015 if the \c version entry is not specified.

    Model versions and references:
    \verbatim
        Version v2005:

            Cgamma = 2.1377
            Ctau = 0.4083
            kappa = gammaL^exp1 / (1 - gammaL^exp2),

            where exp1 = 2, and exp2 = 2.

            Magnussen, B. F. (2005, June).
            The Eddy Dissipation Concept -
            A Bridge Between Science and Technology.
            In ECCOMAS thematic conference on computational combustion
            (pp. 21-24).

        Version v1981:

            Changes coefficients exp1 = 3 and exp2 = 3

            Magnussen, B. (1981, January).
            On the structure of turbulence and a generalized
            eddy dissipation concept for chemical reaction in turbulent flow.
            In 19th Aerospace Sciences Meeting (p. 42).

        Version v1996:

            Changes coefficients exp1 = 2 and exp2 = 3

            Gran, I. R., & Magnussen, B. F. (1996).
            A numerical study of a bluff-body stabilized diffusion flame.
            Part 2. Influence of combustion modeling and finite-rate chemistry.
            Combustion Science and Technology, 119(1-6), 191-217.

        Version v2016:

            Use local constants computed from the turbulent Da and Re numbers.

            Parente, A., Malik, M. R., Contino, F., Cuoci, A., & Dally, B. B.
            (2016).
            Extension of the Eddy Dissipation Concept for
            turbulence/chemistry interactions to MILD combustion.
            Fuel, 163, 98-111.
    \endverbatim

Tutorials cases provided: reactingFoam/RAS/DLR_A_LTS, reactingFoam/RAS/SandiaD_LTS.

This codes was developed and contributed by

    Zhiyi Li
    Alessandro Parente
    Francesco Contino
    from BURN Research Group

and updated and tested for release by

    Henry G. Weller
    CFD Direct Ltd.

to provide smoother behavior on start-up when an acceleration impulse is
applied, e.g. if the body is suddenly released.  e.g.

dynamicFvMesh       dynamicMotionSolverFvMesh;

motionSolverLibs   ("librigidBodyMeshMotion.so");

solver             rigidBodyMotion;

rigidBodyMotionCoeffs
{
    report          on;

    solver
    {
        type    Newmark;
    }

    ramp
    {
        type     quadratic;
        start    0;
        duration 10;
    }
.
.
.

will quadratically ramp the forces from 0 to their full values over the first
10s of the run starting from 0.  If the 'ramp' entry is omitted no force ramping
is applied.

Description
    Ramp function base class for the set of scalar functions starting from 0 and
    increasing monotonically to 1 from \c start over the \c duration and
    remaining at 1 thereafter.

    Usage:
    \verbatim
        <entryName> <rampFunction>;
        <entryName>Coeffs
        {
            start     10;
            duration  20;
        }
    \endverbatim
    or
    \verbatim
        <entryName>
        {
            type      <rampFunction>;
            start     10;
            duration  20;
        }
    \endverbatim

    Where:
    \table
        Property | Description  | Required | Default value
        start    | Start time   | no       | 0
        duration | Duration     | yes      |
    \endtable

The following common ramp functions are provided: linear, quadratic, halfCosine,
quarterCosine and quaterSine, others can easily be added and registered to the run-time
selection system.