Removed hard-coded logic for electrolyzer replacement schedule

[elenya-grant]

Removed hard-coded logic for electrolyzer replacement schedule

Removed the hard-coded logic within the finance models and H2IntegrateModel that was specific to connecting the replacement schedule from the technology to a finance model if a technology name included "electrolyzer". Now - the replacement schedule is passed to the finance models for all technologies.

Note: This is ready for an in-depth review, but I have noted some specific questions for reviewers in Section 2 under "Type of Reviewer Feedback Requested"

Since technology-specific finance models do not expect the electrolyzer replacement schedule to be connected, there is some added logic to handle tech-specific finance models (before, the logic was not explicit and relied on whether the commodity_stream for a finance subgroup was None. This logic has been replaced with more explicit logic. Additionally, since this logic is handled/defined at the subgroup-level, it is not possible to have a finance subgroup that includes finance_groups that have a mix of technology-specific and finance specific models (this has always been the case). Further information on this is described in Section 5. But - I added in an error message to catch this case if it were to pop up.

This also required updating the feedstock cost model to output a replacement schedule. An alternative to adding this output to the feedstock cost model would be to add in logic to connect_technologies that checks if 'feedstock' is in the technology name (this alternative approach was the route taken for transport technologies).

I also added a documentation page about the technology naming convention in H2I to communicate what naming convention is requires so that the logic within H2I functions as expected.

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

• Add test that error is thrown if combining technology-specific finance model and system-level finance model in a finance subgroup.

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:

Implementation feedback:

• Should the feedstock cost model have an output of replacement_schedule or should we introduce logic into connect_technologies so that technologies with feedstock in the name do not have the replacement schedule passed to the finance model? This logic would maybe have to be duplicated in the finance models if so. I like the current implementation since it reduces the amount of naming-specific logic in the code base.
• Similar question to above, but relating to the transport models. The logic for the transport model is to not connect the replacement schedule to the finance model if "transport" is in the tech name. Since theres only two transport models that can be defined in the tech config, this felt like the best way to do it (rather than add replacement_schedule as an output to both transport models).

Other feedback:

• Should the naming convention for the electricity producing techs and the naming convention for default commodities streams (defined in the default_techs_to_commodities dictionary in H2IntegrateModel.create_finance_model()) be described in the docs/user_guide/expected_naming_convention.md doc page?

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 has been updated to describe the changes made in this PR

Section 3: Related Issues

This is somewhat related to Issue #485

Section 4: Impacted Areas of the Software

Section 4.1: New Files

• docs/user_guide/expected_naming_convention.md: new doc page that explains what naming convention is needed for technologies in H2I so that it functions properly

Section 4.2: Modified Files

• h2integrate/finances/profast_base.py - ProFastBase: removed logic around electrolyzer replacement schedule, added input for all replacement schedule for all technologies, and updated replacement schedule calculation to use inputs['replacement_schedule_{tech}'] instead of time between replacement.
• examples/08_wind_electrolyzer/user_finance_model/simple_lco.py: added input of technology replacement schedules
• h2integrate/finances/numpy_financial_npv.py - NumpyFinancialNPV: removed logic around electrolyzer replacement schedule, added input for all replacement schedule for all technologies, and updated replacement schedule calculation to use inputs['replacement_schedule_{tech}'] instead of time between replacement.
• h2integrate/core/feedstocks.py: added replacement_schedule output to FeedstockCostModel
• h2integrate/core/h2integrate_model.py:
  • create_finance_model():
    • added system_finance_model key to the finance_subgroups dictionary. This is a boolean that is True if the finance model is system-level and False if the finance model is tech-specific.
    • added a counter variable n_tech_finances_in_group that is equal to the number of technology-specific finance models within a finance subgroup. This is used so that later on, we can throw an error message if someone has a mix of technology-specific finance models and system-level finance models within one finance subgroup.
  • connect_technologies()
    • Removed elif statement for elif "storage" in source_tech and elif "storage" in dest_tech because it was the same logic that is done in the else statement and was therefore unnecessary.
    • Connecting techs to finance models: Replaced logic of if commodity_stream is not None to if is_system_finance_model which is pulled from the finance_subgroups attribute that is created in create_finance_model()
    • Connecting techs to finance models: Added logic when looping through technologies to connect technology replacement schedule to the finance model if is_system_finance_model is True and tech_name does not include "transport".
    • Connecting techs to finance models: Added a check if the technology is 'cable' or 'pipe' since those are protected transport item names. This change was not necessary for this PR, but if someone had put 'cable' or 'pipe' in the technologies for a finance subgroup, there would've been an error (but now there won't be an error! yay!)
• h2integrate/core/test/test_framework.py: added new test, test_invalid_finance_group_combination, for error message added

Section 5: Additional Supporting Information

it is not possible to have a finance subgroup that includes finance_groups that have a mix of technology-specific and finance specific models.

Suppose we have a technology-specific finance model for the steel technology and a system-level finance model named profast_model (as is the case in Example 1). If a user tried to run both of these finance models as shown below:

finance_subgroups:
  steel:
    commodity: steel
    finance_groups: ['steel', 'profast_model']
    technologies: [steel]

there would be an error (this PR now includes a more verbose error than the error that would've occurred when trying to run H2I).

The user should instead define two finance subgroups, one per finance model.

finance_subgroups:
  steel:
    commodity: steel
    finance_groups: ['steel']
    technologies: [steel]
  steel_profast:
    commodity: steel
    finance_groups: ['profast_model']
    technologies: [steel]

This error does not come up if finance models defined in the finance_groups for a specific finance subgroup are either all tech-specific finance models OR all system-level finance models (see example 8).

Section 6: Test Results, if applicable

[jaredthomas68]

This looks pretty good to me. Thanks for continuing to generalize and reduce tech-specific logic. My main thoughts are as follows:

1. Let's allow for costs for transport techs (needed in current project)
2. I don't love having costs or replacement schedule in feedstocks, but if the user does not need to do anything with them then I think it is ok if keeps things more general.

[jaredthomas68]

Looks good to me now

[johnjasa]

Thanks for this PR! It's really nice to see things come together in a standardized way. I pushed up some changes, have some non-blocking questions, and have bigger picture questions for you:

Given where we're at with the finance models, would it make sense to adapt the steel and ammonia examples to not use tech-specific finance models? We initially coded it this way to match the prior GreenHEART implementation, but I don't think it's strictly necessary. If we do that, are tech specific finance models still useful? I'm wondering if we can simplify the codebase and the internal logic by removing that capability, but I wouldn't want to remove it if you see it as a worthwhile capability. I imagine it is worthwhile, but more want to get your take on it given how much you've been working in and around the finance models.

[johnjasa]

Mostly for my curiosity, why is this part needed? Are you running this script outside of the directory? Is the limitation that we need to be in a certain directory to run parts of H2I well-documented in an issue?

[elenya-grant]

not necessary but most of the examples only work if we change the cwd to the example folder. Aka - most examples are set-up to be run like:

cd examples/01_onshore_steel_mn
python run_onshore_steel_mn.py

That's why all the tests in test_all_examples change the cwd to the folder of the example its testing

[johnjasa]

Got it. I guess more of my question is should we change the behavior of the examples so that this is not necessary? And to make an issue to track that if it is the case. I couldn't find one right off. If you don't think it's helpful to change this behavior, please say so!

[elenya-grant]

I can revert this change - I just made it because I was using that example to debug and was sick of restoring the changes I make to the file

[kbrunik]

I vote revert and make an issue about not being able to run examples unless in the cwd!

[johnjasa]

Thanks team, no need to revert, I've made an issue here: #563

[johnjasa]

A point I'm noting here and it's relevant in a few places in the code: in some locations you say "system finance model" and in others "general finance model". Are these the same thing? I believe so. I'd suggest being consistent on the naming, and maybe even suggest using is_system_finance_model as the key (add is_) to make it clear it's a boolean, not an object or something else

[elenya-grant]

yes - system finance model and general finance model are the same. I can update the variables and comments to all use system finance model (unless you prefer general over system) and I'll update that new key to be "is_system_finance_model" instead.

[johnjasa]

I like system finance model, thanks for the bool change too!

[elenya-grant]

this is done!