Rename pipe and cable transport types to pipe_passthrough and cable_passthrough

[johnjasa]

Rename pipe and cable transport types to pipe_passthrough and cable_passthrough

Renames the protected transport type identifiers pipe to pipe_passthrough and cable to cable_passthrough to better indicate their pass-through (no-loss) nature. This makes the naming more specific and leaves room for future transport components that model actual losses.

Changes include:

• New files pipe_passthrough.py / cable_passthrough.py with renamed classes (PipePassthroughPerformanceModel, CablePassthroughPerformanceModel)
• Updated supported_models registry, reserved_techs, and no_cost_models
• Updated all 34 example YAML configs, tests, documentation, and notebooks

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:

• Step 1
• Step 2

Type of Reviewer Feedback Requested (on Draft PR)

Structural feedback:

Implementation feedback:

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 #560

[elenya-grant]

Thanks for making these changes to resolve this issue!

I hate to be this person but - I kinda don't like it (ah! even though I made the issue!)

The reason(s) I don't like it - at least don't like it coming in now (perhaps it'll make sense in the future) is that:

• typing cable and pipe are so easy compared to the _passthrough versions of them. I can already imagine many mini "ugh" moments in my future because I had a typo in _passthrough and it throws an error
• Any future transport models that include some performance aspect can be easily named something more verbose because they'd be (likely) used less often. Take for example, example 21_iron_examples, which use the GenericTransporterPerformanceModel for many different commodity streams, then these technologies are named things like crude_ore_transport or iron_ore_transport. For example, if we add a lossy cable model into H2I, then it's not crazy to name that technology in the tech config as electricity_transport or something.
• The use of "cable" and "pipe" ARE case-sensitive. Aka - if someone wants to use a lossy cable performance model and they name it "Cable" in their technology config - that would be OK
• We have "protected" name(s) in the finance model definition and likely other places in H2I - I think that having the very basic cable and pipe naming is ok since we've defined it as "protected"
• I think that these should only be renamed if we find that a certain cable or pipe model is being used more often than the pass-through lossless models OR re-evaluate immediately before a major release

[johnjasa]

Thanks for you comment, @elenya-grant, this is very helpful! @jaredthomas68, based on what Elenya said, what do you think? Do we need this PR or no thank you?

[jaredthomas68]

As I have given this more thought and the code has continued to progress, I lean towards not renaming them. I think it may be better to gradually transition to full tech models for transport with cost and performance models. The existing pipe and cable components could have a set cost and a simple efficiency that could be set to 0 and 1, respectively, to mimic the current behavior. Eventually it would be great to have transport models that can use start and end lat lon from two site specifications and open the way for routing (via reV perhaps). I think making the existing components slightly more general will be a better step forward than giving them pass through names.

[johnjasa]

Thanks @elenya-grant and @jaredthomas68! I'll close this PR as not relevant.