foamDictionary executions are now wrapped by runApplication like any
other execution so that they do not print during a test loop.
foamDictionary does not produce a conforming log, however, so
log.foamDictionary has been filtered out of the formation of the test
loop report so that false failures are not reported.
This means a plane can now be specified like this:
planeType pointAndNormal;
point (0 0 0);
normal (0 0 1);
As well as this:
planeType pointAndNormal;
pointAndNormalDict
{
point (0 0 0);
normal (0 0 1);
}
The new optional 'slash' scoping syntax is now the default and provides a more
intuitive and flexible syntax than the previous 'dot' syntax, corresponding to
the common directory/file access syntax used in UNIX, providing support for
reading entries from other dictionary files.
In the 'slash' syntax
'/' is the scope operator
'../' is the parent dictionary scope operator
'!' is the top-level dictionary scope operator
Examples:
internalField 3.4;
active
{
type fixedValue;
value.air $internalField;
}
inactive
{
type anotherFixedValue;
value $../active/value.air;
anotherValue $!active/value.air;
sub
{
value $../../active/value.air;
anotherValue $!active/value.air;
}
}
"U.*"
{
solver GAMG;
}
e.air
{
$U.air;
}
external
{
value $testSlashDict2!active/value.air;
}
active2
{
$testSlashDict2!active;
}
If there is a part of the keyword before the '!' then this is taken to be the
file name of the dictionary from which the entry will be looked-up using the
part of the keyword after the '!'. For example given a file testSlashDict containing
internalField 5.6;
active
{
type fixedValue;
value.air $internalField;
}
entries from it can be read directly from another file, e.g.
external
{
value $testSlashDict2!active/value.air;
}
active2
{
$testSlashDict2!active;
}
which expands to
external
{
value 5.6;
}
active2
{
type fixedValue;
value.air 5.6;
}
These examples are provided in applications/test/dictionary.
The the default syntax can be changed from 'slash' to 'dot' in etc/controlDict
to revert to the previous behaviour:
OptimisationSwitches
{
.
.
.
// Default dictionary scoping syntax
inputSyntax slash; // Change to dot for previous behaviour
}
or within a specific dictionary by adding the entry
See applications/test/dictionary/testDotDict.
gcc version 5 and above and clang version 3.4 and above fully support the C++14
standard and the compilation rules of OpenFOAM-dev now require this support
allowing for further development and maintenance to benefit from the additional
language features provided in C++14.
For example
thermo:rho.air1
{
explicit 3e-07;
implicit 0;
}
f1.air1.bubbles
{
value 3.5;
explicit #calc "$value*$../thermo:rho.air1/explicit";
implicit 0;
}
now works, whereas previously an extra level of '../' was required:
explicit #calc "$value*$../../thermo:rho.air1/explicit";
because #calc created its own sub-dictionary. The '$value' would have also
needed a '../' except that the 'value' entry is in the direct parent and could
be looked-up automatically by the parent search.
The reactingtTwoPhaseEulerFoam solver has been replaced by the more general
multiphaseEulerFoam solver which supports two-phase and multiphase systems
containing fluid and stationary phases, compressible or incompressible, with
heat and mass transfer, reactions, size distribution and all the usual phase
interaction and transfer models.
All reactingtTwoPhaseEulerFoam tutorials have been ported to multiphaseEulerFoam
to demonstrate two-phase capability with a wide range of phase and
phase-interaction models.
When running with two-phases the optional referencePhase entry in
phaseProperties can be used to specify which phase fraction should not be
solved, providing compatibility with reactingtTwoPhaseEulerFoam, see
tutorials/multiphase/multiphaseEulerFoam/RAS/fluidisedBed
tutorials/multiphase/multiphaseEulerFoam/laminar/bubbleColumn
for examples.
Description
Stops the run when the specified clock time in second has been reached
and optionally write results before stopping.
The following actions are supported:
- noWriteNow
- writeNow
- nextWrite (default)
Examples of function object specification:
\verbatim
stop
{
type stopAtClockTime;
libs ("libutilityFunctionObjects.so");
stopTime 10;
action writeNow;
}
\endverbatim
will stop the run at the next write after the file "stop" is created in the
case directory.
Usage
\table
Property | Description | Required | Default value
type | type name: stopAtClockTime | yes |
stopTime | Maximum elapsed time [s] | yes |
action | Action executed | no | nextWrite
\endtable
By default the case stops following the next write but stopping immediately with
or without writing are also options.
The stopAtFile functionObject derived from stopAt stops the run when a file
predefined file is created in the case directory:
Description
Stops the run when the specified file is created in the case directory.
The default name of the trigger file is \c $FOAM_CASE/<name> where \c
<name> is the name of the functionObject entry and the default action is \c
nextWrite.
Currently the following action types are supported:
- noWriteNow
- writeNow
- nextWrite
Examples of function object specification:
\verbatim
stop
{
type stopAtFile;
libs ("libutilityFunctionObjects.so");
}
\endverbatim
will stop the run at the next write after the file "stop" is created in the
case directory.
\verbatim
stop
{
type stopAtFile;
libs ("libutilityFunctionObjects.so");
file "$FOAM_CASE/stop";
action writeNow;
}
\endverbatim
will write the fields and stop the run when the file "stop" is created in
the case directory.
Usage
\table
Property | Description | Required | Default value
type | type name: stopAtFile | yes |
file | Trigger file path name | no | $FOAM_CASE/<name>
action | Action executed | no | nextWrite
\endtable
The new multiphaseEulerFoam is based on reactingMultiphaseEulerFoam with some
improvements and rationalisation to assist maintenance and further development.
The phase system solution has been enhanced to handle two phases more
effectively and all two-phase specific models updated for compatibility so that
multiphaseEulerFoam can also replace reactingTwoPhaseEulerFoam.
When running multiphaseEulerFoam with only two-phases the default behaviour is
to solve for both phase-fractions but optionally a reference phase can be
specified so that only the other phase-fraction is solved, providing better
compatibility with the behaviour of reactingTwoPhaseEulerFoam.
All reactingMultiphaseEulerFoam and reactingTwoPhaseEulerFoam tutorials have
been updated for multiphaseEulerFoam.
The base phaseSystem now provides all the functionality needed for
reactingMultiphaseEulerFoam and twoPhaseSystem is a specialisation, simplifying
maintenance.
Description
This functionObject writes the phase-fraction map field alpha.map with
incremental value ranges for each phase
e.g., with values 0-1 for water, 1-2 for air, 2-3 for oil etc.
Example of function object specification:
\verbatim
phaseMap
{
type phaseMap;
libs ("libreactingEulerFoamFunctionObjects.so");
writeControl writeTime;
}
\endverbatim
Usage
\table
Property | Description | Required | Default value
type | type name: phaseMap | yes |
\endtable
This replaces the alphas functionality previously built-in to
reactingMultiphaseEulerFoam so that the storage, calculation and writing of the
phase map field is now under user control.
The optional reference phase fraction field is not read even if the file is
present, it is constructed with "calculated" BCs as it is a derived field. All
other phase fraction field files are read and now must be present.
for compatibility with reactingMultiphaseEulerFoam when run with two-phases.
Some of these two-phase models could be enhanced to operate with multiple
dispersed phases in the future.
In order to update these models for reactingMultiphaseEulerFoam it has been
necessary to break compatibility with the now redundant twoPhaseEulerFoam solver
which has been superseded by the much more capable reactingEulerFoam solvers and
now removed.
to ensure the velocity and flux of the phases sum the conservative mixture
values obtained from the pressure solution.
Also corrected handling of MRF and updated to work with partial elimination.
The cellZoneInjection now correctly fills all tets of a given cell with
a random distribution of particles. Previously an error in the
calculation of the cumulative tet volume fractions for a cell meant that
one tet never had any particles injected into it.
