Refactor buildings ces tree#2331
Conversation
ricardarosemann
left a comment
ricardarosemann
left a comment
There was a problem hiding this comment.
Thanks, looks good - I only think that we can probably delete/skip some of the things that you have added or modified. I'm happy to help if you have questions on this.
| appliances_light_elec_fe "buildings appliances and lighting electricity" | ||
| appliances_light_natgas_fe "buildings appliances and lighting natural gas" | ||
| appliances_light_petrol_fe "buildings appliances and lighting petrol" | ||
| cooking_biomod_fe "buildings cooking modern biomass" | ||
| cooking_biotrad_fe "buildings cooking traditional biomass" | ||
| cooking_coal_fe "buildings cooking coal" | ||
| cooking_elec_fe "buildings cooking electricity" | ||
| cooking_natgas_fe "buildings cooking natural gas" | ||
| cooking_petrol_fe "buildings cooking petrol" | ||
| ict_elec_fe "buildings information communication technology electricity" | ||
| space_cooling_elec_fe "buildings space cooling electricity" | ||
| space_cooling_heat_fe "buildings space cooling district heat" | ||
| space_heating_biomod_fe "buildings space heating modern biomass" | ||
| space_heating_biotrad_fe "buildings space heating traditional biomass" | ||
| space_heating_coal_fe "buildings space heating coal" | ||
| space_heating_elecHP_fe "buildings space heating electricity heat pump" | ||
| space_heating_elecRH_fe "buildings space heating electricity resistive heating" | ||
| space_heating_heat_fe "buildings space heating district heat" | ||
| space_heating_natgas_fe "buildings space heating natural gas" | ||
| space_heating_petrol_fe "buildings space heating petrol" | ||
| water_heating_biomod_fe "buildings water heating modern biomass" | ||
| water_heating_biotrad_fe "buildings water heating traditional biomass" | ||
| water_heating_coal_fe "buildings water heating coal" | ||
| water_heating_elecHP_fe "buildings water heating electricity heat pump" | ||
| water_heating_elecRH_fe "buildings water heating electricity resistive heating" | ||
| water_heating_heat_fe "buildings water heating district heat" | ||
| water_heating_natgas_fe "buildings water heating natural gas" | ||
| water_heating_petrol_fe "buildings water heating petrol" |
There was a problem hiding this comment.
I'm pretty certain we don't need this here. The dimension of the object that the buildings input data is read into is all_in not all_enty. So if we only need these entries for reporting, they should only exist in all_in.
There was a problem hiding this comment.
I tried running the model without these entries in all_enty and it turns out that they're used as indices in vm_emiFgas(ttot,all_regi,all_enty) and GAMS throws domain violation errors during compilation when removing them.
There was a problem hiding this comment.
That's very weird - vm_emiFgas should only contain entries of all_enty related to F-gases. Maybe you can check the file core/input/f_emiFgas.cs4r in your runs (which is where vm_emiFgas gets its data from), this should not contain any of our variables.
If it turns out we need the detailed edgebuildings variables in all_enty for some reasons related to buildings or at least FE demand, fair enough, but this makes no sense, so I think we should take the time to investigate.
There was a problem hiding this comment.
I was also a bit puzzled by that. I tried to reproduce the error but can't and core/input/f_emiFgas.cs4r does not contain any buildings-related variables as expected so should be all good.
hagento
force-pushed
the
buildingsCEStree
branch
2 times, most recently
from
2087f25 to
4c2d12e
Compare
ricardarosemann
left a comment
ricardarosemann
left a comment
There was a problem hiding this comment.
In general, it looks all good, thanks! I also checked the compScens and they look fine to me, too. I only noticed one thing: In SSP2 there is a notable difference in liquids demand for transport in the NPi-scenario. I don't quite see how this could be related to your changes, so it might make sense to briefly verify whether this deviation can come from somewhere else - maybe input data differs between the "ces"-scenario and the default one?
Apart from that you definitely need to put a new input revision and possibly a new CES commit hash. My take is that you also need to generate new input data and recalibrate, but please check on this with Lavinia if you're unsure.
| cfg$inputRevision <- "7.95" | ||
| cfg$inputRevision <- "7.91ces" | ||
|
|
||
| #### Current CES parameter and GDX revision (commit hash) #### | ||
| cfg$CESandGDXversion <- "dec24b712ce59db95bb4385ba71ec9a4cd921041" |
There was a problem hiding this comment.
For the final merge you still need to put an up to date revision without a development suffix and make sure that the CES commit hash lies in the group-wide calibration repo and not in a local one (which I haven't checked). This means in my view you'd need to regenerate input data and recalibrate - if you want to skip this, please check with Lavinia first.
|
Thanks for your comments @ricardarosemann. I wanted to update the inputRevision as soon as you checked the changes - I will let you know when the fresh calibrations ran through. As far as the deviations are concerned, I saw that there is a different rent package version for the input data for the new CES tree as compared to the develop branch - this is most-likely the reason for the deviations. |
2 participants
Purpose of this PR
This PR refactors REMIND's buildings CES tree structure to provide more granular representation of electricity end-uses and removes unnecessary calibration bounds.
Type of change
Key changes:
feelalb,feelictb,feelscb) to be direct children ofenbrather than aggregated infeelcb.space_heating_elecHP_fe,water_heating_natgas_fe) to support future post-processing.New Buildings CES Structure
graph TD en["en (total energy)"] enb["enb (buildings energy)"] enhb["enhb (buildings heating energy)"] enhgab["enhgab (gases)"] fesob["fesob (solids)"] fehob["fehob (liquids)"] feheb["feheb (district heat)"] feelhpb["feelhpb (electricity for heat pumps)"] feelrhcob["feelrhcob (electricity for resistive heating and cooking)\n[RENAMED from feelrhb]"] fegab["fegab (natural gas)"] feh2b["feh2b (hydrogen)"] feelalb["feelalb (electricity for appliances and lighting)\n[NEW - was part of feelcb]"] feelictb["feelictb (electricity for ICT)\n[NEW - was part of feelcb]"] feelscb["feelscb (electricity for space cooling)\n[NEW - was part of feelcb]"] en --> enb enb --> enhb enb --> feelalb enb --> feelictb enb --> feelscb enhb --> fesob enhb --> fehob enhb --> feheb enhb --> feelhpb enhb --> feelrhcob enhb --> enhgab enhgab --> fegab enhgab --> feh2bChanges from previous structure:
feelcb(conventional electricity) → split intofeelalb,feelictb,feelscbfeelrhb(resistive heating electricity) → renamed tofeelrhcobsince it also includes electric cookingParts concerned
Impact
Checklist
Do not delete any line. Leave unfinished elements unchecked so others know how far along you are.
In the end all checkboxes must be ticked before you can merge.
make test) after my final commit and all tests pass (FAIL 0)remind2if and where it was neededforbiddenColumnNamesin readCheckScenarioConfig.R in case the PR leads to deprecated switchesCHANGELOG.mdcorrectly (added, changed, fixed, removed, input data/calibration)Further information (optional)
I ran a full
scenario_configwithout any convergence issues (see runs below). I aggregated the runs with the new ces tree to the resolution of the old tree and could only spot slight differences due to different baselines from non-heating electricity and resistive heating electricity which are expected due to the shift of electricity from cooking from one quantity to the other in the new ces structure./p/tmp/hagento/dev/REMIND/develop/remind/output: