Feature particle patch postpro filtering
### Summary
Adds options to write particle-patch interactions to file, and to select particle fields to post-process for the `patchPostProcessing` cloud function object
### Resolved bugs (If applicable)
none
### Details of new models (If applicable)
Cloud patch interaction models:
Optionally write patch interaction statistics, e.g. number and mass of particles that stick, escape etc. to file using the optional `writeToFile` entry, e.g.
```
localInteractionCoeffs
{
patches
(
"(walls|cyc.*)"
{
type rebound;
}
"inlet|outlet"
{
type escape;
}
);
// New optional entry
writeToFile yes;
}
```
Cloud function objects:
New `fields` optional entry can be used to select which particle fields to post-process; if empty or the entry is not given all fields are written (to provide backwards compatibility)
```
patchPostProcessing1
{
type patchPostProcessing;
// Optional new entry
fields (position "U.*" d T nParticle);
maxStoredParcels 20;
patches
(
cycLeft_half0
cycLeft_half1
);
}
```
See the `$FOAM_TUTORIALS/lagrangian/reactingParcelFilm/filter` tutorial for an example
### Risks
Low risk
See merge request Development/openfoam!301
Feature expressions
### Summary
This branch represents an implementation of what is considered to be the most useful aspects of swak4Foam ([Swiss-Army-Knife for FOAM](https://openfoamwiki.net/index.php/Contrib/swak4Foam)) from Bernhard Gschaider, namely the ability to use text-based expressions instead of coding in C++ for the following cases:
- expression-based boundary conditions (also known as _groovy_ boundary conditions)
- expression-based setFields (also known as _funky_ set fields)
The idea of what we currently term *expressions* was pioneered by
(Bernhard Gschaider) and is now firmly established in `swak4Foam`.
Among other things, expressions attempt to bridge the gap between
using standard, predefined boundary conditions and writing dedicated,
special-purpose ones. Although part of this gap is now covered within
OpenFOAM by using dynamically compiled user coding (eg, coded boundary
conditions), there remains substantial areas where it can be
significantly more convenient to have a series of predefined functions
and expression sytax with some access to base OpenFOAM field
functionality that enables rapid deployment of boundary conditions, or
custom-defined `setFields` without writing code.
A significant portion of `swak4Foam` expressions has been adapted for
direct integration into OpenFOAM. During the integration and rewrite,
we have tried to pare things down to a smaller subset with the aim of
covering 90% or more of the common cases. The remaining cases are left
to be reassessed for extending the *expressions* functionality in the
future, but they also may be better served with other approaches (eg,
with coded conditions) that were not available when `swak4Foam` was
originally conceived.
To the greatest extent possible, the integrated *expressions* have
been designed to avoid name clashes with `swak` so it should remain
possible to use the most recent versions of `swak` without problem.
### Risks
- New functionality, so low chance of regression.
- The scope of the functionality will be revised in the future
### Naming (for `swak4Foam` users)
The following are the *expressions* correspondences to `swak`:
- The `exprFixedValue` and `exprGradient` boundary conditions are
roughly equivalent to the _groovy_ boundary conditions.
- The utilities `setExprFields` and `setExprBoundaryFields` are
roughly equivalent to the _funky_ utilities of similar name.
The naming of the boundary conditions and utilities not only reflects
the slightly different input requirements, but simultaneously seeks to
avoid any potential name-clash with `swak4Foam` in a mixed
environment.
The names for the boundary condition dictionary entries tend be
shorter and slightly different (eg, `valueExpr` vs `valueExpression`)
to serve as a small reminder that the *expressions* syntax is slightly
different than the *groovy* equivalents. It also allows the user to
fashion dictionary entries that are sufficient for **both** boundary
condition variants and quickly toggle between them simply by changing
the boundary condition `type`.
See merge request Development/openfoam!300
Limits fields to user-specified min and max bounds
Usage
Example of function object specification:
limitFields1
{
type limitFields;
libs ("libfieldFunctionObjects.so");
...
fields (U);
limit max;
max 100;
}
Where the entries comprise:
Property | Description | Required | Default
type | type name: limitFields | yes |
fields | list of fields to process | yes |
limit | bound to limit - see below | yes |
min | min limit value | partly |
max | max limit value | partly |
The "limit" entry can take the value:
- min : specify a minimum value
- max : specify a maximum value
- both : specify a minimum value and a maximum value
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
);
}
- replace stringOps::toScalar with a more generic stringOps::evaluate
method that handles scalars, vectors etc.
- improve #eval to handle various mathematical operations.
Previously only handled scalars. Now produce vectors, tensors etc
for the entries. These tokens are streamed directly into the entry.
This condition applies a scalar multiplier to the value of another
boundary condition.
Usage
Property | Description | Required | Default value
scale | Time varing scale | yes |
patch | patchField providing the raw patch value | yes |
Example of the boundary condition specification to scale a reference
velocity of (15 0 0) supplied as a fixedValue by a table of values
that ramps the scale from 0 to 1 over 1 second:
<patchName>
{
type scaledFixedValue;
scale table
(
( 0 0)
( 1.0 1.0)
(100.0 1.0)
);
patch
{
type fixedValue;
value uniform (15 0 0);
}
}
- The previous option 'write-nut' controlled the writing of turbulence
nut, but other turbulence fields were always written.
These have been shown to be a source of instability for many cases.
This commit replaces the 'write-nut' option by a 'writeTurbulenceFields'
option that controls the writing of all turbulence fields.
If not set, only the velocity field is written.
For compatibility, the old 'write-nut' option is still recognized
but is redirected to 'writeTurbulenceFields'.
Set the m4 -I include accordingly to have the folllowing:
- the directory of the parser.
- include/ in the top-level source tree of the current target
(eg, src/finiteVolume/include-m4/ when compiling libfiniteVolume)
- include/ from OpenFOAM
Additional -dry-run option for makeParser, wrap-lemon for expanding m4
only.
Extend m4 wrapping support to include bison as well.
- include the trailing newline for the "// comment" form, but also add
in leading space removal. This ensure that we do not introduce odd
indentation, while also eliminating lines that are solely C++
comments.
- output the "uniform", "nonuniform" Field entry tags as words instead
of raw character strings, which can help for direct tokenization or
when sending/receiving via Pstreams.
- some support for "uniform" bool fields. Calculating an averaged
value for a boolField does not work very well, but we simply define
that the field average is 'true' when more than 1/2 of its values
are true. Not exactly true, but allows templated definitions to work
smoothly.
- additional output method writeValue().
This outputs the single (uniform) value or the first value of the
field.
- ITstream append() would previously have used the append from the
underlying tokenList, which leaves the tokenIndex untouched and
renders the freshly appended tokens effectively invisible if
interspersed with primitiveEntry::read() that itself uses tokenIndex
when building the list.
The new append() method makes this hidden ITstream bi-directionality
easier to manage. For efficiency, we only append lists
(not individual tokens) and support a 'lazy' resizing that allows
the final resizing to occur later when all tokens have been appended.
- The new ITstream seek() method provides a conveniently means to move
to the end of the list or reposition to the middle.
Using rewind() and using seek(0) are identical.
ENH: added OTstream to output directly to a list of tokens
---
BUG: List::newElem resized incorrectly
- had a simple doubling of the List size without checking that this
would indeed be sufficient for the requested index.
Bug was not triggered since primitiveEntry was the only class using
this call, and it added the tokens sequentially.
This adds automatic deletion of cells inside small gaps. This is
generally used to avoid having excessive numbers of cells in irrelevant
areas of a geometry. It is nearly the opposite of automatic gap refinement
- that refines cells to resolve the gap; this functionality removes cells
to not mesh the gap.
The proximity handling will remove those cells which are inside 'thin' gaps
where 'thin' is defined as a distance of 2*'blockLevel'
It will
- detect surfaces which have the new 'blockLevel' specification
- convert this to a minimum gap distance
- detect cells which are inside this gap
- remove these cells and add exposed faces to the nearest 'real' patch
- The case files may contain #... comment lines
- The geometry file may contain an optional "extents" entry
- Properly handle element id specifications (off|assign|ignore|given).
- Partially handle node id specifications (off|assign|ignore|given).
Treat "given" like "ignore", since results in the lightest amount of
coding and in many cases the "given" node ids are in fact 1-based
contiguous values and thus no different than "ignore" for our
purposes.
