Buildings stock and heat demand migration

[aaccensi]

Context

The sliders/inputs for the Buildings stock and heat demand are changing and therefore they need a migration to go along.

Implemented changes

• The migration file in question: db/migrate/20260804120000_simplified_buildings_heat_inputs.rb
• The schema file with the latest version: db/schema.rb (And Rails 8 alphabetical order)
• The solid cache schema file also updated: db/cache_schema.rb (Only Rails 8 alphabetical order)

Related

The etsource and etmodel changes are still a work in progress but this migration should never land (aka be merged to beta or pro) before the etsource changes do!

Checklist

• I have tested these changes (locally)
• I have updated documentation as needed
• I have tagged the relevant people for review

[noracato]

Nicely written!

[noracato]

@aaccensi could you double check this?

[aaccensi]

Virtually this file causes no changes. It looks like this because Rails 8 now sorts fields alphabetically, and it did so when I ran the migration (it also adds a header comment explaining the file's purpose). The columns and indexes are identical. The only real addition is the explicit utf8mb4_0900_ai_ci collation, which is our MySQL 8 default and has no effect on a table with binary key/value columns (queue_schema.rb already has it).

Even though this change adds nothing, I think it's better to commit it once and for all rather than discard it, so we don't keep running into it every time we run a migration.

[kndehaan]

Overall, the migration is looking good! I have a three required changes, see listed below. Note that these changes requests also apply to the migration in the households sector.

1. Design change of insulation sliders
We decided that the insulation sliders (buildings_insulation_existing_buildings and buildings_insulation_new_buildings) will be set as a positive value instead of a negative value. So instead of "my heat demand changes with -5% due to improved insulation", it's rather "my heat demand reduces with 5% due to improved insulation". Could you process this in the migration as well?

2. Omit behaviour slider from migration
We discussed that overall it's quite tricky to set the behaviour slider based on the old sliders since it conceptually difficult to distinguish insulation and behavioural effects. Therefore, the behaviour slider can be left out of the migration. If a reduction in kWh/m2 was set, set the reduction in the insulation sliders. If an increase was set, do nothing. This effect will be lost in the new scenarios.

3. Apply rounding
Could we apply rounding of the values for the new inputs that is in line with the step_value of the input? Some inputs are currently set with a lot of decimals, see screenshot below, which doesn't look so neat. This would mean rounding to:

• 0 decimals for buildings_number_of_buildings_demolished and buildings_number_of_buildings_new
• 1 decimal for buildings_insulation_existing_buildings and buildings_insulation_new_buildings

[aaccensi]

These changees sound good:

1. No problem, make sure this changes actually land properly in etsource. (Adjust accordingly the min_value and max_value of the new inputs)
2. Great, dropping the calculation of the behaviour slider from the migration simplifies it a lot. As a side note, this would have been much better if decided before the work on the migration was started to save us valuable time.
3. We can. I would argue that rounding the buildings_number_of_buildings_new and buildings_number_of_buildings_demolishedis pointless though. If the original values of these inputs and the area attribute present_number_of_buildings are whole as they should, the subtraction or direct move necessary for their migration should still be whole. But maybe is good to do it nonetheless for extra safety, just in case the original data is not as we imagine it.
   EDIT: Actually for demolished it will surely help since the present_number_of_buildings are affected by the scenario scaler!

[kndehaan]

Good!