ENH: 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 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.
postProcess
utility
Feature-2: Enabling 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:
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;