The writeEntry form is now defined and used consistently throughout OpenFOAM
making it easier to use and extend, particularly to support binary IO of complex
dictionary entries.
This is like the scalarTrasport function except that the transported
scalar is confined to a single phase of a multiphase simulation. In
addition to the usual specification for the scalarTransport function
(i.e., a field, schemes and solution parameters), the user needs to
specify the phase-flux or a pressure field which can be used to generate
it.
Example usage for interFoam:
phaseScalarTransport1
{
type phaseScalarTransport;
libs ("libsolverFunctionObjects.so");
field s.water;
p p_rgh;
}
Example usage for reactingTwoPhaseEulerFoam:
phaseScalarTransport1
{
type phaseScalarTransport;
libs ("libsolverFunctionObjects.so");
field s.water;
alphaPhi alphaRhoPhi.water;
rho thermo:rho.water;
}
The function will write out both the per-unit-phase field that is solved
for (s.water in the above examples) and also the mixture-total field
(alphaS.water), which is often more convenient for post-processing.
to rationalise the structure and class names to avoid the need for the confusing
addNamedToRunTimeSelectionTable and use instead use the standard
addToRunTimeSelectionTable to populate the run-time selection table.
With the inclusion of boundary layer modelling in the gas, the
separation of wave perturbation from and mean flow became less useful,
and potentially prevents further extension to support similar boundary
layer modelling in the liquid.
The mean velocity entry, UMean, is now needed in the
constant/waveProperties file rather than in the waveVelocity boundary
condition.
In order to increase the flexibility of the wave library, the mean flow
handling has been removed from the waveSuperposition class. This makes
waveSuperposition work purely in terms of perturbations to a mean
background flow.
The input has also been split, with waves now defined as region-wide
settings in constant/waveProperties. The mean flow parameters are sill
defined by the boundary conditions.
The new format of the velocity boundary is much simpler. Only a mean
flow velocity is required.
In 0/U:
boundaryField
{
inlet
{
type waveVelocity;
UMean (2 0 0);
}
// etc ...
}
Other wave boundary conditions have not changed.
The constant/waveProperties file contains the wave model selections and
the settings to define the associated coordinate system and scaling
functions:
In constant/waveProperties:
origin (0 0 0);
direction (1 0 0);
waves
(
Airy
{
length 300;
amplitude 2.5;
phase 0;
angle 0;
}
);
scale table ((1200 1) (1800 0));
crossScale constant 1;
setWaves has been changed to use a system/setWavesDict file rather than
relying on command-line arguments. It also now requires a mean velocity
to be specified in order to prevent ambiguities associated with multiple
inlet patches. An example is shown below:
In system/setWavesDict:
alpha alpha.water;
U U;
liquid true;
UMean (1 0 0);
This object calculates a field of the age of fluid in the domain; i.e.,
the time taken for a fluid particle to travel to a location from an
inlet. It outputs a field, named age, with dimensions of time, and
requires a solver and a div(phi,age) scheme to be specified. A number of
corrections for the solution procedure can be set, as well as the name
of the flux and density fields.
Example specification:
age1
{
type age;
libs ("libfieldFunctionObjects.so");
nCorr 10;
phi phi;
rho rho;
}
Example usage:
postProcess -func age -fields "(phi)" -latestTime
This work was supported by Robert Secor and Lori Holmes, at 3M
to simplify reacting case setup.
Tutorials
tutorials/combustion/chemFoam/ic8h18_TDAC
tutorials/combustion/reactingFoam/RAS/SandiaD_LTS
tutorials/combustion/reactingFoam/laminar/counterFlowFlame2DLTS_GRI_TDAC
tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D_GRI_TDAC
updated to benefit from the new configuration files.
Patch contributed by Francesco Contino
Description
Calculates the natural logarithm of the specified scalar field.
Performs \f$ln(max(x, a))\f$ where \f$x\f$ is the field and \f$a\f$ an
optional clip to handle 0 or negative \f$x\f$.
The etc/caseDicts/postProcessing/fields/log configuration file is provided so
that the simple #includeFunc can be used to execute this functionObject during
the run, e.g. for some dimensionless field x
functions
{
#includeFunc log(x)
}
or if x might be 0 or negative in some regions the optional clip may be applied:
functions
{
#includeFunc log(p,clip=1e-6)
}
The sampled sets have been renamed in a more explicit and consistent
manner, and two new ones have also been added. The available sets are as
follows:
arcUniform: Uniform samples along an arc. Replaces "circle", and
adds the ability to sample along only a part of the circle's
circumference. Example:
{
type arcUniform;
centre (0.95 0 0.25);
normal (1 0 0);
radial (0 0 0.25);
startAngle -1.57079633;
endAngle 0.52359878;
nPoints 200;
axis x;
}
boundaryPoints: Specified point samples associated with a subset of
the boundary. Replaces "patchCloud". Example:
{
type boundaryPoints;
patches (inlet1 inlet2);
points ((0 -0.05 0.05) (0 -0.05 0.1) (0 -0.05 0.15));
maxDistance 0.01;
axis x;
}
boundaryRandom: Random samples within a subset of the boundary.
Replaces "patchSeed", but changes the behaviour to be entirely
random. It does not seed the boundary face centres first. Example:
{
type boundaryRandom;
patches (inlet1 inlet2);
nPoints 1000;
axis x;
}
boxUniform: Uniform grid of samples within a axis-aligned box.
Replaces "array". Example:
{
type boxUniform;
box (0.95 0 0.25) (1.2 0.25 0.5);
nPoints (2 4 6);
axis x;
}
circleRandom: Random samples within a circle. New. Example:
{
type circleRandom;
centre (0.95 0 0.25);
normal (1 0 0);
radius 0.25;
nPoints 200;
axis x;
}
lineFace: Face-intersections along a line. Replaces "face". Example:
{
type lineFace;
start (0.6 0.6 0.5);
end (0.6 -0.3 -0.1);
axis x;
}
lineCell: Cell-samples along a line at the mid-points in-between
face-intersections. Replaces "midPoint". Example:
{
type lineCell;
start (0.5 0.6 0.5);
end (0.5 -0.3 -0.1);
axis x;
}
lineCellFace: Combination of "lineFace" and "lineCell". Replaces
"midPointAndFace". Example:
{
type lineCellFace;
start (0.55 0.6 0.5);
end (0.55 -0.3 -0.1);
axis x;
}
lineUniform: Uniform samples along a line. Replaces "uniform".
Example:
{
type lineUniform;
start (0.65 0.3 0.3);
end (0.65 -0.3 -0.1);
nPoints 200;
axis x;
}
points: Specified points. Replaces "cloud" when the ordered flag is
false, and "polyLine" when the ordered flag is true. Example:
{
type points;
points ((0 -0.05 0.05) (0 -0.05 0.1) (0 -0.05 0.15));
ordered yes;
axis x;
}
sphereRandom: Random samples within a sphere. New. Example:
{
type sphereRandom;
centre (0.95 0 0.25);
radius 0.25;
nPoints 200;
axis x;
}
triSurfaceMesh: Samples from all the points of a triSurfaceMesh.
Replaces "triSurfaceMeshPointSet". Example:
{
type triSurfaceMesh;
surface "surface.stl";
axis x;
}
The headers have also had documentation added. Example usage and a
description of the control parameters now exists for all sets.
In addition, a number of the algorithms which generate the sets have
been refactored or rewritten. This was done either to take advantage of
the recent changes to random number generation, or to remove ad-hoc
fixes that were made unnecessary by the barycentric tracking algorithm.
A new constraint patch has been added which permits AMI coupling in
cyclic geometries. The coupling is repeated with different multiples of
the cyclic transformation in order to achieve a full correspondence.
This allows, for example, a cylindrical AMI interface to be used in a
sector of a rotational geometry.
The patch is used in a similar manner to cyclicAMI, except that it has
an additional entry, "transformPatch". This entry must name a coupled
patch. The transformation used to repeat the AMI coupling is taken from
this patch. For example, in system/blockMeshDict:
boundary
(
cyclic1
{
type cyclic;
neighbourPatch cyclic2;
faces ( ... );
}
cyclic2
{
type cyclic;
neighbourPatch cyclic1;
faces ( ... );
}
cyclicRepeatAMI1
{
type cyclicRepeatAMI;
neighbourPatch cyclicRepeatAM2;
transformPatch cyclic1;
faces ( ... );
}
cyclicRepeatAMI2
{
type cyclicRepeatAMI;
neighbourPatch cyclicRepeatAMI1;
transformPatch cyclic1;
faces ( ... );
}
// other patches ...
);
In this example, the transformation between cyclic1 and cyclic2 is used
to define the repetition used by the two cyclicRepeatAMI patches.
Whether cyclic1 or cyclic2 is listed as the transform patch is not
important.
A tutorial, incompressible/pimpleFoam/RAS/impeller, has been added to
demonstrate the functionality. This contains two repeating AMI pairs;
one cylindrical and one planar.
A significant amount of maintenance has been carried out on the AMI and
ACMI patches as part of this work. The AMI methods now return
dimensionless weights by default, which prevents ambiguity over the
units of the weight field during construction. Large amounts of
duplicate code have also been removed by deriving ACMI classes from
their AMI equivalents. The reporting and writing of AMI weights has also
been unified.
This work was supported by Dr Victoria Suponitsky, at General Fusion
Streamlines can now be tracked in both directions from the set of
initial locations. The keyword controlling this behaviour is
"direction", which can be set to "forward", "backward" or "both".
This new keyword superseeds the "trackForward" entry, which has been
retained for backwards compatibility.
Description
Evaluates and writes the turbulence intensity field 'I'.
The turbulence intensity field 'I' is the root-mean-square of the turbulent
velocity fluctuations normalised by the local velocity magnitude:
\f[
I \equiv \frac{\sqrt{\frac{2}{3}\, k}}{U}
\f]
To avoid spurious extrema and division by 0 I is limited to 1 where the
velocity magnitude is less than the turbulent velocity fluctuations.
Example of function object specification:
\verbatim
functions
{
.
.
.
turbulenceIntensity
{
type turbulenceIntensity;
libs ("libfieldFunctionObjects.so");
}
.
.
.
}
\endverbatim
or using the standard configuration file:
\verbatim
functions
{
.
.
.
#includeFunc turbulenceIntensity
.
.
.
}
\endverbatim
and optionally the CPU and clock times per time step.
Example of function object specification:
time
{
type time;
libs ("libutilityFunctionObjects.so");
writeControl timeStep;
writeInterval 1;
perTimeStep no;
}
Adding
#includeFunc time
to the functions list in the controlDict of the motorBike tutorial generates
0 1.190000e+00 1
1 1.640000e+00 1
2 1.940000e+00 2
Enabling the optional writing of the CPU and clock time per time step is
straight forward:
#includeFunc time(perTimeStep=yes)
terms of the local barycentric coordinates of the current tetrahedron,
rather than the global coordinate system.
Barycentric tracking works on any mesh, irrespective of mesh quality.
Particles do not get "lost", and tracking does not require ad-hoc
"corrections" or "rescues" to function robustly, because the calculation
of particle-face intersections is unambiguous and reproducible, even at
small angles of incidence.
Each particle position is defined by topology (i.e. the decomposed tet
cell it is in) and geometry (i.e. where it is in the cell). No search
operations are needed on restart or reconstruct, unlike when particle
positions are stored in the global coordinate system.
The particle positions file now contains particles' local coordinates
and topology, rather than the global coordinates and cell. This change
to the output format is not backwards compatible. Existing cases with
Lagrangian data will not restart, but they will still run from time
zero without any modification. This change was necessary in order to
guarantee that the loaded particle is valid, and therefore
fundamentally prevent "loss" and "search-failure" type bugs (e.g.,
2517, 2442, 2286, 1836, 1461, 1341, 1097).
The tracking functions have also been converted to function in terms
of displacement, rather than end position. This helps remove floating
point error issues, particularly towards the end of a tracking step.
Wall bounded streamlines have been removed. The implementation proved
incompatible with the new tracking algorithm. ParaView has a surface
LIC plugin which provides equivalent, or better, functionality.
Additionally, bug report <https://bugs.openfoam.org/view.php?id=2517>
is resolved by this change.
except turbulence and lagrangian which will also be updated shortly.
For example in the nonNewtonianIcoFoam offsetCylinder tutorial the viscosity
model coefficients may be specified in the corresponding "<type>Coeffs"
sub-dictionary:
transportModel CrossPowerLaw;
CrossPowerLawCoeffs
{
nu0 [0 2 -1 0 0 0 0] 0.01;
nuInf [0 2 -1 0 0 0 0] 10;
m [0 0 1 0 0 0 0] 0.4;
n [0 0 0 0 0 0 0] 3;
}
BirdCarreauCoeffs
{
nu0 [0 2 -1 0 0 0 0] 1e-06;
nuInf [0 2 -1 0 0 0 0] 1e-06;
k [0 0 1 0 0 0 0] 0;
n [0 0 0 0 0 0 0] 1;
}
which allows a quick change between models, or using the simpler
transportModel CrossPowerLaw;
nu0 [0 2 -1 0 0 0 0] 0.01;
nuInf [0 2 -1 0 0 0 0] 10;
m [0 0 1 0 0 0 0] 0.4;
n [0 0 0 0 0 0 0] 3;
if quick switching between models is not required.
To support this more convenient parameter specification the inconsistent
specification of seedSampleSet in the streamLine and wallBoundedStreamLine
functionObjects had to be corrected from
// Seeding method.
seedSampleSet uniform; //cloud; //triSurfaceMeshPointSet;
uniformCoeffs
{
type uniform;
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
to the simpler
// Seeding method.
seedSampleSet
{
type uniform;
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
which also support the "<type>Coeffs" form
// Seeding method.
seedSampleSet
{
type uniform;
uniformCoeffs
{
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
}
