[DEFECT] Economic parameters cannot be specified with anything but <sweep_values> subnode

[j-bryan]

---

Defect Description

Describe the defect

What did you expect to see happen?

Model to be evaluated at specified sweep values. Documentation indicates <sweep_values> is an accepted subnode for <reference_price> (see provided heron_input.xml).

What did you see instead?

Error when calculating economics due to specified sweep values being a list. The end goal here is to be able to specify a range of economics values as part of a sensitivity analysis.

Do you have a suggested fix for the development team?

The swept economics values could probably be evaluated after the dispatch optimization in RAVEN and addressed within HERON while the economic metrics are being calculated. The standard dispatch optimization doesn't seem to rely on the values specified in the node, so adding these to the sampling grid in RAVEN (outer.xml) would duplicate design points which do affect dispatch. I'm not sure if optimizing these values would ever make sense (i.e. using <opt_bounds> to specify values) for these nodes.

Alternative, just amend <reference_price>, <reference_driver>, and <growth_factor_x> to accept only the <fixed_value> subnode.

Describe how to Reproduce
Steps to reproduce the behavior:

1. Use <sweep_values> node to specify values for <reference_price>
2. Run model with HERON, then RAVEN.

Screenshots and Input Files
Please attach the input file(s) that generate this error. The simpler the input, the faster we can find the issue.

HERON input XML file and relevant out~inner file with error messages changed to .txt to allow upload and are attached.

Platform (please complete the following information):

• OS: Windows 10 Enterprise
• Version: 19043
• Dependencies Installation: CONDA
• HERON (3fc4137)
• RAVEN (4fee4b9b4bf298451a3c27e003edb30fc01c48c6)

---

For Change Control Board: Issue Review

This review should occur before any development is performed as a response to this issue.

• 1. Is it tagged with a type: defect or task?
• 2. Is it tagged with a priority: critical, normal or minor?
• 3. If it will impact requirements or requirements tests, is it tagged with requirements?
• 4. If it is a defect, can it cause wrong results for users? If so an email needs to be sent to the users.
• 5. Is a rationale provided? (Such as explaining why the improvement is needed or why current code is wrong.)

---

For Change Control Board: Issue Closure

This review should occur when the issue is imminently going to be closed.

• 1. If the issue is a defect, is the defect fixed?
• 2. If the issue is a defect, is the defect tested for in the regression test system? (If not explain why not.)
• 3. If the issue can impact users, has an email to the users group been written (the email should specify if the defect impacts stable or master)?
• 4. If the issue is a defect, does it impact the latest release branch? If yes, is there any issue tagged with release (create if needed)?
• 5. If the issue is being closed without a pull request, has an explanation of why it is being closed been provided?
  heron_input.txt
  out-inner.txt

[PaulTalbot-INL]

This is an excellent feature request (or defect we should not claim as a current feature). We had FY23 scope proposed for this activity this year, but it has not been funded yet as of this note. We think stochastically treating the costing data could be very valuable in capturing the expected economic efficacy of portfolios.

[j-bryan]

Am I right in thinking that we could address that uncertainty after we've done the dispatch optimization? Seems like it would be relatively easy to implement and computationally inexpensive.

[PaulTalbot-INL]

Yes, it is independent (and linear) from the dispatch optimization so it should be almost completely trivial to handle quickly if we set it up right.