Reports cloud information for particles passing through a specified cell
zone.
Example usage:
cloudFunctions
{
particleZoneInfo1
{
type particleZoneInfo;
cellZone leftFluid;
// Optional entries
//writer vtk;
}
}
Results are written to file:
- \<case\>/postProcessing/lagrangian/\<cloudName\>/\<functionName\>/\<time\>
\# cellZone : leftFluid
\# time : 1.0000000000e+00
\#
\# origID origProc (x y z) time0 age d0 d mass0 mass
Where
- origID : particle ID
- origProc : processor ID
- (x y z) : Cartesian co-ordinates
- time0 : time particle enters the cellZone
- age : time spent in the cellZone
- d0 : diameter on entry to the cellZone
- d : current diameter
- mass0 : mass on entry to the cellZone
- mass : current mass
If the optional \c writer entry is supplied, cloud data is written in the
specified format.
During the run, output statistics are reported after the cloud solution,
e.g.:
particleZoneInfo:
Cell zone = leftFluid
Contributions = 257
Here, 'Contributions' refers to the number of incremental particle-move
contributions recorded during this time step. At write times, the output
is extended, e.g.:
particleZoneInfo:
Cell zone = leftFluid
Contributions = 822
Number of particles = 199
Written data to "postProcessing/lagrangian/reactingCloud1/
TUT: filter: add an example for the particleZoneInfo function object
- can now specify sampled sets as dictionary entries instead of a list
entry.
can now use: sets { ... }
instead of: sets ( ... );
This is similar to sampled surfaces and makes it easier to
manage with dictionary manipulation tools.
TUT: update to use writeTime instead of outputTime
- when used with *any* alphaField and normalised (the usual case)
would largely give a 0-1 corresponding to the min/max of the first
component, but could also yield negative values.
- if the alpha field corresponds identically to colour field, it is
readily possible to combine as into RGBA sequences. However, if the
fields are different it potentially means referencing an opacity
field that has not yet been sampled. This impedes using the format
for a streaming sampler without additional overhead and/or rewriting
the alpha channel later.
Computes a selected operation between multiple \c fieldValue function
objects.
The operation is applied to all results of each \c fieldValue object.
Note
Each object must generate the same number and type of results.
Usage
Minimal example by using \c system/controlDict.functions:
multiFieldValue1
{
// Mandatory entries (unmodifiable)
type multiFieldValue;
libs (fieldFunctionObjects);
// Mandatory entries (runtime modifiable)
operation subtract;
// List of fieldValue function objects as dictionaries
functions
{
region1
{
...
}
region2
{
...
}
...
regionN
{
...
}
}
// Optional (inherited) entries
...
}
where the entries mean:
Property | Description | Type | Req'd | Dflt
type | Type name: multiFieldValue | word | yes | -
libs | Library name: fieldFunctionObjects | word | yes | -
operation | Operation type to apply to values | word | yes | -
functions | List of fieldValue function objects | dict | yes | -
\endtable
Options for the \c operation entry:
add | add
subtract | subtract
min | minimum
max | maximum
average | average
Deprecated fieldValueDelta
- The fieldValueDelta function object was originally written to compute the
difference between two fieldValue-type function objects. The multiFieldValue
object name better describes its purpose whilst being able to operate on an
arbitrary number of fieldValue-type objects.
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
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
);
}
- 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
- 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;
}
