Dove modifications part 2

[caleb-sitton-inl]

---

Pull Request Description

What issue does this change request address?

#386

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

These changes implement a rough draft of HERON using DOVE to handle dispatch in the inner. The majority of the manual testing on these changes was performed using the https://github.com/idaholab/HERON/blob/devel/doc/workshop/LM2Tutorial/Full/heron_input_solution.xml input script, so that input is most likely to behave as expected. Note the typo in the input file (see changes in this PR). Significant organization and cleanup is necessary on this branch, but it is a working example for many main use cases of HERON. This branch of HERON is designed to pair with the branch of DOVE at https://github.com/caleb-sitton-inl/DOVE/tree/heron-compatibility-changes, so ensure that this is the current branch of DOVE when testing this version of HERON.

This branch of HERON is currently limited in its functionality. The following is a list of all the known assumptions and restrictions:

• It assumes that DOVE has been installed by the user, and that HERON and DOVE are located in the same directory, i.e., they must share a parent directory.
• Governed HERON components (on which <comp>.is_governed() returns True) are not supported.
• Cases that include levelized costs on cashflows (on which <cf>.is_mult_target() returns True) are not supported.
• Much of the debug printing in the dispatch from running HERON with debug_mode = True is no longer operable.
• Polynomial transfer functions are not supported.
• The driver on repeating cashflows with periods that are not 'yearly' (these are the cashflows relevant to dispatch) must contain the activity subnode. DOVE expects every cashflow driver to be directly proportional to the activity of its respective component at every timestep; thus, driver may contain activity and some additional, potentially time-varying multiplication factor. Most often, this factor will be in the form of a multiplier.
• The scaling_factor_x on cashflows relevant to dispatch must be a constant value in time.
• No cashflow parameters or other user-defined inputs can contain the activity ValuedParam, nor can they be dependent on other quantities that are optimized by DOVE (e.g., storage levels, charge, discharge, etc).

---

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.