PyPSA / pypsa-eur

PyPSA-Eur: A Sector-Coupled Open Optimisation Model of the European Energy System
https://pypsa-eur.readthedocs.io/
323 stars 225 forks source link

Time aggregation: can't have two different aggregations between elec and sectors #1277

Open cerealice opened 1 week ago

cerealice commented 1 week ago

Checklist

Describe the Bug

I believe there are some issues with time aggregation. If you run the sectorial model with two different resolution for electricity and sectors it will create the csv for the snapshot weightings (in "resources") in the prepare_network rule, then it is not rerun in prepare_sector_network, thus taking the values from that csv. Maybe there is no need to separate the two time aggregations

image

PS: thanks @p-glaum for the help with this

koen-vg commented 2 days ago

Hi. Indeed it looks like with the current implementation, it might not be possible to set one resolution for electricity-only networks, and another resolution for sector-coupled networks. Implementation-wise, networks are time-aggregated according to resolution_elec in prepare_network.py, and time-aggregated separately according to resolution_sector in time_aggregation.py and prepare_sector_network.py.

However, I cannot see that snapshot weightings are exported in the prepare_network.py script; if I'm missing something, could you point me to the specific location in the source code where this is happening?

I do agree that it seems a bit unnecessary to have two completely separate paths for time aggregation. However, it seems like a bit of a hairy issue to resolve cleanly without making some changes to the rest of the workflow. My observations:

  1. Ideally, we would have a single place in the code where time-aggregation happens, and a single point of configuration. I don't think there should be any reason for supporting different time-resolutions in elec- and sector-networks within a single configuration? (Happy to be contradicted on this point if anyone has really good use-cases for this.)
  2. Currently the implementation isn't in one place, because time-aggregation needs to happen after the prepare_network rule for sector-coupled networks (because time-varying load profiles, capacity factors, etc. are added to network in hourly resolution in prepare_sector_network).
  3. One complicating factor is that the code doesn't really "know" if a network is going to be electricity-only or sector-coupled by the time it gets to prepare_network. If we could know that, prepare_network could decide to time-aggregate for electricity-only networks but not for sector-coupled networks. That would make different time resolution configs for elec/sector networks possible.
  4. Maybe a cleaner approach would be to move where time-aggregation happens. One option is maybe to apply time-aggregation only in solve_network.py, right before solving. However, I can see some potential issues with myopic foresight optimisation there (where components from solved and unsolved networks are combined. Another option is to introduce a new rule which would run after prepare_network and prepare_sector_network but _beforesolve_network, which would only apply time aggregation. This rule could probably be made to work for both electricity-only and sector-coupled networks. (It should still run separately from the current time_aggregation rule, because time segmentation has to be consistent between networks at different planning horizons for myopic foresight optimisation.)

At the very least, we could document a little better right now that different time resolutions for elec-only and sector-coupled networks aren't supported.

If others think it's a reasonable idea, I'd be happy to give something like 4. (above) a shot and see if I can harmonise how time aggregation is dealt with a little. Thoughts?