switch-model / switch

A Modern Platform for Planning High-Renewable Power Systems
http://switch-model.org/
Other
130 stars 85 forks source link

Transmission lines vs. transfer corridors #122

Open mfripp opened 5 years ago

mfripp commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.