Creates volume fields whose boundaries are used to store patch interaction
statistics.
Current field output per patch face:
- \<cloud\>\<model\>:count - cumulative particle hits
- \<cloud\>\<model\>:mass - cumuluative mass of hitting particles
Fields can be reset according to:
- none: fields are not reset
- timeStep: reset at each time step
- writeTime: reset at each write time
Usage
patchInteractionFields1
{
type patchInteractionFields;
resetMode writeTime;
}
Shows an example of the new recyclePatchInteraction model
- particles that escape from the outlet are recycled back into the
domain via the second inlet
Signed-off-by: Kutalmis Bercin <kutalmis.bercin@esi-group.com>
- additional "names" entry to specify a word/regex list of selections
For example,
{
type patch;
name inlets;
names ("inlet_[0-9].*" inlet);
}
- if "names" exists AND contains a literal (non-regex) that can be used
as a suitable value for "name", the "name" entry becomes optional.
For example,
{
type patch;
names ("inlet_[0-9].*" inlet);
// inferred name = inlet
}
- reduce some overhead in surfaceFieldValue
TUT: surfaceFieldValue on patches : reactingParcelFoam/verticalChannel
Computes a histogram for the distribution of particle diameters
and corresponding number of particles hitting on a given list of patches.
A minimal example by using `constant/reactingCloud1Properties.cloudFunctions`:
```
patchParticleHistogram1
{
// Mandatory entries (unmodifiable)
type patchParticleHistogram;
patches (<patch1> <patch2> ... <patchN>);
nBins 10;
min 0.1;
max 10.0;
maxStoredParcels 20;
}
```
- in most cases this eliminates manually calculation of circumferential
points.
TUT: improve parameterization of sphere blockMeshDict
- allow separate parameterization of radius, ratio of inner to outer,
and the number of divisions in x/y/z and radial directions
1) Adding LiquidEvapFuchsKnudsen model for lagrangian evaporation.
This models is based on a diffusion type of evaporation/
condensation on particles composed of solution (liquid + solid).
2) Adding modes of calculating the particle rho and volume change.
The new keyword in constantProperties is 'volumeUpdateMethod'
which three options:
a) constantRho
b) constantVolume
c) updateRhoAndVol
The old keyword 'constantVolume' true/face is still valid
3) The entry rho0 is now optional for multicomponent parcels.
If defined , it is used, but if it is not the actual mixture
provided is used to calculate rho0 of the particle.
T0 is still used as initial T and Cp0 is over-written in the
multicomponent cloud but still required.
4) Adding tutorial for evaporation/condensation model
Example usage:
cloudFunctions
{
WeberNumber1
{
type WeberNumber;
}
}
This will calculate and write the Weber number field as a 'standard'
cloud field, available for post-processing alongside other lagrangian
fields in the lagrangian/<cloudName> directory.
ENH: update libs of etc/caseDicts/postProcess items
ENH: ensure destructor=default
ENH: ensure constness
ENH: ensure no 'copy construct' and 'no copy assignment' exist
TUT: add examples of function objects with full set
of settings into a TUT if unavailable
TUT: update pisoFoam/RAS/cavity tutorial in terms of usage
The optional 'fields' entry can be used to limit which particle fields are
written to file. If empty/not specified, all properties are written to
maintain backwards compatibility.
patchPostProcessing1
{
type patchPostProcessing;
maxStoredParcels 20;
fields (position "U.*" d T nParticle);
patches
(
cycLeft_half0
cycLeft_half1
);
}
- number of particles per parcel info to kinematic cloud
- added turbulent dispersion to basicHeterogeneousReactingParcel
- corrected dhsTrans in MUCSheterogeneousRate::calculate
- added cloud macro system to reactingParcelFoam and fixed calculation
of average particles per parcel
- added progress variable dimension to reacting model (nF)
- added ReactingHeterogeneous tutorial
- Extended runTimePostProcessing to include access to "live"
simulation objects such a geometry patches and sampled surfaces
stored on the "functionObjectObjects" registry.
- Add 'live' runTimePostProcessing of cloud data.
Extracts position and fields from the cloud via its objectRegistry writer
- For the "live" simulation objects, there are two new volume filters
that work directly with the OpenFOAM volume fields:
* iso-surface
* cutting planes
Both use the VTK algorithms directly and support multiple values.
Eg, can make multiple iso-levels or multiple planes parallel to each
other.
- When VTK has been compiled with MPI-support, parallel rendering will
be used.
- Additional title text properties (shadow, italic etc)
- Simplified handling of scalar-bar and visibility switches
- Support multiple text positions. Eg, for adding watermark text.
- now supports a parcel selection mechanism like vtkCloud,
giving the ability to select a subset of parcels.
For example, a given stride, or removal of parcels with a small
diameter.
Eg,
dataCloud output Time: 3.2
Applying parcel filtering to 994 parcels
- add stride 4
- subtract field U : (less 0.2)
After filtering using 214/994 parcels
- add output precision control for dataCloud
- use parallel list writing, beginDataArray methods.
- use static_assert to restrict conversion of non-label integral types
- cache .vtp.series information by fileName instead of by cloud name.
This issues if the output directory changes, and simplifies code.
ENH: emit TimeValue in files generated by vtkCloud
- additional information for passing to ParaView
ENH: vtkCloud output to postProcessing/ (issue #866)
- better alignment with other function objects, no collision with
foamToVTK output.
- helps reduce clutter in the topoSetDict files.
Caveats when using this.
The older specification styles using "name" will conflict with the
set name. Eg,
{
name f0
type faceSet;
action add;
source patchToFace;
sourceInfo
{
name inlet;
}
}
would flattened to the following
{
name f0
type faceSet;
action add;
source patchToFace;
name inlet;
}
which overwrites the "name" used for the faceSet.
The solution is to use the updated syntax:
{
name f0
type faceSet;
action add;
source patchToFace;
patch inlet;
}
- old 'DELETE' enum was easily confused with 'REMOVE', which removes
the set, not the elements from the set.
- provide corresponding subtractSet() method
STYLE: HashSet set/unset instead of insert/erase methods in topoSetSource
- simplifies switching to/from bitSet storage
- writes positions and a single field (eg, diameter) in plain ASCII files,
suitable for importing in a spreadsheet or manipulation with
scripting tools.
- code integrated from
https://develop.openfoam.com/Community/OpenFOAM-addOns
Description
Calculates the spatial minimum and maximum extents of a field
The extents are derived from the bound box limits after identifying
the locations where field values exceed the user-supplied threshold
value.
Usage
Example of function object specification:
fieldExtents1
{
type fieldExtents;
libs ("libfieldFunctionObjects.so");
...
writeToFile yes;
log yes;
fields (alpha);
threshold 0.5;
patches ();
}
Where the entries comprise:
Property | Description | Required | Default
type | type name: fieldExtents | yes |
writeToFile | write extents data to file | no | yes
log | write extents data to standard output | no | yes
internalField | Process the internal field | no | yes
threshold | Field value to identify extents boundary | yes |
referencePosition | Reference position | no | (0 0 0)
fields | list of fields to process | yes |
patches | list of patches to process | no | <all>
Output data is written to the file \<timeDir\>/fieldExtents.dat
Note
For non-scalar fields, the magnitude of the field is employed and
compared to the threshold value.
Previously the coordinate system functionality was split between
coordinateSystem and coordinateRotation. The coordinateRotation stored
the rotation tensor and handled all tensor transformations.
The functionality has now been revised and consolidated into the
coordinateSystem classes. The sole purpose of coordinateRotation
is now just to provide a selectable mechanism of how to define the
rotation tensor (eg, axis-angle, euler angles, local axes) for user
input, but after providing the appropriate rotation tensor it has
no further influence on the transformations.
--
The coordinateSystem class now contains an origin and a base rotation
tensor directly and various transformation methods.
- The origin represents the "shift" for a local coordinate system.
- The base rotation tensor represents the "tilt" or orientation
of the local coordinate system in general (eg, for mapping
positions), but may require position-dependent tensors when
transforming vectors and tensors.
For some coordinate systems (currently the cylindrical coordinate system),
the rotation tensor required for rotating a vector or tensor is
position-dependent.
The new coordinateSystem and its derivates (cartesian, cylindrical,
indirect) now provide a uniform() method to define if the rotation
tensor is position dependent/independent.
The coordinateSystem transform and invTransform methods are now
available in two-parameter forms for obtaining position-dependent
rotation tensors. Eg,
... = cs.transform(globalPt, someVector);
In some cases it can be useful to use query uniform() to avoid
storage of redundant values.
if (cs.uniform())
{
vector xx = cs.transform(someVector);
}
else
{
List<vector> xx = cs.transform(manyPoints, someVector);
}
Support transform/invTransform for common data types:
(scalar, vector, sphericalTensor, symmTensor, tensor).
====================
Breaking Changes
====================
- These changes to coordinate systems and rotations may represent
a breaking change for existing user coding.
- Relocating the rotation tensor into coordinateSystem itself means
that the coordinate system 'R()' method now returns the rotation
directly instead of the coordinateRotation. The method name 'R()'
was chosen for consistency with other low-level entities (eg,
quaternion).
The following changes will be needed in coding:
Old: tensor rot = cs.R().R();
New: tensor rot = cs.R();
Old: cs.R().transform(...);
New: cs.transform(...);
Accessing the runTime selectable coordinateRotation
has moved to the rotation() method:
Old: Info<< "Rotation input: " << cs.R() << nl;
New: Info<< "Rotation input: " << cs.rotation() << nl;
- Naming consistency changes may also cause code to break.
Old: transformVector()
New: transformPrincipal()
The old method name transformTensor() now simply becomes transform().
====================
New methods
====================
For operations requiring caching of the coordinate rotations, the
'R()' method can be used with multiple input points:
tensorField rots(cs.R(somePoints));
and later
Foam::transformList(rots, someVectors);
The rotation() method can also be used to change the rotation tensor
via a new coordinateRotation definition (issue #879).
The new methods transformPoint/invTransformPoint provide
transformations with an origin offset using Cartesian for both local
and global points. These can be used to determine the local position
based on the origin/rotation without interpreting it as a r-theta-z
value, for example.
================
Input format
================
- Streamline dictionary input requirements
* The default type is cartesian.
* The default rotation type is the commonly used axes rotation
specification (with e1/e2/3), which is assumed if the 'rotation'
sub-dictionary does not exist.
Example,
Compact specification:
coordinateSystem
{
origin (0 0 0);
e2 (0 1 0);
e3 (0.5 0 0.866025);
}
Full specification (also accepts the longer 'coordinateRotation'
sub-dictionary name):
coordinateSystem
{
type cartesian;
origin (0 0 0);
rotation
{
type axes;
e2 (0 1 0);
e3 (0.5 0 0.866025);
}
}
This simplifies the input for many cases.
- Additional rotation specification 'none' (an identity rotation):
coordinateSystem
{
origin (0 0 0);
rotation { type none; }
}
- Additional rotation specification 'axisAngle', which is similar
to the -rotate-angle option for transforming points (issue #660).
For some cases this can be more intuitive.
For example,
rotation
{
type axisAngle;
axis (0 1 0);
angle 30;
}
vs.
rotation
{
type axes;
e2 (0 1 0);
e3 (0.5 0 0.866025);
}
- shorter names (or older longer names) for the coordinate rotation
specification.
euler EulerRotation
starcd STARCDRotation
axes axesRotation
================
Coding Style
================
- use Foam::coordSystem namespace for categories of coordinate systems
(cartesian, cylindrical, indirect). This reduces potential name
clashes and makes a clearer declaration. Eg,
coordSystem::cartesian csys_;
The older names (eg, cartesianCS, etc) remain available via typedefs.
- added coordinateRotations namespace for better organization and
reduce potential name clashes.
- the original intention was to avoid vtp output when the clouds are
empty anyhow. However, it is useful for post-processing to have
clouds with zero parcels (eg, before the start of injection).
Pruning of empty clouds is now an option in the vtkCloud dictionary
controls, with the default being false (no pruning). This represents
a non-breaking change in behaviour since it generates more output
than previously.
Example,
{
type vtkCloud;
//- Suppress writing of empty clouds (default: false)
prune true;
}
- improve doxygen entries for searchable surfaces.
- support selection of searchable surfaces with shorter names.
Eg,
type box | cylinder | ...;
vs type searchableBox | searchableCylinder | ...;
- functionObjectLibs -> libs
- redirectType -> name
- change deprecated writeCompression flags types to Switch.
- cleanup some trailing ';;' from some dictionaries
Support the following expansions when they occur at the start of a
string:
Short-form Equivalent
========= ===========
<etc>/ ~OpenFOAM/ (as per foamEtcFile)
<case>/ $FOAM_CASE/
<constant>/ $FOAM_CASE/constant/
<system>/ $FOAM_CASE/system/
These can be used in fileName expansions to improve clarity and reduce
some typing
"<constant>/reactions" vs "$FOAM_CASE/constant/reactions"
The combustion and chemistry models no longer select and own the
thermodynamic model; they hold a reference instead. The construction of
the combustion and chemistry models has been changed to require a
reference to the thermodyanmics, rather than the mesh and a phase name.
At the solver-level the thermo, turbulence and combustion models are now
selected in sequence. The cyclic dependency between the three models has
been resolved, and the raw-pointer based post-construction step for the
combustion model has been removed.
The old solver-level construction sequence (typically in createFields.H)
was as follows:
autoPtr<combustionModels::psiCombustionModel> combustion
(
combustionModels::psiCombustionModel::New(mesh)
);
psiReactionThermo& thermo = combustion->thermo();
// Create rho, U, phi, etc...
autoPtr<compressible::turbulenceModel> turbulence
(
compressible::turbulenceModel::New(rho, U, phi, thermo)
);
combustion->setTurbulence(*turbulence);
The new sequence is:
autoPtr<psiReactionThermo> thermo(psiReactionThermo::New(mesh));
// Create rho, U, phi, etc...
autoPtr<compressible::turbulenceModel> turbulence
(
compressible::turbulenceModel::New(rho, U, phi, *thermo)
);
autoPtr<combustionModels::psiCombustionModel> combustion
(
combustionModels::psiCombustionModel::New(*thermo, *turbulence)
);
ENH: combustionModel, chemistryModel: Simplified model selection
The combustion and chemistry model selection has been simplified so
that the user does not have to specify the form of the thermodynamics.
Examples of new combustion and chemistry entries are as follows:
In constant/combustionProperties:
combustionModel PaSR;
combustionModel FSD;
In constant/chemistryProperties:
chemistryType
{
solver ode;
method TDAC;
}
All the angle bracket parts of the model names (e.g.,
<psiThermoCombustion,gasHThermoPhysics>) have been removed as well as
the chemistryThermo entry.
The changes are mostly backward compatible. Only support for the
angle bracket form of chemistry solver names has been removed. Warnings
will print if some of the old entries are used, as the parts relating to
thermodynamics are now ignored.
ENH: combustionModel, chemistryModel: Simplified model selection
Updated all tutorials to the new format
STYLE: combustionModel: Namespace changes
Wrapped combustion model make macros in the Foam namespace and removed
combustion model namespace from the base classes. This fixes a namespace
specialisation bug in gcc 4.8. It is also somewhat less verbose in the
solvers.
This resolves bug report https://bugs.openfoam.org/view.php?id=2787
ENH: combustionModels: Default to the "none" model
When the constant/combustionProperties dictionary is missing, the solver
will now default to the "none" model. This is consistent with how
radiation models are selected.
Within decomposeParDict, it is now possible to specify a different
decomposition method, methods coefficients or number of subdomains
for each region individually.
The top-level numberOfSubdomains remains mandatory, since this
specifies the number of domains for the entire simulation.
The individual regions may use the same number or fewer domains.
Any optional method coefficients can be specified in a general
"coeffs" entry or a method-specific one, eg "metisCoeffs".
For multiLevel, only the method-specific "multiLevelCoeffs" dictionary
is used, and is also mandatory.
----
ENH: shortcut specification for multiLevel.
In addition to the longer dictionary form, it is also possible to
use a shorter notation for multiLevel decomposition when the same
decomposition method applies to each level.
Correcting thermoSingleLayer.C mask field alpha to avoid heat sources where there is no film.
Tunning fvSolution for alpha for twoPhasePachuka tutorial
The combined solver includes the most advanced and general functionality from
each solver including:
Continuous phase
Lagrangian multiphase parcels
Optional film
Continuous and Lagrangian phase reactions
Radiation
Strong buoyancy force support by solving for p_rgh
The reactingParcelFoam and reactingParcelFilmFoam tutorials have been combined
and updated.
This tutorial demonstrates moving mesh and AMI with a Lagrangian cloud.
It is very slow, as interaction lists (required to compute collisions)
are not optimised for moving meshes. The simulation time has therefore
been made very short, so that it finishes in a reasonable time. The
mixer only completes a small fraction of a rotation in this time. This
is still sufficient to test tracking and collisions in the presence of
AMI and mesh motion.
In order to generate a convincing animation, however, the end time must
be increased and the simulation run for a number of days.
and the continuous-phase simulation type
For LTS and steady-state simulations the transient option does not need to be
provided as only steady-state tracking is appropriate. For transient running
the Lagrangian tracking may be steady or transient.
- although this has been supported for many years, the tutorials
continued to use "convertToMeters" entry, which is specific to blockMesh.
The "scale" is more consistent with other dictionaries.
ENH:
- ignore "scale 0;" (treat as no scaling) for blockMeshDict,
consistent with use elsewhere.
- Use on/off vs longer compressed/uncompressed.
For consistency, replaced yes/no with on/off.
- Avoid the combination of binary/compressed,
which is disallowed and provokes a warning anyhow
For example the actuationDiskSource fvOption may now be specified
disk1
{
type actuationDiskSource;
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
rather than
disk1
{
type actuationDiskSource;
active on;
actuationDiskSourceCoeffs
{
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
}
but this form is supported for backward compatibility.
The entries for liquid and solid species can now be simply be the name unless
property coefficients are overridden in which are specified in a dictionary as
before e.g. in the tutorials/lagrangian/coalChemistryFoam/simplifiedSiwek case
the water is simply specified
liquids
{
H2O;
}
and solid ash uses standard coefficients but the coefficients for carbon are
overridden thus
solids
{
C
{
rho 2010;
Cp 710;
kappa 0.04;
Hf 0;
emissivity 1.0;
}
ash;
}
The defaultCoeffs entry is now redundant and supported only for backward
compatibility. To specify a liquid with default coefficients simply leave the
coefficients dictionary empty:
liquids
{
H2O {}
}
Any or all of the coefficients may be overridden by specifying the properties in
the coefficients dictionary, e.g.
liquids
{
H2O
{
rho
{
a 1000;
b 0;
c 0;
d 0;
}
}
}
