Updates related to demand_tech in SLC framework

[elenya-grant]

Updates related to demand_tech in SLC framework

READY FOR HIGH-LEVEL REVIEW

This PR aims to resolve two issues related to SLC:

• SLC: Require user to specify demand component in control_parameters #739
• SLC: Only connect technologies upstream of the demand component to the SLC #740

In this draft implementation, I've required that the user specify the demand technology in the system_level_control section of the plant configuration file. This looks like below:

system_level_control:
  control_strategy: DemandFollowingControl
  demand_component: h2_load_demand # this is new
  solver_options:
    solver_name: gauss_seidel
    max_iter: 20
    convergence_tolerance: 1.0e-6

Background and Questions for reviewers on the above implementation:
An alternative approach would be have the demand_component defined under the control_parameters section. The reason I did not do that approach is to be consistent with the current organization, usage, and distinction between slc_config and control_parameters. The SLC gets two "configuration" dictionaries, slc_config and control_parameters. slc_config is created in H2IntegrateModel._classify_slc_technologies(). The slc_config contains information that is used by both H2IntegrateModel and the SLC for set-up and connection logic. The parameters within the control_parameters dictionary are controller-specific parameters that is only accessed within the SLC (not used by H2IntegrateModel). This is my justification for the route I went, but I'd be curious to hear opinions on the alternative approach if a reviewer finds it appealing.

This simplifies some of the logic in H2IntegrateModel_classify_slc_technologies(). I've also updated it so that only technologies that are upstream and connected to the demand technology are included in the information contained in the slc_config.

Additional Questions for reviewers are noted in Section 2

Example use-cases that would be enabled with this functionality:

• demand component downstream of the demand component specified for SLC: may be used as the commodity stream for a finance subgroup if wanting to calculate the LCO with a commodity stream that is saturated below some value
• demand component upstream of the demand component specified for SLC:
  • may be used similar to a splitter (but is able to be used a commodity stream for finance groups - splitters cannot be used as a commodity stream for finance groups).
  • may be used to intentionally manipulate some SLC behavior. If we have the system used in Example 12 and we want the ammonia plant to operate at 90% CF, then we may pre-calculate the hydrogen demand required to achieve that 90% CF and have that demand used in the hydrogen system. The ammonia demand (which is the demand component for the SLC) would also be targeted at the 90% CF - but the SLC would not be aware of the excess hydrogen that is curtailed from the hydrogen system to enforce this.

Section 1: Type of Contribution

• Feature Enhancement
  • Framework
  • New Model
  • Updated Model
  • Tools/Utilities
  • Other (please describe):
• Bug Fix
• Documentation Update
• CI Changes
• Other (please describe):

Section 2: Draft PR Checklist

• Open draft PR
• Describe the feature that will be added
• Fill out TODO list steps
• Describe requested feedback from reviewers on draft PR
• Complete Section 7: New Model Checklist (if applicable)

TODO:

• Remove commented out code in methods changed in H2IntegrateModel
• Update SLC docs (after initial reviewer feedback)
• Add tests to ensure that new error messages are raised when expected
• Add test(s) and/or example to ensure that the upstream-of-demand component logic works as expected
• Add integration test with a SLC controller to ensure that the upstream-of-demand component logic works as expected

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:

Implementation feedback:

• thoughts on the naming of the new demand_component parameter?
• should we raise an error if a demand technology is defined upstream of the demand_component technology or should that be OK? Like if we had a hydrogen demand component and an ammonia demand component, using the ammonia demand as the demand_component. I don't think we should raise an error, open to ideas though!

Other feedback:

Section 3: General PR Checklist

• PR description thoroughly describes the new feature, bug fix, etc.
• Added tests for new functionality or bug fixes
• Tests pass (If not, and this is expected, please elaborate in the Section 6: Test Results)
• Documentation
  • Docstrings are up-to-date
  • Related docs/ files are up-to-date, or added when necessary
  • Documentation has been rebuilt successfully
  • Examples have been updated (if applicable)
• CHANGELOG.md
  • At least one complete sentence has been provided to describe the changes made in this PR
  • After the above, a hyperlink has been provided to the PR using the following format:
    "A complete thought. [PR XYZ]((https://github.com/NatLabRockies/H2Integrate/pull/XYZ)", where
    XYZ should be replaced with the actual number.

Section 4: Related Issues

Resolves Issue #739 and #740

TODO: make an issue for the possible future use-case of having multiple demand components feed into the SLC (or even if thats a use-case worth considering)

Section 5: Impacted Areas of the Software

Section 5.1: New Files

• h2integrate/core/test/test_slc_framework.py: added in tests for H2Integrate._classify_slc_technologies()
• h2integrate/core/test/inputs/tech_connection_cases.yaml: input file for tests in h2integrate/core/test/test_slc_framework.py

Section 5.2: Modified Files

• H2IntegrateModel in h2integrate/core/h2integrate_model.py
  • __init__(): Updated call to create_technology_graph()
  • create_technology_graph(): updated to take an input list of tech connections and return the graph (rather than set it as an attribute) so it can be used in _classify_slc_technologies()
  • _classify_slc_technologies():
    • updated to use demand_component specified in the system_level_control config instead of looping through technology_interconnections. This included adding in checking for the following cases where an error is raised:
      • demand_tech is missing from the system_level_control section in the plant config
      • the technology specified as the demand_tech is missing from the technology config
      • the technology specified as the demand_tech is not connected in technology_interconnections
      • the technology specified as the demand_tech is not a valid demand technology type (i.e., the performance model name does not include "DemandComponent")
    • updated so that only technologies that are upstream and have a path to the specified demand_tech are included in the tech_to_commodity and technology_graph parameters of the SLC config.
• examples/35_system_level_control/*/plant_config.yaml: added in demand_component to system_level_control section.

Section 6: Additional Supporting Information

Section 7: Test Results, if applicable

[genevievestarke]

I really like this functionality, thank you @elenya-grant !! I think it's much clearer what's happening in the code.
I don't have a problem with called the input demand_component since it needs to be a demand module to use system level control.
I don't think that we should throw an error for having upstream demand components in the system as long as it doesn't change the behavior of the system level control. I'm still working through why you would want a second demand component (so you can see how much of a steady-state demand you've met, maybe?).
It looks good to me!