Redesign solar thermal collectors in buildings

[claudiavalkenier]

I noticed something in a blank scenario for Cyprus with the slider for Solar thermal collectors in space heating for buildings (buildings_space_heater_solar_thermal_share). The default setting is 8.8%, and it shows a final solar thermal demand of 0.46 PJ. But when I change the slider to either 8.7% or 8.9%, the final demand drops to 0.06 PJ, which seems a bit odd. Should this be looked into?

[kaskranenburgQ]

The slider for solar thermal collectors calls for a re-evaluation.

The label indicates that the user can set a certain amount of the potential roof surface to be build with solar thermal collectors:

The labeling indicates that this energy will be used for the hot water demand in buildings. While the buildings sector in the ETM has no hot water demand.

Then what does this slider do?

The underlying input tells us that this slider partly fills the space heating demand of buildings. Setting this slider to 100% will let the solar thermal heaters produce 13% of the building space heating demand.

    EACH(
      UPDATE(EDGE(buildings_space_heater_solar_thermal, buildings_useful_demand_for_space_heating_buildings_present), share, (USER_INPUT()*0.13)/100.0),
      UPDATE(EDGE(buildings_space_heater_solar_thermal, buildings_useful_demand_for_space_heating_buildings_future), share, (USER_INPUT()*0.13)/100.0)
      )

The hardcoded value in this sliders i not documented.

The issue that @claudiavalkenier describes above comes from a difference in the defined start value and input statement of the slider:

The start value has no cap on the 13 % of the space heating demand:

- start_value_gql = present:V(buildings_space_heater_solar_thermal,share_of_buildings_useful_demand_for_space_heating_buildings_present) * 100

This means that if I were to set the slider to the same amount as the start value it would multiply with 0.13, while the start value does not take this into account.

I propose the following changes:

1. Change labeling in front-end to reflect that this technology is used for space heating.
2. Change the hardcoded slider value
3. Change the maximum slider value of the slider.
4. Change the start value of the slider.

[mabijkerk]

Three considerations @kaskranenburgQ:

1. If we do this, do we need a migration?
2. What would be the new hardcoded slider value? What would be the maximum value? If the maximum is set to 100% and a user sets that value, does that work or will the model break?
3. Why/how would you change the start value of the slider?

[kaskranenburgQ]

1. If we do this, do we need a migration?
2. What would be the new hardcoded slider value? What would be the maximum value? If the maximum is set to 100% and a user sets that value, does that work or will the model break?
3. Why/how would you change the start value of the slider?

1. Depends on the implementation, but I think yes.
2. I just tested this, setting the maximum slider to 100% does not break the model in a nl2019 scenario locally.
3. This is indeed only necessary when our implementation demands it.

My proposal:
Let the user set the value to 100%, but keep the solar thermal collectors in a separate share group in comparison to the other household heating sliders.

[kndehaan]

Double check costs since the other technologies will be installed but not deployed(?)

[kaskranenburgQ]

Status of redesign solar thermal collectors in buildings issue:

This issue is solved in the PR's underneath this comment.
The chosen approach to solve this issue is to remove the hardocded value from the input slider.
This makes it possible to fill all heat demand by the solar thermal collectors in the buildings sector.

In this approach 2 issues remain:

• As @kndehaan brought to the attention: Setting the household collector share to 100% will lead to both costs in the solar thermal collectors and the "normal" space heating nodes. Leading to extra costs (in nl2019 setting the slider to 100% leads from 37.0 bln/yr to 40.8 bln/yr)
• The solar thermal collectors fill the energy demand on an annual level. Setting the slider to 100% will therefore serve all the annual demand. The hourly household heat calculations will therefore not take place. It is not realistic that all household heat demand can be served by solar thermal collectors on an hourly level. In the future we should look into the possibility of making this technology on an hourly level as well.

PR's:

• ETSource: Redesign Buildings solar thermal slider etsource#3263 (input slider change)
• ETModel: Clarifying working of solar thermal slider #4489 (Documentation of slider working)
• ETEngine: Buildings solar thermal etengine#1581 (Migration to support input slider change)

[github-actions]

This issue has had no activity for 60 days and will be closed in 7 days. Removing the "Stale" label or posting a comment will prevent it from being closed automatically. You can also add the "Pinned" label to ensure it isn't marked as stale in the future.