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.
This is faster than the library functionality that it replaces, as it
allows the compiler to do inlining. It also does not utilise any static
state so generators do not interfere with each other. It is also faster
than the the array lookup in cachedRandom. The cachedRandom class
therefore offers no advantage over Random and has been removed.
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.
It may be convenient to specify these directions un-normalized so it is
necessary to normalize them before they are used to calculate the force
coefficients.
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
The logic governing function objects' ability to change the time-step
has been modified so that it is compatible with the time-step adjustment
done in the Time class. The behaviour has been split into a method which
sets the step directly, and another which moidifies the time until the
next write operation (i.e., the time that the solver "aims" for).
This fixes an issue where the adjustments in Time and the function
objects interfere and cause the time step to decrease exponentially down
to machine precision. It also means that the set-time-step function
object now does not break the adjustable run-time setting.
This resolves bug report https://bugs.openfoam.org/view.php?id=2820
In early versions of OpenFOAM the scalar limits were simple macro replacements and the
names were capitalized to indicate this. The scalar limits are now static
constants which is a huge improvement on the use of macros and for consistency
the names have been changed to camel-case to indicate this and improve
readability of the code:
GREAT -> great
ROOTGREAT -> rootGreat
VGREAT -> vGreat
ROOTVGREAT -> rootVGreat
SMALL -> small
ROOTSMALL -> rootSmall
VSMALL -> vSmall
ROOTVSMALL -> rootVSmall
The original capitalized are still currently supported but their use is
deprecated.
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)
for incompressible flow simulated using simpleFoam, pimpleFoam or pisoFoam.
Description
Calculates and write the estimated incompressible flow heat transfer
coefficient at wall patches as the volScalarField field
'wallHeatTransferCoeff'.
All wall patches are included by default; to restrict the calculation to
certain patches, use the optional 'patches' entry.
Example of function object specification:
wallHeatTransferCoeff1
{
type wallHeatTransferCoeff;
libs ("libfieldFunctionObjects.so");
...
region fluid;
patches (".*Wall");
rho 1.225;
Cp 1005;
Prl 0.707;
Prt 0.9;
}
Usage
Property | Description | Required | Default value
type | Type name: wallHeatTransferCoeff | yes |
patches | List of patches to process | no | all wall patches
region | Region to be evaluated | no | default region
rho | Fluid density | yes |
Cp | Fluid heat capacity | yes |
Prl | Fluid laminar Prandtl number | yes |
Prt | Fluid turbulent Prandtl number| yes |
Note
Writing field 'wallHeatTransferCoeff' is done by default, but it can be
overridden by defining an empty \c objects list. For details see
writeLocalObjects.
Corrected a few issues with the utilisation of the tracking within the
nearWallFields function object. The tracking is now done over a
displacement from the initial location, which prevents trying to track
to a location outside the mesh when the patch face is warped and the
centre lies outside the tracking decomposition. Also fixed the end
criteria so that it does not suffer from round off error in the step
fraction.
The upshot of these changes is that the faces on which the near wall
cells were not being set are now being set properly, and uninitialised
data is no longer being written out.
Removed all the special handling for awkward particles from the
nearWallFields function object. The version 5+ tracking already handles
this more robustly.
Resolves bug-report https://bugs.openfoam.org/view.php?id=2728
The forces function object, when specified with a full coordinate
system, previously wrote forces and moments out in the following format:
time-0 forces-0 moments-0
time-0 localForces-0 localMoments-0
time-1 forces-1 moments-1
time-1 localForces-1 localMoments-1
# etc ...
There are two rows of values per time. This complicates the definition
of the table and means that filtering has to be done before the data
series can be visualised. The format has now been changed to the
following form:
time-0 forces-0 moments-0 localForces-0 localMoments-0
time-1 forces-1 moments-1 localForces-1 localMoments-1
# etc ...
There is one row per time, and each column is therefore a continuous
series of one variable that can be plotted.
A lot of methods were taking argument data which could be referenced or
generated from the parcel class at little or no additional cost. This
was confusing and generated the possibility of inconsistent data states.
Tracking data classes are no longer templated on the derived cloud type.
The advantage of this is that they can now be passed to sub models. This
should allow continuous phase data to be removed from the parcel
classes. The disadvantage is that every function which once took a
templated TrackData argument now needs an additional TrackCloudType
argument in order to perform the necessary down-casting.
Particle collisions with ACMI patches are now handled. The hit detects
whether the location is within the overlap or the coupled region and
recurses, calling the hit routine appropriate for the region.
The low level tracking methods are now more consistently named. There is
now a distinction between tracking to a face and hitting it. Function
object side effects have been moved out of the base layer and into the
parcels on which they are meaningful.
When an OpenFOAM simulation runs in parallel, the data for decomposed fields and
mesh(es) has historically been stored in multiple files within separate
directories for each processor. Processor directories are named 'processorN',
where N is the processor number.
This commit introduces an alternative "collated" file format where the data for
each decomposed field (and mesh) is collated into a single file, which is
written and read on the master processor. The files are stored in a single
directory named 'processors'.
The new format produces significantly fewer files - one per field, instead of N
per field. For large parallel cases, this avoids the restriction on the number
of open files imposed by the operating system limits.
The file writing can be threaded allowing the simulation to continue running
while the data is being written to file. NFS (Network File System) is not
needed when using the the collated format and additionally, there is an option
to run without NFS with the original uncollated approach, known as
"masterUncollated".
The controls for the file handling are in the OptimisationSwitches of
etc/controlDict:
OptimisationSwitches
{
...
//- Parallel IO file handler
// uncollated (default), collated or masterUncollated
fileHandler uncollated;
//- collated: thread buffer size for queued file writes.
// If set to 0 or not sufficient for the file size threading is not used.
// Default: 2e9
maxThreadFileBufferSize 2e9;
//- masterUncollated: non-blocking buffer size.
// If the file exceeds this buffer size scheduled transfer is used.
// Default: 2e9
maxMasterFileBufferSize 2e9;
}
When using the collated file handling, memory is allocated for the data in the
thread. maxThreadFileBufferSize sets the maximum size of memory in bytes that
is allocated. If the data exceeds this size, the write does not use threading.
When using the masterUncollated file handling, non-blocking MPI communication
requires a sufficiently large memory buffer on the master node.
maxMasterFileBufferSize sets the maximum size in bytes of the buffer. If the
data exceeds this size, the system uses scheduled communication.
The installation defaults for the fileHandler choice, maxThreadFileBufferSize
and maxMasterFileBufferSize (set in etc/controlDict) can be over-ridden within
the case controlDict file, like other parameters. Additionally the fileHandler
can be set by:
- the "-fileHandler" command line argument;
- a FOAM_FILEHANDLER environment variable.
A foamFormatConvert utility allows users to convert files between the collated
and uncollated formats, e.g.
mpirun -np 2 foamFormatConvert -parallel -fileHandler uncollated
An example case demonstrating the file handling methods is provided in:
$FOAM_TUTORIALS/IO/fileHandling
The work was undertaken by Mattijs Janssens, in collaboration with Henry Weller.
