provides optional control for solving the pyrolysis region.

Patch contributed by Karl Meredith, FMGlobal.

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.

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.

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 52d83407

fvOptions does not have the appropriate structure to support MRF as it
is based on option selection by user-specified fields whereas MRF MUST
be applied to all velocity fields in the particular solver.  A
consequence of the particular design choices in fvOptions made it
difficult to support MRF for multiphase and it is easier to support
frame-related and field related options separately.

Currently the MRF functionality provided supports only rotations but
the structure will be generalized to support other frame motions
including linear acceleration, SRF rotation and 6DoF which will be
run-time selectable.

Allows the specification of a reference height, for example the height
of the free-surface in a VoF simulation, which reduces the range of p_rgh.

hRef is a uniformDimensionedScalarField specified via the constant/hRef
file, equivalent to the way in which g is specified, so that it can be
looked-up from the database.  For example see the constant/hRef file in
the DTCHull LTSInterFoam and interDyMFoam cases.

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

fixedFluxPressure BC: the snGrad is now pushed into the BC from pEqn.H rather than being evaluated in the BC

combustion)

Automated the caching of "finalIteration".

This reverts commit c5bea524.

This reverts commit b18f6cc1.

Exception: applyWallFunctionBoundaryConditions.C cannot split #include
directives.

Relaxation and solution parameters for the final iteration in PIMPLE loops are
now selected according to the value of the "finalIteration" entry in the
mesh::data dictionary.

rhoPimpleFoam significantly updates and now replaces rhoPisoFoam.

For non-premixed combustion using sensible enthalpy.

uniformDimensionedVectorField.

New, improved with p rather than pd, PIMPLE rather than PISO and more general handling of the diffusivity.

location for the specification is the same as that for the pd level.

- change system/controlDict to use functions {..} instead of functions (..);
  * This is internally more efficient
- fixed formatting of system/controlDict functions entry

- pedantic change: use 'return 0' instead of 'return(0)' in the applications,
  since return is a C/C++ keyword, not a function.

- this (now deprecated) idiom:
      for (runTime++; !runTime.end(); runTime++) { ... }
  has a few problems:
    * stop-on-next-write will be off-by-one (ie, doesn't work)
    * function objects are not executed on exit with runTime.end()
  Fixing these problems is not really possible.

- this idiom
      while (runTime.run())
      {
          runTime++;
          ...
      }
  works without the above problems.