openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2021-06-08T20:14:41Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/465TUT: mesh, multiphase: clean up tutorials2021-06-08T20:14:41ZKutalmış BerçinTUT: mesh, multiphase: clean up tutorials[testLoopReport-old.gz](/uploads/9bc2a67785228a2c226abe8ed4ee7d2a/testLoopReport.gz)
[testLoopReport-new.gz](/uploads/2ffc2a3da8fd9778514b490ecc1ab994/testLoopReport.gz)[testLoopReport-old.gz](/uploads/9bc2a67785228a2c226abe8ed4ee7d2a/testLoopReport.gz)
[testLoopReport-new.gz](/uploads/2ffc2a3da8fd9778514b490ecc1ab994/testLoopReport.gz)v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/464TUT: basic, IO, preProcessing, VV: clean up tutorials2021-06-09T13:39:17ZKutalmış BerçinTUT: basic, IO, preProcessing, VV: clean up tutorials[testLoopReport-old.gz](/uploads/26cf0709babf6bd781a818790f16275e/testLoopReport.gz)
[testLoopReport-new.gz](/uploads/f6d5cb4be7291fbae4945c3e38cb0b8d/testLoopReport.gz)[testLoopReport-old.gz](/uploads/26cf0709babf6bd781a818790f16275e/testLoopReport.gz)
[testLoopReport-new.gz](/uploads/f6d5cb4be7291fbae4945c3e38cb0b8d/testLoopReport.gz)v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/463ENH: Adding subMesh option to momentumError and div FOs2021-07-03T19:59:35ZSergio FerrarisENH: Adding subMesh option to momentumError and div FOs- Adding subMesh capabilities to momentumError and div FOs.
- A subMesh is created from cellZones to compute FOs.
- The operators (div, etc) are only calculated in the subMesh.
- Zero field is written in the non-subMesh cells.
- Op...- Adding subMesh capabilities to momentumError and div FOs.
- A subMesh is created from cellZones to compute FOs.
- The operators (div, etc) are only calculated in the subMesh.
- Zero field is written in the non-subMesh cells.
- Optionally, halo cells can be added to the cellZones.
- New helper class to handle the subMesh creation and field mapping.
- TUT: add an example to `tutorials/compressible/rhoSimpleFoam/aerofoilNACA0012`v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/462TUT: incompressible: clean up tutorials2021-06-08T20:17:01ZKutalmış BerçinTUT: incompressible: clean up tutorials[testLoopReport-old.gz](/uploads/fd21c57a06667a0e7b7cc011a7439440/testLoopReport.gz)
[testLoopReport-new.gz](/uploads/6541448fcc63a08614a149ce886731b3/testLoopReport.gz)
Additionally, `Allrun` was executed for both (including the adjoi...[testLoopReport-old.gz](/uploads/fd21c57a06667a0e7b7cc011a7439440/testLoopReport.gz)
[testLoopReport-new.gz](/uploads/6541448fcc63a08614a149ce886731b3/testLoopReport.gz)
Additionally, `Allrun` was executed for both (including the adjoint), resulting in pass.v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/461TUT: combustion: clean up tutorials2021-06-08T20:24:35ZKutalmış BerçinTUT: combustion: clean up tutorials[logs-old.gz](/uploads/513e7e4ff9bed9427dd13afacc98e567/logs.gz)
[testLoopReport-old.gz](/uploads/04bd97a0bbde7f6a999bd870b1a54679/testLoopReport.gz)
[logs-new.gz](/uploads/2343b658ce058efe1e802d0ad3326d9d/logs.gz)
[testLoopReport-new...[logs-old.gz](/uploads/513e7e4ff9bed9427dd13afacc98e567/logs.gz)
[testLoopReport-old.gz](/uploads/04bd97a0bbde7f6a999bd870b1a54679/testLoopReport.gz)
[logs-new.gz](/uploads/2343b658ce058efe1e802d0ad3326d9d/logs.gz)
[testLoopReport-new.gz](/uploads/4f49690308dd869e533dae50a0af2964/testLoopReport.gz)
```
base0 = work
base1 = tutorial-combustion
api = 2103
patch = 210414
HEAD = cf6b675a8b
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
```v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/459TUT: compressible: clean up tutorials2021-05-27T09:00:24ZKutalmış BerçinTUT: compressible: clean up tutorials- elementwise the same:
[logs-old.gz](/uploads/ef3824e69f7dd916a3ed322b0d80b739/logs.gz)
[testLoopReport-old.gz](/uploads/ac9d00a5b8c1780571564b96ceed799d/testLoopReport.gz)
[logs-new.gz](/uploads/a874d039d99ec0f730e1c4a54098356c/logs...- elementwise the same:
[logs-old.gz](/uploads/ef3824e69f7dd916a3ed322b0d80b739/logs.gz)
[testLoopReport-old.gz](/uploads/ac9d00a5b8c1780571564b96ceed799d/testLoopReport.gz)
[logs-new.gz](/uploads/a874d039d99ec0f730e1c4a54098356c/logs.gz)
[testLoopReport-new.gz](/uploads/1e90d330490264b02a7206c2f2857026/testLoopReport.gz)
- the environment of the old setup:
```
base0 = base
base1 = develop
api = 2103
patch = 210414
HEAD = 3273e6c21a
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
```v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/458TUT: heatTransfer: clean up tutorials2021-05-26T11:36:22ZKutalmış BerçinTUT: heatTransfer: clean up tutorials- elementwise the same:
[logs-old.gz](/uploads/fabc366885ebda688028a1bc92bb8e9f/logs.gz)
[testLoopReport-old.gz](/uploads/62469080cea9f65e91ba275a970ed733/testLoopReport.gz)
[logs-new.gz](/uploads/ef7706e0e8477642d874f4bacd5ac091/logs...- elementwise the same:
[logs-old.gz](/uploads/fabc366885ebda688028a1bc92bb8e9f/logs.gz)
[testLoopReport-old.gz](/uploads/62469080cea9f65e91ba275a970ed733/testLoopReport.gz)
[logs-new.gz](/uploads/ef7706e0e8477642d874f4bacd5ac091/logs.gz)
[testLoopReport-new.gz](/uploads/4bafc00041f330ef89341b7a0c1afee4/testLoopReport.gz)
- the environment of the old setup:
```
base0 = base
base1 = develop
api = 2103
patch = 210414
HEAD = 9a3d27e3df
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
```v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/457support parallel creation of finiteArea meshes with on-the-fly decomposition ...2021-05-28T18:14:55ZMark OLESENsupport parallel creation of finiteArea meshes with on-the-fly decomposition of fields #2084v2106Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/456Support AMI for multi-world operation2021-05-26T08:27:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comSupport AMI for multi-world operation### Summary
Multi-world operation now supports AMI (`nearestPatchFaceAMI`)
Fixes #2099### Summary
Multi-world operation now supports AMI (`nearestPatchFaceAMI`)
Fixes #2099v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/454ENH: turbulentDFSEMInlet: various improvements2021-06-22T09:18:22ZKutalmış BerçinENH: turbulentDFSEMInlet: various improvements### Summary
- ENH: Input entries of `R`, `L` and `U` are now `PatchFunction1` type.
- ENH: Adds two scalar normalisation factors for input `R`, `L` and `U`: `Uref` and `Lref` (default=1).
- ENH: Adds a scalar factor to enable users to t...### Summary
- ENH: Input entries of `R`, `L` and `U` are now `PatchFunction1` type.
- ENH: Adds two scalar normalisation factors for input `R`, `L` and `U`: `Uref` and `Lref` (default=1).
- ENH: Adds a scalar factor to enable users to tune the C1 normalisation coefficient: `scale` (default=1).
- BUG: MappedFile: separates scopes of entries.
- TUT: Replaces `chan395DFSEM` and `PCF` tutorials with `planeChannel` and `oneCellThickPlaneChannel` tutorials.
- Corrects the integral-length scale input files.
- Updates the [Extended Code Guide's channel flow](https://www.openfoam.com/documentation/guides/latest/doc/verification-validation-turbulent-plane-channel-flow.html) case, and allows users to reproduce the results.
### Resolved bugs (If applicable)
#2098
#2097
#2090
#1004
#1744
#2089
### Details of new models (If applicable)
A set of results obtained from the `planeChannel` tutorial (and its plot script available to users) with a different set of settings can be seen below:
##### Ruv vs y
![Ruv_vs_y](/uploads/0a9a5a8b41f5c19a8ccacc3d1614d554/Ruv_vs_y.png)
##### u vs y
![u_vs_y](/uploads/e43ae1708a96ba6c77955d33e4ebf5ca/u_vs_y.png)
##### Ruu vs y
![Ruu_vs_y](/uploads/d30bcba9424ab2cf2fd63f9ebcb41285/Ruu_vs_y.png)
##### x vs Cf
![x_vs_cf](/uploads/c7f25cfb42129756c84d9a76ce010170/x_vs_cf.png)
##### Rvv vs y
![Rvv_vs_y](/uploads/aa956075682e9331172a0ddbd92ab727/Rvv_vs_y.png)
##### Rww vs y
![Rww_vs_y](/uploads/00cdcd67ba65659f8469c59415a46d23/Rww_vs_y.png)
### Risks
##### User input
Users (my apologies) will have to change the input syntax for `R`, `L` and `U` entries. For example, for reading the input files in `constant/boundaryData/inlet/0/`, users were using the following minimal syntax:
```
inlet
{
type turbulentDFSEMInlet;
delta 1;
mapMethod nearestCell;
value $internalField;
}
```
For the same effect, one of the syntax examples could be as follows:
```
inlet
{
type turbulentDFSEMInlet;
delta 1;
U mappedFile;
R mappedFile;
L mappedFile;
mapMethod nearest;
value $internalField;
}
```
or as follows:
```
inlet
{
type turbulentDFSEMInlet;
delta 1;
U
{
type mappedFile;
mapMethod nearest;
}
R
{
type mappedFile;
mapMethod nearest;
}
L
{
type mappedFile;
mapMethod nearest;
}
value $internalField;
}
```
Users can, however, use any of the `PatchFunction1` input syntax exemplified in this [link](https://www.openfoam.com/news/main-news/openfoam-v1812/core#core-patch-function1) and this [link](https://www.openfoam.com/news/main-news/openfoam-v20-06/pre-processing#pre-processing-expression-patchfunction1).
##### Regressions
- ~~The default value of `nCellPerEddy` entry was changed from 5 to 1, which is the default value corresponding to the original journal paper.~~
- The default value of `nCellPerEddy` entry was kept the same as 5.
##### Remaining issues
- Arguably, the DFSEM method has various theoretical issues that need to be addressed (see #2090). We have been trying to reach the originators of the method during the last couple of years; and we will continue our efforts, if possible, to cooperate with them to resolve some of these issues.v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/451TUT: finiteArea: clean up tutorials2021-06-09T13:41:55ZKutalmış BerçinTUT: finiteArea: clean up tutorials[old-testLoopReport.gz](/uploads/9cba8c30d2af84df40afefabf33a3565/old-testLoopReport.gz)
[new-testLoopReport.gz](/uploads/e9a555b45ae7beb188d78198e359ba56/new-testLoopReport.gz)
[old-logs.gz](/uploads/b51c81ef8a656bf373b5d76c3a31d395/o...[old-testLoopReport.gz](/uploads/9cba8c30d2af84df40afefabf33a3565/old-testLoopReport.gz)
[new-testLoopReport.gz](/uploads/e9a555b45ae7beb188d78198e359ba56/new-testLoopReport.gz)
[old-logs.gz](/uploads/b51c81ef8a656bf373b5d76c3a31d395/old-logs.gz)
[new-logs.gz](/uploads/217a781a7a9a5a1845de65dc7ae4acfb/new-logs.gz)v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/450ENH: update geoVoF module (#2076)2021-06-24T16:48:11ZHenning ScheuflerENH: update geoVoF module (#2076)@johan_roenby
Changes:
* renamed interface fields recon::centre -> interfaceCentre.{phaseName}
* interface fields are not written by default
* compatible with AMR and load balancing
Status:
* all tests and tutorial cases pass
the test...@johan_roenby
Changes:
* renamed interface fields recon::centre -> interfaceCentre.{phaseName}
* interface fields are not written by default
* compatible with AMR and load balancing
Status:
* all tests and tutorial cases pass
the testsuite is not included in the commits but is available in issue #2076.v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/449refactor and extend handling of faSchemes/fvSchemes2021-05-14T18:36:39ZMark OLESENrefactor and extend handling of faSchemes/fvSchemesv2106Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/447STYLE: PDRFOAM End of Program was inconsistent with other applications2021-06-18T13:18:00ZHenning ScheuflerSTYLE: PDRFOAM End of Program was inconsistent with other applicationsfixes issue #2091fixes issue #2091v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/446collected changes for Lists, faces and PrimitivePatch2021-05-13T10:53:04ZMark OLESENcollected changes for Lists, faces and PrimitivePatchv2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/445add multi-region handling for checkMesh etc, centralized the region handling...2024-01-05T16:57:08ZMark OLESENadd multi-region handling for checkMesh etc, centralized the region handling #2072Introduces a few new include files that simplify and improve the code structure for multi-region utilities
- addAllRegionOptions.H
- getAllRegionOptions.H
- createNamedMeshes.HIntroduces a few new include files that simplify and improve the code structure for multi-region utilities
- addAllRegionOptions.H
- getAllRegionOptions.H
- createNamedMeshes.Hv2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/443ENH: CloudFunctionObject: new particle function objects2021-06-08T20:35:31ZKutalmış BerçinENH: CloudFunctionObject: new particle function objects### Summary
* acec5badc7 - ENH: lagrangian: add new CloudFunctionObjects
- New cloud function objects:
- ReynoldsNumber (for kinematic parcels, i.e. KinematicReynoldsNumber)
- ReynoldsNumber (for thermo/reacting parcels, i...### Summary
* acec5badc7 - ENH: lagrangian: add new CloudFunctionObjects
- New cloud function objects:
- ReynoldsNumber (for kinematic parcels, i.e. KinematicReynoldsNumber)
- ReynoldsNumber (for thermo/reacting parcels, i.e. ThermoReynoldsNumber)
- NusseltNumber
- HeatTransferCoeff
* 83e3043dec - ENH: lagrangian: split macros for CloudFunctionObjects
- three macros:
- makeParcelCloudFunctionObjects for kinematic parcels
- makeThermoParcelCloudFunctionObjects for thermo parcels
- makeReactingParcelCloudFunctionObjects for reacting parcels
* 4c13f687b7 - DOC: lagrangian: review heat transfer models
* 2107c10f3b - ENH: RanzMarshall: generalises the Nusselt-number correlation
* 3d14d3f7ec - ENH: rhoThermos: enable transport:tabulated + equationOfState:icoPolynomial
### Details of new models (If applicable)
- See the header file documentations for the details.
- Users can enable the cloud FOs as follows:
```
cloudFunctions
{
ReynoldsNumber1
{
type ReynoldsNumber;
// picks kinematic or thermo Reynolds number FO
// based on the operand cloud type.
// e.g. for sprayFoam, the ThermoReynoldsNumber
// is activated in the background.
}
NusseltNumber1
{
type NusseltNumber;
}
HeatTransferCoeff1
{
type HeatTransferCoeff;
}
}
```
- Various results in comparison to experimental results reported in [Buist et al., (2017)](https://www.doi.org/10.1016/j.ces.2016.04.022):
![Re_vs_Nu](/uploads/8ded0601dcdd0e3344349715ed0523e7/Re_vs_Nu.png)
- Users can also input custom values for the correlation coefficients in the Ranz-Marshall correlation, e.g.:
```
subModels
{
RanzMarshallCoeffs
{
a 2.0;
b 0.6;
m 0.5;
n 0.6666;
}
}
```
### Risks
- No change to the previous output state or to the user input
- Alltest: pass [logs.gz](/uploads/d4852ee2206ee4928ce7734be9b43aea/logs.gz) [testLoopReport.gz](/uploads/860a89f5cc0f5abbc17da65e32301518/testLoopReport.gz)
- sprayFoam/aachenBomb: pass (parallel:random)
- Doxygen: pass
- clang/gcc compilations: passv2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/442consistency improvements for regex and hashes, etc2021-04-19T16:34:10ZMark OLESENconsistency improvements for regex and hashes, etcAccumulated changes/fixes for improving consistency.
- fileName : improve handling of windows-style path separators
- wordRe / keyType : reduce code duplication in favour of using wordRe more consistently
- hashes : rejig hashing overlo...Accumulated changes/fixes for improving consistency.
- fileName : improve handling of windows-style path separators
- wordRe / keyType : reduce code duplication in favour of using wordRe more consistently
- hashes : rejig hashing overloads and class-local versions to improve future extensibilityv2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/441ENH: SpalartAllmaras: add estimation functions for k, epsilon and omega2021-05-27T08:59:07ZKutalmış BerçinENH: SpalartAllmaras: add estimation functions for k, epsilon and omega### Summary
- Adds estimation functions for `k`, `epsilon`, `omega` fields into the `SpalartAllmaras` turbulence closure model, so that various utilities can be enabled with this model if necessary, e.g. `turbulenceFields` function obje...### Summary
- Adds estimation functions for `k`, `epsilon`, `omega` fields into the `SpalartAllmaras` turbulence closure model, so that various utilities can be enabled with this model if necessary, e.g. `turbulenceFields` function object.
- Reduces peak-memory usage in the `SpalartAllmaras` model.
### Resolved bugs
N/A
### Details of new models
- The first test case was based on a direct-numerical simulation
by (Moser et al., 1999). The test case is a smooth-wall turbulent
plane channel flow wherein an internal flow statistically develops downstream
(until is fully developed) through parallel smooth walls that are two
characteristic-length apart. The friction Reynolds number of the flow is
$`\mathrm{Re}_\tau = 180`$.
##### Turbulent kinetic energy
<img src="/uploads/b0cf7d41b347137dc29afe6a16776929/all_setups_yPlus_vs_kPlus1.png" width="50%" height="50%"/>
##### Turbulent kinetic energy dissipation rate
<img src="/uploads/c3349de9e0923e438206b9a2d4fa3a3d/all_setups_yPlus_vs_epsilonPlus.png" width="50%" height="50%"/>
##### Turbulent kinetic energy production rate
<img src="/uploads/7fe9b01e82dafe5a40e30190a76f0d51/all_setups_yPlus_vs_productionRatePlus.png" width="50%" height="50%"/>
##### Streamwise flow speed
<img src="/uploads/9f9fd069fcb7e6d9762b52e7f250d8c0/all_setups_yPlus_vs_uPlus.png" width="50%" height="50%"/>
##### Reynolds stress tensor components
<img src="/uploads/c4c631ee9e2a487c7475f34e3c6bb476/all_setups_yPlus_vs_Ruv.png" width="50%" height="50%"/>
<img src="/uploads/982bc15a688f2388778f22bc4e3445c0/all_setups_yPlus_vs_Rww.png" width="50%" height="50%"/>
<img src="/uploads/038dda65b4c2e4015013c58f7812529f/all_setups_yPlus_vs_Rvv.png" width="50%" height="50%"/>
<img src="/uploads/5e174efaba0470289ba83133942238b9/all_setups_yPlus_vs_Ruu.png" width="50%" height="50%"/>
### Risks
No known risks or user-input changes.
PS: Hi @vaggelisp, might affect or be relevant? just for your info in any case.v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/440ENH: DMD: refactor dynamic mode decomposition FO2021-04-26T15:00:55ZKutalmış BerçinENH: DMD: refactor dynamic mode decomposition FO#### Summary
##### Feature-1: Refactoring the dynamic mode decomposition (DMD) module
In `v2006`, OpenFOAM had learned a function object capability called “Streaming Total Dynamic Mode Decomposition” (i.e. `STDMD`) which was a variant ...#### Summary
##### Feature-1: Refactoring the dynamic mode decomposition (DMD) module
In `v2006`, OpenFOAM had learned a function object capability called “Streaming Total Dynamic Mode Decomposition” (i.e. `STDMD`) which was a variant of dynamic mode decomposition method (i.e. data-driven/equation-free dimensionality reduction method).
Although the `STDMD` was observed to provide the general DMD method capabilities alongside economised and feasible memory and CPU usage, in the last decade or so, many variants arose, "such as multiresolution DMD, compressed DMD, forward backward DMD, and higher order DMD among others, in order to deal with noisy data, big dataset, or spurious data for example."
This set of commits allows developers/users to implement their own DMD models by providing them a more user-friendly interface and class hierarchies within a new `DMD` module.
##### Feature-2: Enabling `postProcess` utility
`STDMD` could operate on run time by using `system/controlDict.functions`, i.e. the data processing that is performed during the running of an ongoing simulation.
However, `STDMD` could not operate as a postprocessing routine, i.e. the data processing activity that occurs after a simulation has run.
This set of commits provides the required capabilities to execute a `DMD` model on ascii/binary OpenFOAM fields that are already written by an OpenFOAM simulation after either a serial or parallel computation.
The new implementation allows a `DMD` model to be executed by using the `postProcess` utility after a simulation is completed, and required fields are written.
A minimal example by using the `postProcess` utility can be as follows (the utility reads the `DMD` settings from `system/controlDict.functions`):
<solver> -postProcess -fields '(U p)' -time '10:'
##### Feature-3: Enabling operations on patch fields
`STDMD`could operate on a given `{vol,surface}<Type>Field` where `<Type>` can be either of the OpenFOAM object types: `scalar`, `vector`, `symmetricTensor` or `tensor`.
However, `STDMD` could not operate on an input patch field, such as `wallShearStress`.
This set of commits provides the required capabilities to execute a `DMD` model on a given patch field for selected patch(es) in serial and parallel modes during an ongoing computation or during a postprocessing activity.
Selection of a certain group of patches instead of operating on all patches has been ensured, reportedly, "to constrain the input data to specific patches, not only for data reduction, but also to prevent from inserting constant entries into the `DMD` snapshots", a situation for which no concrete theoretical information is available (i.e. it is not well known "what happens to `DMD` if a majority of snapshot contents do not change over time.")
#### Resolved bugs (If applicable)
N/A
#### Details of new models (If applicable)
Please see the header-file documentations available in
- `DMD.H`
- `DMDModel.H`
- `STDMD.H`
#### Risks
A given set of settings for `v2006`-`STDMD` could not be run with this set of commits. Having said that the user input changes are self explanatory and can easily be performed.
Also, developers/users had been kindly warned in `v2006` by the following hard-coded warning stream:
```c
Info<< nl
<< " ### This STDMD release is the beta release ###" << nl
<< " Therefore small-to-medium changes in input/output interfaces "
<< "and internal structures should be expected in the next versions."
<< endl;
```v2106Andrew HeatherAndrew Heather