Skip to content

Refactor buildings ces tree#2331

Draft
hagento wants to merge 2 commits intoremindmodel:developfrom
hagento:buildingsCEStree
Draft

Refactor buildings ces tree#2331
hagento wants to merge 2 commits intoremindmodel:developfrom
hagento:buildingsCEStree

Conversation

@hagento
Copy link
Copy Markdown

@hagento hagento commented Apr 14, 2026

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:

  • Moved non-heating electricity uses (feelalb, feelictb, feelscb) to be direct children of enb rather than aggregated in feelcb.
  • Added 28 granular final energy carrier-enduse categories (e.g., space_heating_elecHP_fe, water_heating_natgas_fe) to support future post-processing.
  • Removed MEA region-specific calibration bound relaxations for buildings variables that are no longer needed with the improved CES structure since they lead to unreasonable results.

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 --> feh2b
Loading

Changes from previous structure:

  • feelcb (conventional electricity) → split into feelalb, feelictb, feelscb
  • feelrhb (resistive heating electricity) → renamed to feelrhcob since it also includes electric cooking

Parts concerned

  • ☑️ GAMS Code
  • ◻️ R-scripts
  • ◻️ Documentation (GAMS incode documentation, comments, tutorials)
  • ☑️ Input data / CES parameters
  • ◻️ Tests, CI/CD (continuous integration/deployment)
  • ◻️ Configuration (switches in main.gms, default.cfg, and scenario_config*.csv files)
  • ◻️ Other (please give a description)

Impact

  • ◻️ Bug fix
  • ☑️.\ Refactoring
  • ◻️ New feature
  • ☑️.\ Change of parameter values or input data (including CES parameters)
  • ◻️ Minor change (default scenarios show only small differences)
  • ◻️ Fundamental change of results of default scenarios

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
.

  • I executed the automated model tests (make test) after my final commit and all tests pass (FAIL 0)
  • I adjusted the reporting in remind2 if and where it was needed
  • I adjusted the madrat packages (mrremind and other packages involved) for input data generation if and where it was needed
  • My code follows the coding etiquette
  • I explained my changes within the PR, particularly in hard-to-understand areas
  • I checked that the in-code documentation is up-to-date
  • I adjusted forbiddenColumnNames in readCheckScenarioConfig.R in case the PR leads to deprecated switches
  • I updated the CHANGELOG.md correctly (added, changed, fixed, removed, input data/calibration)

Further information (optional)

I will provide further information, update the inputRevision, etc. as soon as all the runs are completed.

  • Runs with these changes are here:
  • Comparison of results (what changes by this PR?):

@hagento hagento added the enhancement New feature or request label Apr 14, 2026
Copy link
Copy Markdown
Contributor

@ricardarosemann ricardarosemann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread core/sets.gms
Comment on lines +369 to +373
feelhpb "buildings use of electricity for heat pumps"
feelrhcob "buildings use of electricity for resistive heating and cooking"
feelalb "buildings use of electricity for appliances and lighting"
feelictb "buildings use of electricity for information and communication technology"
feelscb "buildings use of electricity for space cooling"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we still need these set elements in all_enty - buildings final energy quantities are to my knowledge mostly handled via fegas, fehos, feels and so on. There is one mapping that maps fegas in buildings to fegab etc., but it actually only includes feelb as far as electricity demand is concerned.

Comment thread core/sets.gms
Comment on lines +374 to +401
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"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment on lines -73 to +77
feelb . (feelcb,feelhpb,feelrhb)
feelb . (feelrhcob, feelhpb, feelalb, feelictb, feelscb)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this anymore: As far as I can see the set fe_tax_sub_sbi which is derived from fe_tax_sub36 is only called with "fehos" as first entry, which we do not have here. So fe_tax_sub36 can most likely be removed.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked with Laurin, we can remove fe_tax_sub36; we might want to do this in a separate PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants