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

[cerealice]

Checklist

• I am using the current master branch
• I am running on an up-to-date pypsa-eur environment. Update via conda env update -f envs/environment.yaml.

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

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

[koen-vg]

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 _before solve_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?

[koen-vg]

Just to add one or two more reflections on this issue, #1278 is the kind of thing that happens when users try setting resolution_elec and resolution_sector to different values; that's obviously frustrating. Right now we just trust users to read the documentation really carefully and not run into this erroneous configuration.

Thinking about it again, I gather that the concrete, practical reason for having two configuration options for this is precisely because prepare_network.py essentially has to "decide" whether or not to temporally aggregate the network depending on whether it's going to be an electricity-only network or a sector-coupled network. In that sense, resolution_elec/resolution_sector is almost just a poor proxy for a configuration option which specified whether we are working with an electricity-only or sector-coupled network.

In my opinion, it might not be a bad idea to introduce a new configuration option like mode: "elec"/"sector" or sector_coupled: true/false, a little bit like the existing foresight option. Just like to me it seems like there is no reason to support elec/sector networks with different time resolutions within the same configuration, it actually also seems like there should be no reason to support a single configuration file being used for both electricity-only and sector-coupled optimisations.

If such an option was introduced, the time resolution configuration could be simplified to a single option, and the prepare_network rule could be told to time-aggregate or not depending on the sector-coupled option. One can also imagine that this option could be helpful, if only for readability-purposes, in solve_network, since some constraints only make sense or are implemented correctly for elec/sector networks.