Skip to content

ENH: DMD: refactor dynamic mode decomposition FO

Kutalmış Berçin requested to merge feature-refactoring-dmd into develop

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

STDMDcould 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;
Edited by Kutalmış Berçin

Merge request reports