Additional inputs

[Linwal]

• [ ] W/m thermal capacity of boreholes
• [ ] heat gains by appliances
• [ ] heat gains by lighting
• [ ] heat gains by people
• [x] solar gains (shading factors)
• [x] efficiency deviation (heat pumps, burners, PV, ...)
• [x] deviation of lifetimes of components
• [x] U-value deviation

Any opinions on what should be a scenario parameter and what should be a configuration variable are welcome. Also please add further wishes here.

[kuhnal]

To be honest, for me it is generally not very clear yet why parameters are scenarios or configurations. Do I understand it correctly, that parameters influencing the behaviour gap and climate gap (setpoints for cooling, heating, ventilation, climate models) are rather included as scenarios, whereas parameters addressing the building itself (envelope, heating system, pv) as well as the modelling gap (such as assumptions for U-values, efficiencies, ...) as configuration?

[Linwal]

the differences between scenarios and configurations is mainly dependent on the analysis that you want to do. For me, I try to put all parameters that are of technical nature and are kind of set when the building is built into the configuration file.

Yes, for me climate and behavioural parameters are at the moment the focus of the investigation. So if I want to investigate heating set points in more detail, I would probably switch those to scenario, if they are not the focus of the analysis, I would put them to the config file. Further, there is the possibility to use factors in the scenarios to describe a deviation from the set point in the configuration file.

In the end it is a question of iterating through the options in the code. Of course to some extent it would even be possible to redefine a scenario parameter into a configuration parameter in the post processing.