Removed remaining naming dependencies

[johnjasa]

Use model class instead of tech name to skip no-cost technologies in finance connections

Previously, the finance connection logic in connect_technologies used string-based checks on the technology name (e.g., "splitter" in tech_name, tech_name == "cable") to decide which technologies to skip when connecting CapEx/OpEx/VarOpEx to finance subgroups. This was fragile because renaming a technology could silently break the skip logic.

Now the code looks up each technology's performance_model.model from the tech config and checks it against a set of known no-cost model classes. This decouples the behavior from naming conventions.

no_cost_models = {
    "GenericSplitterPerformanceModel",
    "GenericCombinerPerformanceModel",
    "GasStreamCombinerPerformanceModel",
    "CablePerformanceModel",
    "PipePerformanceModel",
}

for tech_name in tech_configs.keys():
    perf_model = tech_configs[tech_name].get("performance_model").get("model")
    if perf_model in no_cost_models:
        continue

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: 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 3: Related Issues

Fully resolved #374

Section 4: Impacted Areas of the Software

Section 4.1: New Files

N/A

Section 4.2: Modified Files

• h2integrate/core/h2integrate_model.py
  • connect_technologies: Replaced name-based "splitter"/"combiner"/"cable"/"pipe" string checks with a lookup against no_cost_models using the technology's configured model class.

Section 5: Additional Supporting Information

N/A

Section 6: Test Results, if applicable

N/A

Section 7 (Optional): New Model Checklist

N/A

[elenya-grant]

Thanks for this PR John! I had a few small questions but thanks for making this PR to finally remove all naming-specific logic!

[elenya-grant]

would using dictionary defaults prevent issues in case a technology (maybe not one that exists now) has a cost model but not a performance model?

perf_model = tech_configs[tech_name].get("performance_model", {}).get("model", None)

[johnjasa]

Good consideration. This would avoid issues in the future for models that don't necessarily exist now, but it may also obfuscate the issue. Or at least I'd want to catch it sooner than this (connection time). So based on this comment, I've added required: [performance_model] to the tech_schema.yaml to require models there and do the checking.

[elenya-grant]

Okay - I think requiring the performance model makes sense for now (I was spooked when you said performance and cost model since splitters and combiners can be defined in the tech config but don't have an associated cost model). Thanks for explaining!

[johnjasa]

Yeah, I underthought it at first and thought we could require both but you're exactly right!

[elenya-grant]

could you extend this comment to mention that these models are like "internal models" so that's why they don't contribute to the costs for the finance modeling?

[elenya-grant]

why did you put these in h2integrate_model.py instead of supported_models.py? I almost think that I'd be nice to have these in supported models so its a bit more "upfront" than buried within a class method but I'd love to hear your reasoning

[johnjasa]

I love your suggestion! That makes total sense. I didn't have a great reason for putting them here; I think with your suggestion, we'll also have a good setup for other similar groupings. Will change it now, thank you!

[elenya-grant]

Yay! Love that this file can be removed!

[elenya-grant]

Thanks for making these changes!