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

Add ability to build network for individual/groups of states #292

Open
ktehranchi opened this issue Apr 22, 2024 · 8 comments · Fixed by #420
Open

Add ability to build network for individual/groups of states #292

ktehranchi opened this issue Apr 22, 2024 · 8 comments · Fixed by #420
Assignees
Labels
enhancement New feature or request

Comments

@ktehranchi
Copy link
Collaborator

Feature Request

For regional planning it would be useful to implement a feature that builds individual states rather than entire interconnections.

Suggested Solution

  • Filter states in build_base_network, build_shapes, and build_bus_regions
  • Add electricity would need to only add plants that are located in the states

Additional Info

No response

@ktehranchi ktehranchi added the enhancement New feature or request label Apr 22, 2024
@ktehranchi ktehranchi self-assigned this Apr 30, 2024
@jpvelez
Copy link

jpvelez commented May 3, 2024

Besides filters, wouldn't we need some way to configure what level of clustering to apply to the grid outside the state?

@ktehranchi
Copy link
Collaborator Author

ktehranchi commented May 3, 2024

Yep- I'm doing some research now on which style of external node representation makes the most sense for your use-case. Stand-by while I do some reading and gather thoughts from my colleagues who do more IRP modeling.

These are the three options:

  1. Split off a State completely from the rest of the system- where external nodes can be bought from / sold to at a defined market price
  2. Split off a State + its adjacent neighbors- where those adjacent neighbors can still have renewable resource be built-in and exported to the given State. But not external market prices are defined.
  3. Model entire interconnect but aggregate all non-studied nodes together. This way all renewable resource across the interconnect are represented, and could either allow build or could be restricted.

@ktehranchi
Copy link
Collaborator Author

So, all three options seem useful for modeling different states/scenarios. But I think a starting point would be option 1:

Split off a State completely from the rest of the system- where external nodes can be bought from / sold to at a defined market price

For instance, here is a map of the transmission topology used by Pacificorp for their 2023 IRP. In this case, the transmission topology allows for splitting off user-selected regions (blue and orange bubbles). The yellow bubbles represent pricing nodes that would be exogenously defined.
image

@ktehranchi
Copy link
Collaborator Author

I can see two routes for getting this done:

First Option
Filtering out regions from the start in build_base_network, and editing all downstream functions to ensure demand, generators, renewable profiles, GIS shapes are modified accordingly to not add incorrect loads and generators. Work involved:

  1. Adding a function at the end of build_base_network which removes all buses, lines, transformers in build_base_network.
  2. Add function to calculate Load Allocation Factors (LAF) for correctly distributing EIA930 data similar to how we do it for EFS LAFs in build_base_network.
  3. Modifying build_shapes to only build the region of interest shapes.
  4. Modifying add_electricity to only add generators in the region of interest
  5. Modify build_demand for all read strategies (EIA, EFS, EULP).

Pros: Faster run-time for build_renewable_profiles. Smaller network size throughout workflow.
Cons: Lots of code to update. Missing out on adding options for including external node renewable profiles and transmission capacity

Second Option
Filter out regions after cluster_network. Work involved:

  1. Write script at the end of cluster_network to either remove buses, lines, loads, generators, links which are connected to external regions.
  2. Option to add a link to user defined external pricing nodes at a given marginal cost

Pros: Avoid many code changes upstream in the workflow. Allows more flexibility for including information on external renewable profiles.
Con: Longer runtime since you have to build the entire network.

Thoughts: My hunch is that option two is the way to go even if the workflow would take longer to build.

@jpvelez
Copy link

jpvelez commented May 9, 2024

Thanks, this is super useful!

Another consideration: does either option make it easier to add modeling approaches 2 (Split off a State + its adjacent neighbors) and 3 (Model entire interconnect but aggregate all non-studied nodes together) later—assuming we want to do that?

@ktehranchi
Copy link
Collaborator Author

good Q: option 2 will be compatible with modeling approaches 2 and 3.

2: Split off a State + its adjacent neighbors- where those adjacent neighbors can still have renewable resource be built-in and exported to the given State. But not external market prices are defined.

Is an extension of 1, and we would accept a list for filter regions instead of just one region.

3: Model entire interconnect but aggregate all non-studied nodes together. This way all renewable resource across the interconnect are represented, and could either allow build or could be restricted.

This is a quick change (<1 line of code). We would just rename the regions which are external into "external regions"

@jpvelez
Copy link

jpvelez commented Jun 12, 2024

Just wanted to flag a potential resource: a study of New York State done by Vibrant Clean Energy

They say:

Existing transmission corridors between New York and neighboring states are modeled as
imports and exports with energy prices provided by a background modeling scenario (“CEDER”).
6

And this is the background modeling scenario: https://www.vibrantcleanenergy.com/wp-content/uploads/2020/12/WhyDERs_TR_Final.pdf

@ktehranchi
Copy link
Collaborator Author

ktehranchi commented Sep 23, 2024

Working on this now!

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

Successfully merging a pull request may close this issue.

2 participants