Multi-Resolution Time Series Analysis

[GabrielSoto-INL]

---

Pull Request Description

What issue does this change request address? (Use "#" before the issue to link it, i.e., #42.)

2128

What are the significant changes in functionality due to this change request?

Replaces #2129 .

New changes include introduction of multi-resolution time series analysis capabilities to RAVEN, particularly incorporated within the ROMCollection , SyntheticHistory and TSA module infrastructure. Multiresolution (MR) time series analysis algorithms are capable of investigating the inherent dynamics of time series at multiple timescales or frequencies. Decomposition of time series at multiple levels is a typical MR algorithm. These changes add the capability of decomposing time series signal(s) at different levels via a MR algorithm while still leveraging characterization, additional transformation, and generative algorithms within the current TSA library.

A new algorithm was added to the TSA module which is a modified wavelet transform: FilterBankDWT. This algorithm (and more in the future) will be compatible with a new MultiResolutionTSA ROM subtype and a Decomposition ROMCollection subtype. An example input script is shown below to help walk through the new additions:

1. A new ROM subtype called MultiResolutionTSA has been added.
   • It inherits the SupervisedLearning ROM class.
   • It serves the role of the _interfaceROM (for example, when using the standard TSA module, the _interfaceROM is the SyntheticHistory class).
2. A new algorithm FilterBankDWT, using the PyWavelets python package, uses a filter bank discrete wavelet transform to decompose the original signal into various levels.
   • Note that other TSA algorithms can be used to modify or learn characteristics of the signal prior to this algorithm being used.
   • It accepts a wavelet family and an integer number of decomposition levels.
   • After this algorithm is applied (the last applied within this node before the SegmentROM), the signal is split into multiple instances, one per decomposition level.
3. Another new class within the ROMCollection architecture is a Decomposition class which inherits the SupervisedLearning ROM class.
   • It serves the role of the _segmentROM (for example, previous instances use Segment, Clusters, or Interpolated classes).
   • This class handles training and evaluation of algorithms for the time series before and after decomposition.
   • Each decomposition gets assigned to a new instance of a SyntheticHistory object. Any algorithms within the <Segment> node of this input will be applied to each decomposition level (e.g., here, an ARMA model is trained per decomposition level).

Other notes:

• input time series data can be a single macroStep or multiple macroSteps (e.g., multiple years). examples are given in the \tests subdirectory.
• interpolation of learned features between missing macroSteps is not handled within this PR (potential future one).

---

For Change Control Board: Change Request Review

The following review must be completed by an authorized member of the Change Control Board.

• [ ] 1. Review all computer code.
• [ ] 2. If any changes occur to the input syntax, there must be an accompanying change to the user manual and xsd schema. If the input syntax change deprecates existing input files, a conversion script needs to be added (see Conversion Scripts).
• [ ] 3. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the wiki for details.
• [ ] 4. Automated Tests should pass, including run_tests, pylint, manual building and xsd tests. If there are changes to Simulation.py or JobHandler.py the qsub tests must pass.
• [ ] 5. If significant functionality is added, there must be tests added to check this. Tests should cover all possible options. Multiple short tests are preferred over one large test. If new development on the internal JobHandler parallel system is performed, a cluster test must be added setting, in XML block, the node <internalParallel> to True.
• [ ] 6. If the change modifies or adds a requirement or a requirement based test case, the Change Control Board's Chair or designee also needs to approve the change. The requirements and the requirements test shall be in sync.
• [ ] 7. The merge request must reference an issue. If the issue is closed, the issue close checklist shall be done.
• [ ] 8. If an analytic test is changed/added is the the analytic documentation updated/added?
• [ ] 9. If any test used as a basis for documentation examples (currently found in raven/tests/framework/user_guide and raven/docs/workshop) have been changed, the associated documentation must be reviewed and assured the text matches the example.

[moosebuild]

Job Mingw Test on c2e8911 : invalidated by @GabrielSoto-INL

Segmentation fault when activating raven_libraries, trying again?