calliope-project / sector-coupled-euro-calliope Goto Github PK

Different NUTS years lead to different shapefiles associated with different datasets. This is currently dealt with by having a mapping table to define which NUTS regions in each NUTS year correspond to which of the 'eurospores' 98 regions. A better approach would be to combine all eurostat data with corresponding NUTS shapefiles early on, and store them as rasters. Then, any euro-calliope regionalisation can mask the datasets without needing a mapping table.

Some countries have a non-negligible incineration of waste. This should be included in the model, and could be done in one of a few ways:

1. Include waste as a carrier that can be used in place of e.g. biofuel in CHPs
2. include waste in the biofuel carrier stream
3. Remove contribution of waste incinerators from demand timeseries, based on current production of heat and electricity from waste. This would need to be a flat line, since we don't have timeseries data

At any rate, we would include only current national incineration rates, on the assumption that a. waste streams won't increase substantially relative to population, and b. that countries who are against waste incineration will remain as such while those who are for it have already reached the limit on how much they are willing/able to incinerate.

The When2Heat dataset is a heat demand dataset that can be found on OPSD. We use some of their scripts to produce heat demand. We don't depend entirely on their scripts, since they can only handle national shapefiles and are limited in scope. To get these scripts, the script repository is cloned as a rule. This should be updated to do one of the following:

a. clone a specific commit hash, to ensure some degree of reproducibility
b. re-implement the scripts locally (I think the licence is sufficiently permissive to allow this)
c. request/submit upstream changes to When2Heat so that it works for all our requirements, rather than only a subset, and can be installed via pip/conda-forge.

Currently only builds at 'eurospores' resolution, i.e. 98 regions. Needs disaggregation rules to either ignore national subdivision or aggregate all national units.

II find the variable name a bit confusing. A reference temperature to me would be a static value that you compare observations against. I think, however, that reference_temperature is a time series here. Just temperature would be clearer in my opinion

For instance, at the moment it is possible to have 'water_heat' and 'space_heat' as separate carriers or aggregated into one carrier ('heat'). The workflow currently works with all, but will break on anything other than 'heat' when filling templates in the euro-calliope submodule. This breaking change was introduced in one of the two latest commits, to push through a rapid update to how heat techs are represented.

Anyway, the method for handling these different carriers is quite messy and could do with cleaning in general.

Re-runs seem to generate different annual demands than those in the pre-builts of the model. Most of these are marginal, but in some cases they can be significant (>10%, so far I only see these in heat and bau_electricity demands).

This generally affects the following:

• space heat
• cooking
• water
• industry specific demands (methane, methanol, diesel, bau_electricity...)

I suspect issue #9 is one of the culprits, at least on the heat side of things. No idea on what is causing industry demands to change.

Config could do with a schema (true for all workflows related to euro-calliope) and there could do with being more tests for these workflows. There are assertions in files, which will lead to the workflow breaking if there is data consistency, but they are hardly comprehensive.

Some countries still plan on having nuclear power up to 2050 (namely FR, CZ, and UK), which should be put in as a fixed capacity to meet electricity demand (with a small modulation capability). The exact 2050 quantity depends on the data source. Based on current lit review:

The two main functions in this script (get_demand_profiles and get_heat_profiles) have very similar names. The situation gets more confusing as "heat demand" is also a thing. It seems that get_demand_profiles loads and outputs some parameters (a "demand profile shape") while get_heat_profiles actually calculates a set of time series. It probably all makes sense somehow, but would either need better documentation and/or clearer names for me to understand easily.

If you don't want to model a particular subsector, only a minimal set of data processing related to that subsector should be undertaken. At the moment the rules annual_subnational_demand and update_electricity_with_other_sectors are the most troublesome w.r.t. decoupling, since expect all sectors to be involved. The reason for current coupling is two-fold:

1. Similar datasets and spatial operations are used to disaggregate national data to subnational units; separating them might lead to lots of time spent doing the same operation multiple times.
2. Each subsector uses some amount of electricity at present, which is removed from the OPSD electricity demand profile. This is undertaken all in one go at the moment, since they all touch the same output file.

What does site-wide mean? I find it difficult to understand what is going on, for example, in this line

wind = weather_df.xs('wind_speed', level='dataset', axis=1).mean()

because I have no idea what axis=1 is and I haven't found a way to interact with the data to check myself.

At the moment, solar thermal is planned for inclusion as a heat provider, but we have no rules to generate the timeseries. This requires using a modified version of GSEE to combine direct and diffuse irradiation for evacuated tube and flat plate collectors.