Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transmission lines vs. transfer corridors #122

Open
mfripp opened this issue Aug 13, 2019 · 2 comments
Open

Transmission lines vs. transfer corridors #122

mfripp opened this issue Aug 13, 2019 · 2 comments
Assignees

Comments

@mfripp
Copy link
Member

mfripp commented Aug 13, 2019

In switch_model.transmission.transport, we generally refer to entities called "transmission lines". These are actually transfer corridors: aggregated transfer capacity between two zones, calculated from the capabilities of the underlying network. Users often estimate this as a derated sum of the ratings of the transmission lines connecting these zones, but there are other ways to do it (e.g., consult the WECC Path Rating Catalog). At any rate, these are definitely not transmission lines, and it could bug electrical engineers to hear them called that. So we should probably rename them as transfer corridors, transmission corridors, transfer paths or similar. That will also keep the name space open for actual transmission line modeling later.

It would also be helpful to add bidirectional ratings for these paths (at least for initial capacity, and possibly different costs to update the capacity in each direction, based on a detailed transmission study). This reflects the fact that transfer paths often have different ratings in each direction.

@josiahjohnston
Copy link
Contributor

Ha! This asymmetry issue came up for me a few weeks back. I started looking into implementing it, but my client thought a pathway update might correct the issue. In the handful of datasets I examined before implementing it this way (including WECC), the asymmetries were nominal enough to be attributable to rounding errors. The bi-directionality of Switch 1.0 had also caused many of us significant grief over the years, so dropping that seemed like a nice way forward.

Do you have a clear example of very different capacities and costs for either direction?

I don't have a strong opinion on nomenclature shift to be more precise; the pros & cons in my mind seem fairly balanced, so I'm happy to defer my vote on that. It's up to users whether each zone is a large region or a single bus, so these could represent transmission corridors or single lines. Similarly, a generation project may be a single generator unit or a "virtual plant" that is an aggregation of many different generation plants.

Anyway, "Transfer Paths" seems fine to me and sufficient ambiguous to handle both use cases. It's probably worth shopping around a little to make sure it's not confusing. @bmaluenda Do you know what language PLEXOS uses for connections in a transport model?

@bmaluenda
Copy link
Member

I'm not keen on changing the nomenclature. Multiple users (me included) use the Transmission Line objects to model actual lines. The flow model is simply a transport model instead of a DC or AC power flow, but it doesn't change the fact that a line is being represented. I don't think most other users -who use the Trasmission Line objects to model interfaces between zones- would be bothered with the fact of using a "transmission line" obejct to represent a bunch of lines. Josiah's example shows this: many users use the generation unit object to represent a bunch of units (either a plant, a virtual plant, or aggregated capacity in a zone).

All other capacity expansion models I know of use "transmission line" or "circuit" as names. Plexos is a weird case: the user defines Tx lines between nodes, defines zones that group nodes, and then he/she decides whether Tx flow will be modeled nodally or zonally. Plexos then formulates a DC power flow in the former case, and a transport model in the latter.

Maybe the name change would make sense for certain reasons now, but I believe eventually Switch should have the capability to formulate DC power flows. In such case, "transmission lines" would again make more sense.

Regarding bi-directionality: I've found this capability to be useful to model user-defined operative constraints, usually related to security. I ended up writing a couple of custom constraints to restrict flow in certain directions in certain lines in my Chilean models to represent the N-1 security criterion that the ISO uses for operations. I guess this could be useful for any other system with N-X security criteria. Maybe this is also the case with international interconnections? Though I have no experience in that topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants