Return Multiple Economic Metrics

[GabrielSoto-INL]

---

Pull Request Description

What issue does this change request address?

#293

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

• In the optimization settings:
  • <metric> has been renamed to <stats_metric> to represent the statistical operator to use on the distribution of economic metrics from the inner (e.g., expectedValue, min, value at risk). Existing tests have been updated to reflect this change.
  • there is a new <opt_metric> to represent the TEAL economic metric which we are creating a distribution of in the inner (currently NPV, IRR, PI). this defaults to NPV
• In the economics node:
  • there is a new node called <EconMetrics> for additional metrics (NPV, IRR, PI) to return to the user after outer run is complete
  • if running sweep mode, this defaults to just NPV. otherwise returns all requested metrics from user
  • if running opt mode, it returns requested metrics alongside with <opt_metric>. Does not return duplicates.
• if <return_statistics> is specified, these statistics are applied to all requested metrics. Otherwise returns the basic statistics as defined within HERON.
• updates to template_driver.py to accommodate multiple metrics
• some additional accessor methods have been added to bypass direct calls to protected class attributes
• updating some strings into Python f-strings

---

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.

[PaulTalbot-INL]

A few comments to consider.

[GabrielSoto-INL]

newest test is taking too long when running as an optimization case. will try switching to a sweep case to avoid timeout error

[PaulTalbot-INL]

LGTM.