STDMD (i.e. Streaming Total Dynamic Mode Decomposition) is a variant of
a data-driven dimensionality reduction method.
STDMD is being used as a mathematical post-processing tool to compute
a set of dominant modes out of a given flow (or dataset) each of which is
associated with a constant frequency and decay rate, so that dynamic
features of a given flow may become interpretable, and tractable.
Among other Dynamic Mode Decomposition (DMD) variants, STDMD is presumed
to provide the general DMD method capabilities alongside economised and
feasible memory and CPU usage.
Please refer to the header file documentation for further details.
ENH: add new STDMD tutorial, pimpleFoam/laminar/cylinder2D
The phase systems tables for multiphase solvers create conflict
between each other as they are defined in the same namespace and using
similar class names.
Therefore a special htc function object for reactingEulerSolver was
added (reactingEulerHtcModel), located under
src/phaseSystemModels/reactingEulerFoam/functionObjects/
This commit includes the following:
- Relocate solvers/reactingEulerFoam functionObjects to
src/phaseSystemModels
- Remove links for fieldFunctionObject to multiphase libs to avoid
conflicts
- New FO for htc for reactingEulerFoam called reactingEulerHtcModel
- before (-lreactingPhaseSystem -ltwoPhaseReactingTurbulenceModels)
after (-ltwoPhaseReactingTurbulenceModels -lreactingPhaseSystem)
to fix symbol resolution issue on clang.
multiphaseReactingTurbulenceModels and twoPhaseReactingTurbulenceModels
add models to the same table TurbulenceModel. These two libs were removed
from libreactingPhaseSystem which created the conflict.
The multiphaseReactingTurbulenceModels was added to
reactingMultiPhaseEulerFoam solver and twoPhaseReactingTurbulenceModels to
twoPhaseReactingEulerFoam solver
The FO heatTransferCoeffs for libfieldFunctionObjects needs
twoPhaseReactingTurbulenceModels.
These change avoids linking conflict from multiphaseReactingTurbulenceModels
and twoPhaseReactingTurbulenceModels being linked in the same lib.
1) Adding interfaceHeight FO
2) Adding interfaceHeatResistance mass transfer model to
interCondensatingEvaporatingFoam with spread source approach
3) Reworking framework for icoReactingMultiphaseInterFoam
Calculates the acoustic power due to the volume of isotropic turbulence
using Proudman's formula
The acoustic power \f$ P_A \f$ [W/m3] in terms of turbulence \f$ k \f$
and \f$ \epsilon \f$ is given as:
\f[
P_A = alpha_\epsilon \rho \epsilon M_t^5
\f]
where \f$ alpha_\epsilon \f$ is a constant (0.1) and
\f[
M_t = \frac{\sqrt{2 k}}{a_0}
\f]
with \f$ a_0 \f$ the speed of sound. The acoustic power is also output in
dB using:
\f[
L_P = 10 \log \frac{P_A}{P_ref}
\f]
where \f$ P_ref \f$ is a constant (1e-12 W/m3)
Usage
Example of function object specification to calculate the Proudman acoustic
power
proudmanAcousticPower1
{
type proudmanAcousticPower;
libs ("libfieldFunctionObjects.so");
...
// Required additional entries for incompressible calculations
rhoInf 1.225;
aRef 340;
}
Where the entries comprise:
Property | Description | Required | Default value
type | type name: proudmanAcousticPower | yes |
rhoInf | Freestream density for incompressible cases | no |
aRef | Reference spped of sound for incompressible cases | no |
alphaEps | Model coefficient | no | 0.1
Note
- The freestream density and reference speed of sound are only necessary
when a thermodynamics package is unavailable, typically for incompressible
cases.
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
- If applied:
This commit allows the user to compute:
- the Lamb vector (https://en.wikipedia.org/wiki/Lamb_vector),
- on-the-fly or via postProcess utility
- for a given volVectorField (one per functionObject entry)
- Why:
The motivation is the literature-reported quantitative connection
between the Lamb vector (divergence) and the spatially localised
instantaneous fluid motions, e.g. high- and low-momentum fluid
parcels, which possess considerable level of capacity to affect
the rate of change of momentum, and to generate forces such as drag.
- Verification:
- Smooth-wall plane channel flow case (Moser et al. 1999) by
# Curtis et al. (2008) On the Lamb vector divergence
in Navier–Stokes flows, doi:10.1017/S0022112008002760
- What's next:
- The verification-show case
- Extended code guide entry titled "Lamb vector"
- Eg, with surface writers now in surfMesh, there are fewer libraries
depending on conversion and sampling.
COMP: regularize linkage ordering and avoid some implicit linkage (#1238)
Averages columns of cells for layered meshes.
For each patch face, calculates the average value of all cells attached in
the patch face normal direction, and then pushes the average value back
to all cells in the column.
Useful for channel-like cases where we want to average fields in the
spanwise direction.
Example of function object specification:
columnAverage1
{
type columnAverage;
libs ("libfieldFunctionObjects.so");
...
patches (front side);
fields (U p);
}
Where the entries comprise:
\table
Property | Description | Required | Default value
type | type name: fieldMinMax | yes |
patches | list of patches to collapse onto | yes |
fields | list of fields to process | yes |
\endtable
Reports the min|max|average AMI weights to text file and optionally
writes VTK surfaces of the sum of the weights, and mask field for
ACMI patches.
Example usage:
AMIWeights
{
type AMIWeights;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
writeFields yes;
}
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.
Calculates and outputs a field whose values are offset to a reference
value obtained by sampling the field at a user-specified location.
The field values are calculated using:
\f[
f_c = s(f_{c,t} - f_p + f_{off})
\f]
where
\vartable
f_c | field values at cell
s | optional scale factor (default = 1)
f_{c,t} | current field values at cell at this time
f_p | field value at position
f_{off} | offset field value (default = 0)
\endvartable
Usage
Example of function object specification to calculate the reference
field:
\verbatim
pRef
{
type reference;
libs ("libfieldFunctionObjects.so");
...
field p;
result pRef;
position (0 0 0);
scale 1.2;
offset 100000;
}
\endverbatim
Note: performs its own tracking and does not rely on the base
particle::trackXXX functions, and uses a local particle position.
Look to update to barycentric tracking in the future.
terms of the local barycentric coordinates of the current tetrahedron,
rather than the global coordinate system.
Barycentric tracking works on any mesh, irrespective of mesh quality.
Particles do not get "lost", and tracking does not require ad-hoc
"corrections" or "rescues" to function robustly, because the calculation
of particle-face intersections is unambiguous and reproducible, even at
small angles of incidence.
Each particle position is defined by topology (i.e. the decomposed tet
cell it is in) and geometry (i.e. where it is in the cell). No search
operations are needed on restart or reconstruct, unlike when particle
positions are stored in the global coordinate system.
The particle positions file now contains particles' local coordinates
and topology, rather than the global coordinates and cell. This change
to the output format is not backwards compatible. Existing cases with
Lagrangian data will not restart, but they will still run from time
zero without any modification. This change was necessary in order to
guarantee that the loaded particle is valid, and therefore
fundamentally prevent "loss" and "search-failure" type bugs (e.g.,
2517, 2442, 2286, 1836, 1461, 1341, 1097).
The tracking functions have also been converted to function in terms
of displacement, rather than end position. This helps remove floating
point error issues, particularly towards the end of a tracking step.
Wall bounded streamlines have been removed. The implementation proved
incompatible with the new tracking algorithm. ParaView has a surface
LIC plugin which provides equivalent, or better, functionality.
Additionally, bug report <https://bugs.openfoam.org/view.php?id=2517>
is resolved by this change.
Calculates the acoustic pressure based on Curle's analogy.
Curle's analogy is implemented as:
\f[
p' = 4 \frac{\pi}{c_0}\frac{\vec d}{|\vec d|^2}\frac{d(F)}{d(t)}
\f]
where
p' | Curle's acoustic pressure [Pa] or [Pa (m3/rho)]
c_0 | Reference speed of sound [m/s]
\vec d | Distance vector to observer locations [m]
F | Force [N] or [N (m3/rho)]
Community contribution from Johan Roenby, DHI
IsoAdvector is a geometric Volume-of-Fluid method for advection of a
sharp interface between two incompressible fluids. It works on both
structured and unstructured meshes with no requirements on cell shapes.
IsoAdvector is as an alternative choice for the interface compression
treatment with the MULES limiter implemented in the interFoam family
of solvers.
The isoAdvector concept and code was developed at DHI and was funded
by a Sapere Aude postdoc grant to Johan Roenby from The Danish Council
for Independent Research | Technology and Production Sciences (Grant-ID:
DFF - 1337-00118B - FTP).
Co-funding is also provided by the GTS grant to DHI from the Danish
Agency for Science, Technology and Innovation.
The ideas behind and performance of the isoAdvector scheme is
documented in:
Roenby J, Bredmose H, Jasak H. 2016 A computational method for sharp
interface advection. R. Soc. open sci. 3: 160405.
[http://dx.doi.org/10.1098/rsos.160405](http://dx.doi.org/10.1098/rsos.160405)
Videos showing isoAdvector's performance with a number of standard
test cases can be found in this youtube channel:
https://www.youtube.com/channel/UCt6Idpv4C8TTgz1iUX0prAA
Project contributors:
* Johan Roenby <jro@dhigroup.com> (Inventor and main developer)
* Hrvoje Jasak <hrvoje.jasak@fsb.hr> (Consistent treatment of
boundary faces including processor boundaries, parallelisation,
code clean up
* Henrik Bredmose <hbre@dtu.dk> (Assisted in the conceptual
development)
* Vuko Vukcevic <vuko.vukcevic@fsb.hr> (Code review, profiling,
porting to foam-extend, bug fixing, testing)
* Tomislav Maric <tomislav@sourceflux.de> (Source file
rearrangement)
* Andy Heather <a.heather@opencfd.co.uk> (Integration into OpenFOAM
for v1706 release)
See the integration repository below to see the full set of changes
implemented for release into OpenFOAM v1706
https://develop.openfoam.com/Community/Integration-isoAdvector
Generates discrete particle data from multiphase calculations by
interrogating the phase fraction field at a faceZone.
Data is written in raw form, i.e. per particle collected, with
as an optional binned distribution
The operation can be applied to any volume or surface fields generating a
volume or surface scalar field.
Example of function object specification:
\verbatim
Ttot
{
type add;
libs ("libfieldFunctionObjects.so");
fields (T Tdelta);
result Ttot;
executeControl writeTime;
writeControl writeTime;
}
\endverbatim
Also refactored functionObjects::fieldsExpression to avoid code
duplication between the 'add' and 'subtract' functionObjects.
The operation can be applied to any volume or surface fields generating a
volume or surface scalar field.
Example of function object specification:
\verbatim
Tdiff
{
type subtract;
libs ("libfieldFunctionObjects.so");
fields (T Tmean);
result Tdiff;
executeControl writeTime;
writeControl writeTime;
}
\endverbatim
The use of the term 'source' in the context of post-processing is
confusing and does not properly describe the process of region
selection. The new names 'surfaceRegion' and 'volRegion' better
describe the purpose of the functionObjects which is to provide field
processing functionality limited to a specified region of space, either
a surface or volume.
The keyword 'source' is renamed 'regionType' which better describes the
purpose which is to specify the method by which the surface or volume
region is selected.
The keyword to select the name of the surface or volume region is
renamed from 'sourceName' to 'name' consistent with the other
name-changes above.
with the more general and flexible 'postProcess' utility and '-postProcess' solver option
Rationale
---------
Both the 'postProcess' utility and '-postProcess' solver option use the
same extensive set of functionObjects available for data-processing
during the run avoiding the substantial code duplication necessary for
the 'foamCalc' and 'postCalc' utilities and simplifying maintenance.
Additionally consistency is guaranteed between solver data processing
and post-processing.
The functionObjects have been substantially re-written and generalized
to simplify development and encourage contribution.
Configuration
-------------
An extensive set of simple functionObject configuration files are
provided in
OpenFOAM-dev/etc/caseDicts/postProcessing
and more will be added in the future. These can either be copied into
'<case>/system' directory and included into the 'controlDict.functions'
sub-dictionary or included directly from 'etc/caseDicts/postProcessing'
using the '#includeEtc' directive or the new and more convenient
'#includeFunc' directive which searches the
'<etc>/caseDicts/postProcessing' directories for the selected
functionObject, e.g.
functions
{
#includeFunc Q
#includeFunc Lambda2
}
'#includeFunc' first searches the '<case>/system' directory in case
there is a local configuration.
Description of #includeFunc
---------------------------
Specify a functionObject dictionary file to include, expects the
functionObject name to follow (without quotes).
Search for functionObject dictionary file in
user/group/shipped directories.
The search scheme allows for version-specific and
version-independent files using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>/caseDicts/postProcessing
- ~/.OpenFOAM/caseDicts/postProcessing
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>/caseDicts/postProcessing
- $WM_PROJECT_SITE/caseDicts/postProcessing
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>/caseDicts/postProcessing
- $WM_PROJECT_INST_DIR/site/caseDicts/postProcessing
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/caseDicts/postProcessing
An example of the \c \#includeFunc directive:
\verbatim
#includeFunc <funcName>
\endverbatim
postProcess
-----------
The 'postProcess' utility and '-postProcess' solver option provide the
same set of controls to execute functionObjects after the run either by
reading a specified set of fields to process in the case of
'postProcess' or by reading all fields and models required to start the
run in the case of '-postProcess' for each selected time:
postProcess -help
Usage: postProcess [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-dict <file> read control dictionary from specified location
-field <name> specify the name of the field to be processed, e.g. U
-fields <list> specify a list of fields to be processed, e.g. '(U T p)' -
regular expressions not currently supported
-func <name> specify the name of the functionObject to execute, e.g. Q
-funcs <list> specify the names of the functionObjects to execute, e.g.
'(Q div(U))'
-latestTime select the latest time
-newTimes select the new times
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list, has precedence
over the -withZero option
-parallel run in parallel
-region <name> specify alternative mesh region
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
pimpleFoam -postProcess -help
Usage: pimpleFoam [OPTIONS]
options:
-case <dir> specify alternate case directory, default is the cwd
-constant include the 'constant/' dir in the times list
-dict <file> read control dictionary from specified location
-field <name> specify the name of the field to be processed, e.g. U
-fields <list> specify a list of fields to be processed, e.g. '(U T p)' -
regular expressions not currently supported
-func <name> specify the name of the functionObject to execute, e.g. Q
-funcs <list> specify the names of the functionObjects to execute, e.g.
'(Q div(U))'
-latestTime select the latest time
-newTimes select the new times
-noFunctionObjects
do not execute functionObjects
-noZero exclude the '0/' dir from the times list, has precedence
over the -withZero option
-parallel run in parallel
-postProcess Execute functionObjects only
-region <name> specify alternative mesh region
-roots <(dir1 .. dirN)>
slave root directories for distributed running
-time <ranges> comma-separated time ranges - eg, ':10,20,40:70,1000:'
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
The functionObjects to execute may be specified on the command-line
using the '-func' option for a single functionObject or '-funcs' for a
list, e.g.
postProcess -func Q
postProcess -funcs '(div(U) div(phi))'
In the case of 'Q' the default field to process is 'U' which is
specified in and read from the configuration file but this may be
overridden thus:
postProcess -func 'Q(Ua)'
as is done in the example above to calculate the two forms of the divergence of
the velocity field. Additional fields which the functionObjects may depend on
can be specified using the '-field' or '-fields' options.
The 'postProcess' utility can only be used to execute functionObjects which
process fields present in the time directories. However, functionObjects which
depend on fields obtained from models, e.g. properties derived from turbulence
models can be executed using the '-postProcess' of the appropriate solver, e.g.
pisoFoam -postProcess -func PecletNo
or
sonicFoam -postProcess -func MachNo
In this case all required fields will have already been read so the '-field' or
'-fields' options are not be needed.
Henry G. Weller
CFD Direct Ltd.
