for chemFoam, fireFoam, buoyantReactingFoam, reactingFoam, chtMultiRegionFoam,
buoyantReactingParticleFoam, reactingParticleFoam, simpleReactingParticleFoam
If the combination of property models selected in thermophysicalProperties is
not already compiled and present in the standard libraries the thermophysical
property package will be constructed and compiled automatically using the
standard dynamicCode system provided in OpenFOAM.
The thermophysical property package is constructed automatically from the
etc/codeTemplates/dynamicCode files for the corresponding base thermo type,
fluidThermo, fluidReactionThermo etc. If the corresponding codeTemplates files
do not exist the standard thermo lookup error message is generated as before.
As with all other dynamicCode options in OpenFOAM (codeStream,
codedFunctionObject etc.) dynamic compilation of the thermophysical property
package is only enabled if allowSystemOperations is set true.
Chemistry integration occurs over the simulation timestep, and should
therefore be initialised with old time properties. This is now the case.
This means that outer iteration of the chemistry within a timestep is
now correct.
In addition, the laminar combustion model (and derivations) has a new
flag which prevents it from being corrected more than once per timestep.
This flag is true by default, as outer iteration of a typical reaction
system is expensive and provides limited benefit.
If the combination of property models selected in thermophysicalProperties is
not already compiled and present in the standard libraries the thermophysical
property package will be constructed and compiled automatically using the
standard dynamicCode system provided in OpenFOAM.
The thermophysical property package is constructed automatically from the
etc/codeTemplates/dynamicCode files for the corresponding base thermo
type (e.g. fluidThermo), currently these are provided only for fluidThermo but
the others will be added shortly. If the corresponding codeTemplates files do
not exist the standard thermo lookup error message is generated as before.
As with all other dynamicCode options in OpenFOAM (codeStream,
codedFunctionObject etc.) dynamic compilation of the thermophysical property
package is only enabled if allowSystemOperations is set true.
divU is cached before mesh-motion and mapped post-motion to drive the optional pcorr flux
update to ensure the fluxes are conservative following mesh motion and change.
The phase system now have the ability to specify the derivative of mass
transfer rates w.r.t. pressure. This permits implicit handling of
pressure-coupled mass transfer processes.
This implicit handling has been applied to the mass transfers that are
modelled by the thermal phase system. This should result in significant
stability improvements. The implicit handling can be toggled on or off
by means of a "pressureImplicit" switch in constant/phaseProperties. It
is on by default.
Patch contributed by Juho Peltola, VTT.
The former implementation of the daughterSizeDistributionModel based on
Laakkonen et al. (2006) had the issue of not conserving the total
particle number and volume properly, except when the coefficient C4 is
set to a value of 2. The issue is solved by following the work of
Laakkonen et al. (2007).
The default coefficients in both the breakupModel and the
daughterSizeDistributionModel were updated as well according to the
suggestions of the authors.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
and VTT Technical Research Centre of Finland Ltd.
The current implementation of the uniform daughterSizeDistribution model
is not general enough to support uniform breakup into multiple fragments
while conserving both the total particle number and volume, except for
binary breakup (which was the default setting).
The model has therefore been renamed to uniformBinary, i.e. resulting in
two fragments.
It is currently used for verification purposes only. If the need for a
more general form arises, then that will require additional development.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
and VTT Technical Research Centre of Finland Ltd.
Description
Dynamic mesh refinement/unrefinement based on volScalarField values.
Refinement can optionally be specified in a cellZone or in multiple
regions, each controlled by a different volScalarField.
Usage
Example of single field based refinement in all cells:
\verbatim
dynamicFvMesh dynamicRefineFvMesh;
// How often to refine
refineInterval 1;
// Field to be refinement on
field alpha.water;
// Refine field in between lower..upper
lowerRefineLevel 0.001;
upperRefineLevel 0.999;
// If value < unrefineLevel unrefine
unrefineLevel 10;
// If value < unrefineLevel (default=great) unrefine
// unrefineLevel 10;
// Have slower than 2:1 refinement
nBufferLayers 1;
// Refine cells only up to maxRefinement levels
maxRefinement 2;
// Stop refinement if maxCells reached
maxCells 200000;
// Flux field and corresponding velocity field. Fluxes on changed
// faces get recalculated by interpolating the velocity. Use 'none'
// on surfaceScalarFields that do not need to be reinterpolated.
correctFluxes
(
(phi none)
(nHatf none)
(rhoPhi none)
(alphaPhi0.water none)
(ghf none)
);
// Write the refinement level as a volScalarField
dumpLevel true;
\endverbatim
Example of single field based refinement in two regions:
\verbatim
dynamicFvMesh dynamicRefineFvMesh;
// How often to refine
refineInterval 1;
refinementRegions
{
region1
{
cellZone refinementRegion1;
// Field to be refinement on
field alpha.water;
// Refine field in between lower..upper
lowerRefineLevel 0.001;
upperRefineLevel 0.999;
// Refine cells only up to maxRefinement levels
maxRefinement 1;
// If value < unrefineLevel unrefine
unrefineLevel 10;
}
region2
{
cellZone refinementRegion2;
// Field to be refinement on
field alpha.water;
// Refine field in between lower..upper
lowerRefineLevel 0.001;
upperRefineLevel 0.999;
// Refine cells only up to maxRefinement levels
maxRefinement 2;
// If value < unrefineLevel unrefine
unrefineLevel 10;
}
}
// If value < unrefineLevel (default=great) unrefine
// unrefineLevel 10;
// Have slower than 2:1 refinement
nBufferLayers 1;
// Stop refinement if maxCells reached
maxCells 200000;
// Flux field and corresponding velocity field. Fluxes on changed
// faces get recalculated by interpolating the velocity. Use 'none'
// on surfaceScalarFields that do not need to be reinterpolated.
correctFluxes
(
(phi none)
(nHatf none)
(rhoPhi none)
(alphaPhi0.water none)
(ghf none)
);
// Write the refinement level as a volScalarField
dumpLevel true;
\endverbatim
for consistency with the the book on which the implementation of
spatialTransform is based:
Featherstone, R. (2008).
Rigid body dynamics algorithms.
Springer.
The MomentumTransportModels library now builds of a standard set of
phase-incompressible and phase-compressible models. This replaces most
solver-specific builds of these models.
This has been made possible by the addition of a new
"dynamicTransportModel" interface, from which all transport classes used
by the momentum transport models now derive. For the purpose of
disambiguation, the old "transportModel" has also been renamed
"kinematicTransportModel".
This change has been made in order to create a consistent definition of
phase-incompressible and phase-compressible MomentumTransportModels,
which can then be looked up by functionObjects, fvModels, and similar.
Some solvers still build specific momentum transport models, but these
are now in addition to the standard set. The solver does not build all
the models it uses.
There are also corresponding centralised builds of phase dependent
ThermophysicalTransportModels.
so that they operate in the conventional manner in a right-handed coordinate
system:
//- Rotational transformation tensor about the x-axis by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Rx(const scalar& omega)
//- Rotational transformation tensor about the y-axis by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Ry(const scalar& omega)
//- Rotational transformation tensor about the z-axis by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Rz(const scalar& omega)
//- Rotational transformation tensor about axis a by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Ra(const vector& a, const scalar omega)
Description
Transform (translate, rotate, scale) a surface.
Usage
\b surfaceTransformPoints "\<transformations\>" \<input\> \<output\>
Supported transformations:
- \par translate=<translation vector>
Translational transformation by given vector
- \par rotate=(\<n1 vector\> \<n2 vector\>)
Rotational transformation from unit vector n1 to n2
- \par Rx=\<angle [deg] about x-axis\>
Rotational transformation by given angle about x-axis
- \par Ry=\<angle [deg] about y-axis\>
Rotational transformation by given angle about y-axis
- \par Rz=\<angle [deg] about z-axis\>
Rotational transformation by given angle about z-axis
- \par Ra=\<axis vector\> \<angle [deg] about axis\>
Rotational transformation by given angle about given axis
- \par scale=\<x-y-z scaling vector\>
Anisotropic scaling by the given vector in the x, y, z
coordinate directions
Example usage:
surfaceTransformPoints \
"translate=(-0.586 0 -0.156), \
Ry=3.485, \
translate=(0.586 0 0.156)" \
constant/geometry/w3_orig.stl constant/geometry/w3.stl
The transformation sequence is specified like a substitution string used by
Description
Transform (translate, rotate, scale) a surface.
The rollPitchYaw option takes three angles (degrees):
- roll (rotation about x) followed by
- pitch (rotation about y) followed by
- yaw (rotation about z)
The yawPitchRoll does yaw followed by pitch followed by roll.
Usage
\b surfaceTransformPoints "\<transformations\>" \<input\> \<output\>
Example usage:
surfaceTransformPoints \
"translate=(-0.586 0 -0.156), \
rollPitchYaw=(0 -3.485 0), \
translate=(0.586 0 0.156)" \
constant/geometry/w3_orig.stl constant/geometry/w3.stl
Multiple substitutions can be made using the convenient -set "<substitutions>"
option which combines the selection of the entries with the substitutions made
on them using the same argument syntax used by #includeFunc, e.g.
foamDictionary system/controlDict -set "startTime=2000, endTime=3000"
Assuming the heat required to cause the phase change is provided by the film the
energy transferred with the mass to the primary region corresponds to vapour
at the film surface temperature.
Currently the NSRDS-based liquid properties provide no support for pressure and
the enthalpy functions do not include any pressure effects thus internal energy
is equal to the enthalpy. If used with an enthalpy equation the pressure-work
term should not be included.
The constant heat capacity hacked thermo in surfaceFilmModels and the
corresponding transfer terms in Lagrangian have been replaced by the standard
OpenFOAM rhoThermo which provides a general handling of thermo-physical
properties, in particular non-constant heat capacity. Further rationalisation
of liquid and solid properties has also been undertaken in support of this work
to provide a completely consistent interface to sensible and absolute enthalpy.
Now for surfaceFilmModels the thermo-physical model and properties are specified
in a constant/<region>/thermophysicalProperties dictionary consistent with all
other types of continuum simulation.
This significantly rationalises, simplifies and generalises the handling of
thermo-physical properties for film simulations and is a start at doing the same
for Lagrangian.
