pypsa-meets-earth / pypsa-earth

PyPSA-Earth: A flexible Python-based open optimisation model to study energy system futures around the world.
https://pypsa-earth.readthedocs.io/en/latest/
225 stars 175 forks source link

Add the option to define, create and remove subregions #1046

Open virio-andreyana opened 3 months ago

virio-andreyana commented 3 months ago

Closes https://github.com/pypsa-meets-earth/pypsa-earth/issues/788 (the simulate subregion part)

subregion:
  define_subregion_gadm:
  drop_subregion: 

When creating subregions, its loads and existing renewable capacity will be empty. Hence it is recommended to use this additional tools as well

load_options:
  scale:
  subtitute_country_load:

estimate_renewable_capacities:
  custom_capacity:
    Offshore:
    Onshore:
    PV:

Here is an example of countries divided into subregions:

subregion:
  define_subregion_gadm:
    Java-Bali/ID:
      ID: [2,4,7,9,10,11,33]
    Peninsular/MY:
      MY: [1,2,3,4,6,7,8,9,10,11,12,15,16]
    Papua/ID:
      ID: [22,23]
    Sarawak/MY:
      MY: [14]
    Maluku/ID:
      ID: [18,19]
    Sulawesi/ID:
      ID: [6,25,26,27,28,29]
    Sabah/MY:
      MY: [5,13]
    Kalimantan/ID:
      ID: [12,13,14,34,35]
    Nusa-Tenggara/ID:
      ID: [20,21]
    Sumatra/ID:
      ID: [1,3,5,8,16,17,24,30,31,32]

  drop_subregion: ["ID","MY"]

grafik

Changes proposed in this Pull Request

in snakemake

in build_shapes:

in add_electricity:

in build_demand_profiles:

in build_powerplants:

in simplify_network:

in test/config.custom.yaml

note:

Checklist

davide-f commented 3 months ago

The approach is very interesting and it accounts for the problem of the demand rescaling that the previous formulation had. This PR not only addresses the issue of the subregions but increases significantly the flexibility in defining the regions. The approach is interesting, though I'm wondering if there may be easier approaches to do the same. An approach crossed my mind is to revise the use of the alternative_clustering and:

  1. disentangle the use of custom shapes in build_bus_regions from the ones used in cluster_network. This may require a little revision on the gadm_shapes parameter of the two approaches, which in principle can be any shape, not necessarily the gadm one
  2. allow the automatic creation of a custom clustering process in the cluster_network phase that drops/merges the subregions of the gadm_shapes given the desired interests.

What do you think? We can mention it also with the others during the meeting.

Multiple opinions by other developers are highly desiderable too

virio-andreyana commented 3 months ago

Interesting @davide-f! Most of the challange this draft made really happens in the process of turning base.nc into elec.nc (load adjustment, renewables, powerplant) because they specifically need the 2_country_code. Finding the correct settings for all of the subregion is more of a hassle that I would imagine people like to have

However, I would like for the subregion to be defined before elec_s.nc because thats where the backbone algorithm takes place. Defining the subregion starting from cluster_network.py phase would cause back my original issue.

A good compromise maybe is the way similar to how augmented_line_connections.py is conducted. Have a snakefile if function where if subregions are defined, all the buses, lines, and generators within that region countries are renamed. This can take place after elec.nc but before elec_s.nc. That way, you have the advantage of both worlds.

My main concern is the way in which the renewables in offshore regions are impacted. The current method also cuts the eez zone into subregions as well. How accurate is the voronoi in build_renewables.py so that it didn't go too far or too short compared to the current results.

That's my 2 cents. I'll see you in the meeting.

grafik

davide-f commented 2 months ago

However, I would like for the subregion to be defined before elec_s.nc because thats where the backbone algorithm takes place. Defining the subregion starting from cluster_network.py phase would cause back my original issue.

Could you remind what are the problems in the simplifying you were experiencing?

A good compromise maybe is the way similar to how augmented_line_connections.py is conducted. Have a snakefile if function where if subregions are defined, all the buses, lines, and generators within that region countries are renamed. This can take place after elec.nc but before elec_s.nc. That way, you have the advantage of both worlds.

My main concern is the way in which the renewables in offshore regions are impacted. The current method also cuts the eez zone into subregions as well. How accurate is the voronoi in build_renewables.py so that it didn't go too far or too short compared to the current results.

Mmm I need to better explore this; we are aware of problems in the eez, but I didn't get well how this PR relates to that unfortunately