- A few without a 'cd' at the start.
  Use $(getApplication) directly in more places (for clarity).

to handle the effect of condensation and evaporation on bubble size

to handle the size of bubbles created by boiling.  To be used in
conjunction with the alphatWallBoilingWallFunction boundary condition.

The IATE variant of the wallBoiling tutorial case is provided to
demonstrate the functionality:

tutorials/multiphase/reactingTwoPhaseEulerFoam/RAS/wallBoilingIATE

then restart with boiling.

Contributed by Juho Peltola, VTT

Contributed by Juho Peltola, VTT

Notable changes:

    1. The same wall function is now used for both phases, but user must
       specify phaseType ‘liquid’ or ‘vapor’

    2. Runtime selectable submodels for:
       - wall heat flux partitioning between the phases
       - nucleation site density
       - bubble departure frequency
       - bubble departure diameter

    3. An additional iteration loop for the wall boiling model in case
       the initial guess for the wall temperature proves to be poor.

The wallBoiling tutorial has been updated to demonstrate this new functionality.

Fixes wallBoiling mentioned in #141

values; formatted Switch entries consistently across all cases

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/caseDict...

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.

This changes simplifies the specification of functionObjects in
controlDict and is consistent with the 'libs' option in controlDict to
load special solver libraries.

Support for the old 'functionObjectLibs' name is supported for backward compatibility.

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.

functionObjects: Changed options 'outputControl' -> 'writeControl' and 'outputInterval' -> 'writeInterval'

for consistency with the time controls in controlDict and to avoid
unnecessary confusion.  All code and tutorials have been updated.

The old names 'outputControl' and 'outputInterval' are but supported for
backward compatibility but deprecated.

tutorials/multiphase/reactingTwoPhaseEulerFoam/RAS/wallBoiling/system/fvSolution: Updated to improve stability

See http://www.openfoam.org/mantisbt/view.php?id=2076
  - .org is the file extension for emacs org-mode as well
  - .orig is more to the point (.org isn't always recognized as "original")
  - .original is too long, although more consistent with the convention
    of source code file naming

Update script contributed by Bruno Santos

Patch contributed by Juho Peltola, VTT

The new JohnsonJacksonSchaefferFrictionalStress model is included and
the LBend tutorial case to demonstrate the need for the changes to the
frictional stress models.

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

Code and tutorial case provided by Juho Peltola

so that the specification of the name and dimensions are optional in property dictionaries.

Update tutorials so that the name of the dimensionedScalar property is
no longer duplicated but optional dimensions are still provided and are
checked on read.

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

tutorials/multiphase/reactingTwoPhaseEulerFoam/RAS/bubbleColumnEvaporatingReacting: Correct initial pressure to 10bar

Multi-species, mass-transfer and reaction support and multi-phase
structure provided by William Bainbridge.

Integration of the latest p-U and face-p_U algorithms with William's
multi-phase structure is not quite complete due to design
incompatibilities which needs further development.  However the
integration of the functionality is complete.

The results of the tutorials are not exactly the same for the
twoPhaseEulerFoam and reactingTwoPhaseEulerFoam solvers but are very
similar.  Further analysis in needed to ensure these differences are
physical or to resolve them; in the meantime the twoPhaseEulerFoam
solver will be maintained.