Resource Classes: problem implementing capacity limits

[Parisra]

The current implementation of resource classes causes a problem when more than one technology using the same renewable resources is included in the model. For example, if we use a 39-node network and have 5 resource classes for solar and solar-hsat (both of which are PV technologies that need to share the available land), the regions for Spain/Italy would look something like below:

As expected, the regions with the highest resource are in the south for both technologies. However, the constraint for p_nom_max is implemented at a nodal level (across the whole Spain or Italy in this case as we have 39 nodes), not based on the regions shown in the image.

pypsa-eur/scripts/solve_network.py

Line 191 in a1dee3f

def add_solar_potential_constraints(n: pypsa.Network, config: dict) -> None:

Therefore, to maximise profit, the system will choose to maximise the installed capacity of both technologies in the 'yellow' regions, which is basically using the land in the region twice as much as it should be allowed.

A simple numerical example (numbers illustrative):
Solar potential for Spain is : 50 GW,
potential for yellow region is 10 GW.
Currently, the model can install 10 GW solar and 8 GW solar-hsat (since it has higher land use) in the yellow region, because the total installed capacity is still well below 50 GW.

This issue also arises if we choose to include 2 additional types of wind turbine in the model (which was one of the goals of creating resource classes :#290 (comment)) :

.

One solution is to change the constraint so that the overlapping regions are accounted for, but I have not been able to find a way to do this. Therefore, the changes below are proposed:

1. The resource classes should be created based on solar radiation and wind speed. This ensures that all technologies using solar/wind share identical regions.
2. The average capacity factors and maximum potential per region are then calculated for and the rest is the same as the current workflow.

If this solution is feasible, I’d be happy to start implementing it and open a pull request in the coming weeks.