-
Notifications
You must be signed in to change notification settings - Fork 14
Redesign solar thermal collectors in buildings #4477
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Redesign solar thermal collectors in buildings #4477
Comments
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.
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:
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:
|
Three considerations @kaskranenburgQ:
|
My proposal: |
Double check costs since the other technologies will be installed but not deployed(?) |
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?
The text was updated successfully, but these errors were encountered: