Wish-list of modeling fixes

[ekatef]

• Investigate a time resolution issue when defining p_nom_max for retrofitting generators. Currently, p_nom_max is determined as dE_diff[strength] * space_heat_demand.max(), where space_heat_demand is resampled according to time aggregation set in the model:

            demand = n.loads_t.p_set[name].resample(hours[0]).mean()
            space_heat_demand = demand * w_space[sec][node]

In case of hourly time resolution, that is an equivalent for taking a maximum of hourly demand values. However, in case of 24H resolution, that is a maximum of daily averages which is considerably lower as compared with hourly values. E.g. for January 2013 n.loads_t.p_set[name].max()/demand.max() is about
1.27

• Look into retrofit calculations for residential and service sectors. Currently, an update of hotmaps inputs leads to changes predominantly for the services, while the updated file contains compatible changes for the both sectors:

• Investigate costs updates for RES technologies in prepare_sector_network Currently, the capital costs are being updated for solar and onwind generators, but not for offwind ones. Not sure if it was intended.

• Check that urban and rural shares sum-up to the total value in population raster.

• Find a way to remove gas generators from n.generators in cross-sectoral model

[ekatef]

Update on the point 2 The changes have been tracked up to these lines:

https://github.com/PyPSA/pypsa-eur/blob/798a6b848112ad099aeb806e4741cd704b2e9e14/scripts/build_retro_cost.py#L948-L957

The area_reordered output is kind of asymmetric for residential (Appartment blocks, Multifamily houses, Single family- Terraced houses) and non-residential sectors (Education, Health, Hotels and Restaurants etc.). Looks like values have been updated for the area parameter (Heated area [Mm²]), while weights remained same. An example of how does it look:

Base case

residential

AT,AB,1990 - 1999,AT,residential,Appartment blocks,BUILDING,Area,Heated area [Mm²],0,0,4.68904929563393,Mm²,0.014607555307356832

services

AT,Education,2000 - 2010,AT,services,Education,BUILDING,Area,Heated area [Mm²],0,0,1.59,Mm²,0.013642096592907826

Hotmaps updated

residential

AT,AB,1990 - 1999,AT,residential,Appartment blocks,BUILDING,Area,Heated area [Mm²],0,0,7.239376912008641,Mm²,0.014607555307356832

services

AT,Education,2000 - 2010,AT,services,Education,BUILDING,Area,Heated area [Mm²],0,0,2.4547853017479486,Mm²,0.0133209339734084

[ekatef]

area_reordered is basically transferred as a result from prepare_building_stock_data() function, where weights are calculated by the following fragment:

    area_tot = area[["country", "sector", "value"]].groupby(["country", "sector"]).sum()
    area = pd.concat(
        [
            area,
            area.apply(
                lambda x: x.value / area_tot.value.loc[(x.country, x.sector)], axis=1
            ).rename("weight"),
        ],
        axis=1,
    )

Indeed, the issue is very minor, but would be great to trace it's source as understanding the buildings data may be crucial for going deeper into retrofitting scenarios.

[ekatef]

After investigating the data structure, it has been found:

1. the hotmaps update is a scaling of the areas data with differentiation by regions:

2. discrepancies for weight values described above are caused by slightly different bage definitions , in particular Post 2010 bage is missed in old hotmaps data for "subsector=='Other non-residential buildings'".

Long story short, the modeling workflow is perfectly alright, while anomalies after an update of hotmaps data are explained purely by data issues.