Arma macro len

[PaulTalbot-INL]

---

Pull Request Description

What issue does this change request address?

Closes #69

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

Adds an explicit check of the serialized ARMA during compile time to check the samples will be shaped appropriately.

Also removes a workaround that was allowing one-year ARMAs to be used as multiyear ARMAs by re-using the same sample; this was not a designed behaviour.

Also adds structure to integration tests, splitting them into "workflows" and "mechanics". Workflows are good starting places for user cases, while mechanics are more algorithmic tests and less useful as starting workflows.

---

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.
• 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 tes.
• 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, the the analytic documentation must be updated/added.
• 9. If any test used as a basis for documentation examples have been changed, the associated documentation must be reviewed and assured the text matches the example.

[dylanjm]

Less of a comment and more for my own knowledge. Can you describe a situation when you have a 1-year ARMA that needs multiyearing? I'm not quite sure what exactly that means.

[PaulTalbot-INL]

Yeah, sure.

In a "infinite" NPV analysis, you really want to look at the same behavior year after year until the cashflows asymptotically approach 0. We've deviated from that to do specific project lengths, with the somewhat unspoken hypothesis that 30 or 60 years is functionally infinite. Further, we've deviated to use "interpolated" ARMAs so that every year isn't really the same, but instead evolves according to some pattern.

A multiyear ARMA, at its base, samples the ARMA (clusters and all) uniquely for each year, but it's the same ARMA being sampled for each year. Hence, you get unique realization each year, but from the same sampling source. In contrast, for the Interpolated ARMA, you get a sample from a different source for each year.

We should be able to handle a single-year ARMA in multiyear mode (through flags you place on the pickeldROM instance in RAVEN) as easily as handling an Interpolated ARMA.

[dylanjm]

This looks good to me. I had a question regarding multiyear ARMAs.

Also, regarding adding the arma.pk files to the commit history. I realize we probably commit them as the are required by the other integration tests. What are your thoughts on adding a prerequisite tag to the integration tests that need an ARMA?

[PaulTalbot-INL]

What are your thoughts on adding a prerequisite tag to the integration tests that need an ARMA?

See idaholab/raven/issues/1237, yes, I would love to do this.

EDIT: I added a task in HERON to track this.