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)
With the writeJobInfo option in OpenFOAM-dev/etc/controlDict::InfoSwitches set
to 1 each OpenFOAM executable writes a <executable>.<pid> file containing the
job summary into the <case>/jobInfo directory, e.g. after running the
tutorials/incompressible/pisoFoam/RAS/cavity tutorials
tutorials/incompressible/pisoFoam/RAS/cavity/jobInfo contains
blockMesh.20169 pisoFoam.20170
When etc/controlDict::writeJobInfo is set to 1 jobInfo.<pid> files are written
to the case directory containing a summary of the execution of the job containing
startDate
startTime
userName
foamVersion
code
argList
currentDir
PPID
PGID
foamBuild
root
case
nProcs
When the job completes the following additional entries are written:
cpuTime
endDate
endTime
termination
The original etc/controlDict::writeJobInfo control has been renamed writeJobControl and when set
to 1 writes the ~/OpenFOAM/jobControl/runningJobs and finishedJobs files for job control.
This removes a class of flux-velocity decoupling ("staggering") relating to the
interaction between the virtual mass, lift and turbulent dispersion forces.
The ramp function used to graduate the vertical damping force can now be
applied along a number of paths, rather than just one. The keywords
"origins" and "directions" can be used to define a list of paths.
verticalDamping1
{
type verticalDamping;
origins ((1200 0 0) (1200 100 0) (1200 -100 0));
directions ((1 0 0) (0 1 0) (0 -1 0));
// ...
}
The ramping function will be calculated along each of the paths defined
by the origin-direction pair, and the maximum of the calculated values
will be used.
The "origin" and "direction" keywords can still be used with non-list
values.
This work was supported by Jan Kaufmann and Jan Oberhagemann at DNV GL.
First run the surfaceFeatureExtract with the "closeness" option enabled in the
surfaceFeatureExtractDict to extract the surface closeness point field
// Out put the closeness of surface elements to other surface elements.
closeness yes;
Then enable cell sizing based on local surface closeness by specifying the
"internalCloseness" options in the foamyHexMeshDict e.g.
motionControl
{
defaultCellSize 4;
minimumCellSizeCoeff 0.1;
maxSmoothingIterations 100;
maxRefinementIterations 2;
shapeControlFunctions
{
geometry
{
type searchableSurfaceControl;
priority 1;
mode inside;
surfaceCellSizeFunction nonUniformField;
cellSizeCalculationType automatic;
curvature false;
curvatureFile dummy;
featureProximity false;
featureProximityFile dummy;
internalCloseness true;
internalClosenessFile geometry.internalPointCloseness;
internalClosenessCellSizeCoeff 25;
curvatureCellSizeCoeff 0;
maximumCellSizeCoeff 1;
cellSizeFunction uniform;
}
}
}
e.g.
postProcess -func sample -region bottomWater
will now search for the system/bottomWater/sample dictionary before searching
for system/sample so that the fields and type of sampling can optionally be
specified differently for the particular region.
Resolves feature request https://bugs.openfoam.org/view.php?id=2807
This function object will write a paraview-viewable field showing the
area-density of parcel collisions on every patch face. It also outputs
the rate of collisions hitting each patch face, calculated over an
interval equal to the time elapsed since the last output. It has an
optional entry to specify a minimum incident speed below which a
collision is not counted.
It can be enabled in the cloud properties file as follows:
cloudFunctions
{
patchCollisionDensity1
{
type patchCollisionDensity;
minSpeed 1e-3; // (optional)
}
}
This work was supported by Anton Kidess, at Hilti
The onset of vertical damping can now be graduated over a distance. The
user specifies an origin and a direction along which the graduation
occurs, and a ramping function to specify the form of the graduation. An
example specification for the fvOption is:
verticalDamping1
{
type verticalDamping;
selectionMode all;
origin (1200 0 0);
direction (1 0 0);
ramp
{
type halfCosineRamp;
start 0;
duration 600;
}
lambda [0 0 -1 0 0 0 0] 1; // Damping coefficient
timeStart 0;
duration 1e6;
}
If the origin, direction or ramp entries are omitted then the fvOption
functions as before; applying the damping to the entire volume or the
specified cell set.
This work was supported by Jan Kaufmann and Jan Oberhagemann at DNV GL.
The outletPhaseMeanVelocity and waveVelocity boundary conditions now
support a "ramp" keyword, for which a function can be supplied to
gradually increase the input velocity. The following is an example
specification for an outlet patch:
outlet
{
type outletPhaseMeanVelocity;
Umean 2;
ramp
{
type quarterSineRamp;
start 0;
duration 5;
}
alpha alpha.water;
}
There is also a new velocityRamping function object, which provides a
matching force within the volume of the domain, so that the entire flow
is smoothly accelerated up to the operating condition. An example
specification is as follows:
velocityRamping
{
type velocityRamping;
active on;
selectionMode all;
U U;
velocity (-2 0 0);
ramp
{
type quarterSineRamp;
start 0;
duration 5;
}
}
These additions have been designed to facilitate a smoother startup of
ship simulations by avoiding the slamming transients associated with
initialising a uniform velocity field.
This work was supported by Jan Kaufmann and Jan Oberhagemann at DNV GL.
chtMultiRegionSimpleFoam needs to check whether or not the simulation is
at the end. To facilitate this, a Time::running method has been added.
The Time::run method was being used for this purpose, but this lead to
function objects being executed multiple times.
This resolves bug report https://bugs.openfoam.org/view.php?id=2804
Using the noSlip boundary condition for rotating wall in an MRF region
interferes with post-processing by resetting the wall velocity to 0 rather than
preserving the value set by the MRF zone.
Removed possibility for the user to specify a driftRate in the constantDrift
model which is independent of a fvOptions mass source. The driftRate must be
calculated from/be consistent with the mass source in order to yield a particle
number conserving result.
Made calculation of the over-all Sauter mean diameter of an entire population
balance conditional on more than one velocityGroup being present. This diameter
field is for post-processing purposes only and would be redundant in case of one
velocityGroup being used.
Solution control is extended to allow for solution of the population balance
equation at the last PIMPLE loop only, using an optional switch. This can be
beneficial in terms of simulation time as well as coupling between the
population balance based diameter calculation and the rest of the equation
system.
Patch contributed by Institute of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf
(HZDR) and VTT Technical Research Centre of Finland Ltd.
allow renormalization of sizeGroup volume fractions for restarts involving
initial conditions with a slight degree of unboundedness
Patch contributed by Institute of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf
(HZDR) and VTT Technical Research Centre of Finland Ltd.
which provides access to the current phase and the corresponding other phase for
each of the phases in the pair. This allows some simplification of the phase
pair loops in several sub-models and avoids the need for pointer swaps.
The number of characters needed to print a double in scientific format
is 8 plus the number of decimal places; e.g., -6.453452e-231 (6 decimal
places, 14 characters). This has been set in writeFile.C, replacing a
value of 7. Presumably, the case of three digits in the exponent was not
considered when this was first implemented. This change ensures at least
one character of whitespace between tabulated numbers.
This resolves bug report https://bugs.openfoam.org/view.php?id=2801
Checking a pair contains a particular phase and adding a contribution from the
"other" phase can now be written:
if (pair.contains(phase))
{
const phaseModel& otherPhase = pair.other(phase);
phiHbyAs[phasei] +=
fvc::interpolate(rAUs[phasei]*K)
*MRF.absolute(otherPhase.phi());
HbyAs[phasei] += rAUs[phasei]*K*otherPhase.U();
}
which previously would have been written as a loop over the pair and excluding
self reference:
const phaseModel* phase1 = &pair.phase1();
const phaseModel* phase2 = &pair.phase2();
forAllConstIter(phasePair, pair, iter)
{
if (phase1 == &phase)
{
phiHbyAs[phasei] +=
fvc::interpolate(rAUs[phasei]*K)
*MRF.absolute(phase2->phi());
HbyAs[phasei] += rAUs[phasei]*K*phase2->U();
}
Swap(phase1, phase2);
}
This patch enables the reactingEulerFoam solvers to simulate polydisperse flow
situations, i.e. flows where the disperse phase is subject to a size
distribution.
The newly added populationBalanceModel class solves the integro-partial
differential population balance equation (PBE) by means of a class method, also
called discrete or sectional method. This approach is based on discretizing the
PBE over its internal coordinate, the particle volume. This yields a set of
transport equations for the number concentration of particles in classes with a
different representative size. These are coupled through their source-terms and
solved in a segregated manner. The implementation is done in a way, that the
total particle number and mass is preserved for coalescence, breakup and drift
(i.e. isothermal growth or phase change) processes, irrespective of the chosen
discretization over the internal coordinate.
A population balance can be split over multiple velocity (temperature) fields,
using the capability of reactingMultiphaseEulerFoam to solve for n momentum
(energy) equations. To a certain degree, this takes into account the dependency
of heat- and momentum transfer on the disperse phase diameter. It is also possible
to define multiple population balances, e.g. bubbles and droplets simultaneously.
The functionality can be switched on by choosing the appropriate phaseSystem
type, e.g. populationBalanceMultiphaseSystem and the newly added diameterModel
class called velocityGroup. To illustrate the use of the functionality, a
bubbleColumnPolydisperse tutorial was added for reactingTwoPhaseEulerFoam and
reactingMultiphaseEulerFoam.
Furthermore, a reactingEulerFoam-specific functionObject called sizeDistribution
was added to allow post-Processing of the size distribution, e.g. to obtain the
number density function in a specific region.
Patch contributed by Institute of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf
(HZDR) and VTT Technical Research Centre of Finland Ltd.
- Thermal phase change and wall boiling functionality has been generalized to
support two- and multi- phase simulations.
- Thermal phase change now also allows purePhaseModel, which simplifies case setup.
- The phaseSystem templates have been restructured in preparation of multiple
simultaneous mass transfer mechanisms. For example, combination of thermal phase
and inhomogeneous population balance models.
Patch contributed by VTT Technical Research Centre of Finland Ltd and Institute
of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf (HZDR).
