Specifying a plane with which to subset feature edges is now done using
the same dictionary syntax used elsewhere in OpenFOAM. For example, in
system/surfaceFeaturesDict:
subsetFeatures
{
// Include only edges that intersect the plane
plane
{
planeType pointAndNormal;
point (0 0 0);
normal (1 0 0);
}
...
}
A modified Arrhenius reaction rate given by:
k = (A * T^beta * exp(-Ta/T))*a
Where a is the phase surface area per unit volume. The name of the phase is
specified by the user.
Example usage:
oxidationAtSurface
{
type irreversiblePhaseSurfaceArrhenius;
reaction "O2^0 + TiCl4 = TiO2_s + 2Cl2";
A 4.9e1; // The pre-exponential factor is in units
// equal to that in the usual volumetric
// reaction rate **divided by length**, as
// the Arrhenius expression is taken to give
// rate per unit area, not per unit volume
beta 0.0;
Ta 8993;
phase particles;
}
This reaction has been applied to the titaniaSynthesisSurface tutorial,
which avoids the need for explicit caching of the surface area density
field.
This function gives a value of one during a user-specified duration, and
zero at all other times. It is useful for defining the time range in
which an injection or ignition heat source or similar operates.
Example usage, scaling a value:
<name>
{
type scale;
scale squarePulse;
start 0;
duration 1;
value 100;
}
This function has been utilised in a number of tutorial fvOption
configurations to provide a specific window in which the fvOption is
applied. This was previously achieved by "timeStart" and "duration"
controls hard coded into the fvOptions themselves.
This fvOption applies a mass source to the continuity equation and to
all field equations.
Example usage:
massSource
{
type massSource;
selectionMode cellSet;
cellSet massSource;
massFlowRate 1e-4;
fieldValues
{
U (10 0 0);
T 350;
k 0.375;
epsilon 14.855;
}
}
Values should be provided for all solved for fields. Warnings will be
issued if values are not provided for fields for which transport equations
are solved. Warnings will also be issued if values are provided for fields
which are not solved for.
A number of fvOptions that apply to a user-derined field can now
automatically work what primitive type they apply to. These options can
apply to any field type, and in some cases even multiple fields of
differing type. Example usage of the options to which this change
applies are shown below:
codedSource1
{
type codedSource;
name codedSource1;
field h;
...
}
fixedValueConstraint1
{
type fixedValueConstraint;
fieldValues
{
R (1 0 0 1 0 1);
epsilon 150;
}
...
}
phaseLimitStabilization11
{
type phaseLimitStabilization;
field sigma.liquid;
...
}
Previously to apply to a given type, these options had to be selected
with the name of the type prepended to the option name (e.g., "type
symmTensorPhaseLimitStabilization;") and those that operated on multiple
fields were restricted to those fields being of the same type.
A number of other options have had improvements made to their handling
of user specification of fields. Where possible, the option will now
attempt to work out what field the option applies to automatically. The
following options, therefore, no longer require "field" or "fields"
entries:
actuationDiskSource
buoyancyEnergy
buoyancyForce
meanVelocityForce
rotorDiskSource
volumeFractionSource
constantHeatTransfer
function2HeatTransfer
variableHeatTransfer
Non-standard field names can be overridden in the same way as in
boundary conditions; e.g., the velocity name can be overridden with a "U
<UName>;" entry if it does not have the default name, "U". The name of
the energy field is now always determined from the thermodynamics
model and should always be correct. Some options that can be applied to
an individual phase also support a "phase <phaseName>;" entry;
fvOptions field-name handling has been rewritten to increase its
flexibility and to improve warning messages. The flexibility now allows
for options that apply to all fields, or all fields of a given phase,
rather than being limited to a specific list of field names. Messages
warning about options that have not been applied now always print just
once per time-step.
The injection models do not inject parcels into the film they specifically eject
parcels from the film and the name "injection" is very confusing and misleading
hence the logical rename injection -> ejection.
Vertices are generated using run time compilation functionality.
File duplication avoided by placement in:
tutorials/resources/blockMesh/sloshingTank2D
tutorials/resources/blockMesh/sloshingTank3D
Originally the only supported geometry specification were triangulated surfaces,
hence the name of the directory: constant/triSurface, however now that other
surface specifications are supported and provided it is much more logical that
the directory is named accordingly: constant/geometry. All tutorial and
template cases have been updated.
Note that backward compatibility is provided such that if the constant/geometry
directory does not exist but constant/triSurface does then the geometry files
are read from there.
Mesh-motion with or without topology change or AMI is now supported in
multiphaseEulerFoam for both cell- and face-momentum algorithms.
The new tutorial case mixerVesselAMI2D is provided which is the AMI version of
the 4-phase MRF mixerVessel2D case. It is setup with the cell-momentum
algorithm but also runs fine with the face-momentum algorithm although the
results are noticeably less accurate, particularly when the case is run
single-phase and compared directly with those from pimpleFoam.
Further testing is in progress.
I2D/constant/thermophysicalProperties.water
The phase-change functionality in interPhaseChangeFoam has been generalised and
moved into the run-time selectable twoPhaseChange library included into
interFoam providing optional phase-change. The three cavitation models provided
in interPhaseChangeFoam are now included in the twoPhaseChange library and the
two interPhaseChangeFoam cavitation tutorials updated for interFoam.
interPhaseChangeFoam has been replaced by a user redirection script which prints
the following message:
The interPhaseChangeFoam solver has solver has been replaced by the more general
interFoam solver, which now supports phase-change using the new twoPhaseChange
models library.
To run with with phase-change create a constant/phaseChangeProperties dictionary
containing the phase-change model specification, e.g.
phaseChangeModel SchnerrSauer;
pSat 2300; // Saturation pressure
See the following cases for an example converted from interPhaseChangeFoam:
$FOAM_TUTORIALS/multiphase/interFoam/laminar/cavitatingBullet
$FOAM_TUTORIALS/multiphase/interFoam/RAS/propeller
A dynamicMotionSolverFvMesh must now use a "motionSolver" or
"motionSolvers" entry to select the underlying motion solver. For
example, in constant/dynamicMeshDict:
dynamicFvMesh dynamicMotionSolverFvMesh;
motionSolverLibs ("librigidBodyMeshMotion.so");
motionSolver rigidBodyMotion;
...
Previously the motion solver could also be specified with the keyword
"solver", but this resulted in a name clash with rigid body solvers
which are frequently specified in the same scope. For this reason, the
"solver" and "solvers" entries have been removed.
End points of topoSet cylinder sources should now be specified as
"point1" and "point2", which is consistent with other parts of the code.
The previous keywords, "p1" and "p2" have been retained for backwards
compatibility but may be removed in future.
A volumetric flow rate through a tri-surface can now be obtained using
the volumetricFlowRateTriSurface preconfigured function object, using
the following entry in system/controlDict:
fuctions
{
#includeFunc "volumetricFlowRateTriSurface(name=surface.stl)"
}
Where "surface.stl" is a tri-surface file in the constant/triSurface
directory. An example of this has been added to the
incompressible/pimpleFoam/RAS/impeller tutorial case.
Note that when possible, it is preferable to use the flowRatePatch or
flowRateFaceZone functions, as these make direct use of the flux and
therefore report a value that is exactly that computed by the solver.
volumetricFlowRateTriSurface, by contrast, does interpolation of the
velocity field which introduces error.
In addition, a minor fix has been made to the underlying
surfaceFieldValue function object so that it does not need a zone/set
name when values on a searchable surface are requested.
Description
Transforms the specified velocity field into a
cylindrical polar coordinate system or back to Cartesian.
Example of function object specification to convert the velocity field U
into cylindrical polar coordinates before averaging and returning the
average to Cartesian coordinates:
\verbatim
cartesianToCylindrical
{
type cylindrical;
libs ("libfieldFunctionObjects.so");
origin (0 0 0);
axis (0 0 1);
field U;
writeControl outputTime;
writeInterval 1;
}
#includeFunc fieldAverage(cylindrical(U))
cylindricalToCartesian
{
type cylindrical;
libs ("libfieldFunctionObjects.so");
origin (0 0 0);
axis (0 0 1);
field cylindrical(U)Mean;
toCartesian true;
result UMean;
writeControl outputTime;
writeInterval 1;
}
\endverbatim
This is particularly useful for cases with rotating regions, e.g. mixer
vessels with AMI.
See tutorials/incompressible/pimpleFoam/laminar/mixerVesselAMI2D
This simplifies and standardises the handling of radiation in all solvers which
include an energy equation, all of which now support radiation via the
'radiation' fvOption which is selected in the constant/fvOption or
constant/<region>/fvOption file:
radiation
{
type radiation;
libs ("libradiationModels.so");
}
The radiation model, parameters, settings and sub-models are specified in the
'radiationProperties' file as before.
It is better to not select and instantiate a model, fvOption etc. than to create
it and set it inactive as the creation process requires reading of settings,
parameters, fields etc. with all the associated specification and storage
without being used. Also the incomplete implementation added a lot of
complexity in the low-level operation of models introducing a significant
maintenance overhead and development overhead for new models.
The convoluted separate ".*Coeffs" dictionary form of model coefficient
specification is now deprecated and replaced with the simpler sub-dictionary
form but support is provided for the deprecated form for backward comparability.
e.g.
thermophysicalProperties
{
type liquid;
useReferenceValues no;
liquid H2O;
}
rather than
filmThermoModel liquid;
liquidCoeffs
{
useReferenceValues no;
liquid H2O;
}
and
forces
{
thermocapillary;
distributionContactAngle
{
Ccf 0.085;
distribution
{
type normal;
normalDistribution
{
minValue 50;
maxValue 100;
expectation 75;
variance 100;
}
}
zeroForcePatches ();
}
}
rather than
forces
(
thermocapillary
distributionContactAngle
);
distributionContactAngleCoeffs
{
Ccf 0.085;
distribution
{
type normal;
normalDistribution
{
minValue 50;
maxValue 100;
expectation 75;
variance 100;
}
}
zeroForcePatches ();
}
All the tutorial cases containing a surface film have been updated for guidance,
e.g. tutorials/lagrangian/buoyantReactingParticleFoam/hotBoxes/constant/surfaceFilmProperties
surfaceFilmModel thermoSingleLayer;
regionName wallFilmRegion;
active true;
thermophysicalProperties
{
type liquid;
useReferenceValues no;
liquid H2O;
}
viscosity
{
model liquid;
}
deltaWet 1e-4;
hydrophilic no;
momentumTransport
{
model laminar;
Cf 0.005;
}
forces
{
thermocapillary;
distributionContactAngle
{
Ccf 0.085;
distribution
{
type normal;
normalDistribution
{
minValue 50;
maxValue 100;
expectation 75;
variance 100;
}
}
zeroForcePatches ();
}
}
injection
{
curvatureSeparation
{
definedPatchRadii
(
("(cube[0-9][0-9]_side[0-9]_to_cube[0-9][0-9]_side[0-9])" 0)
);
}
drippingInjection
{
cloudName reactingCloud1;
deltaStable 0;
particlesPerParcel 100.0;
parcelDistribution
{
type RosinRammler;
RosinRammlerDistribution
{
minValue 5e-04;
maxValue 0.0012;
d 7.5e-05;
n 0.5;
}
}
}
}
phaseChange
{
model standardPhaseChange;
Tb 373;
deltaMin 1e-8;
L 1.0;
}
upperSurfaceModels
{
heatTransfer
{
model mappedConvectiveHeatTransfer;
}
}
lowerSurfaceModels
{
heatTransfer
{
model constant;
c0 50;
}
}
TableBase, TableFile and Table now combined into a single simpler Table class
which handle both the reading of embedded and file data using the generalised
TableReader. The new EmbeddedTableReader handles the embedded data reading
providing the functionality of the original Table class within the same
structure that can read the data from separate files.
The input format defaults to 'embedded' unless the 'file' entry is present and
the Table class is added to the run-time selection table under the name 'table'
and 'tableFile' which provides complete backward comparability. However it is
advisable to migrate cases to use the new 'table' entry and all tutorial cases
have been updated.
using Function1 and supporting all the standard Function1s including tabulated
and coded.
tutorials/multiphase/interFoam/laminar/sloshingTank3D6DoF updated to use
sixDoFMotion.
