filtering settings for targets during Synthetic history interpolation

[GabrielSoto-INL]

---

Pull Request Description

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

#2389

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

The Problem
During interpolation of a SyntheticHistory ROM, learned features from a characterizing TSA algorithm are interpolated between missing data years. The interpolated values are then written to the final ROM for the missing macroSteps.

When setting the values, each TSA characterizing algorithm (whether global or local/per segment) reads in a dictionary of interpolated params and loops through all target signals to set new values. However, if we have an XML where we have two nodes of the same algorithm, the target list is mismatched from the trained params and the interpolated params. An example is shown below with a modified /tests/framework/ROM/TimeSeries/SyntheticHistory/varma_interpolated.xml test that has two added <fourier> algorithms:

The Solution
The problem is solved by properly filtering the trained settings based on the correct node before setting the ROM features.

---

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 e3eff52 : invalidated by @joshua-cogliati-inl

failed rm directory not empty

[moosebuild]

Job Mingw Test on 637f2cc : invalidated by @GabrielSoto-INL

Timed out from delayed start

[moosebuild]

Job Mingw Test on 637f2cc : invalidated by @GabrielSoto-INL

[moosebuild]

Job Mingw Test on 637f2cc : invalidated by @joshua-cogliati-inl

failed in fetch

[dylanjm]

These changes are good and ready to merge.

[moosebuild]

Job Test qsubs sawtooth on a422810 : invalidated by @joshua-cogliati-inl

failed in fetch

[moosebuild]

Job Test Fedora 31 on a422810 : invalidated by @joshua-cogliati-inl

restarted civet

[moosebuild]

Job Test mac on 2d5d739 : invalidated by @joshua-cogliati-inl

failed in set python environment with download failure

[moosebuild]

Job Mingw Test on 2d5d739 : invalidated by @GabrielSoto-INL

failed in fetching Raven