Infeasible scenario initialization - Twozone Apartment Hydronic testcase

[Jaap-Neven]

Problem description

The 'peak_heating_day' scenario for the twozone apartment hydronic testcase is defined as the period from day 308 until day 322. Initializing this scenario with the code snippet below, where start_time is 308 and warmup_time is 7. Initializing the case with PUT 'scenario' gives the exact same intialization.

res = check_response(requests.put('{0}/initialize'.format(url), json={'start_time': start_time * 24 * 3600, 'warmup_period': warmup_time * 24 * 3600}))

This gives for the day and night zone air temperatures the value 290,47 K (17,32°C). At the same time, the lower comfort bound for both zones ramps up to 21°C, which results in strong thermal discomfort at the start of the scenario.

The figure below shows own (preliminary) simulation results where the ramp-up behavior is clearly visible at the start.

Suggested fix

This initial discomfort can hamper a fair comparison between different controllers, since a well-performing controller will always result in discomfort based on this ramp-up behavior.

Is this intentional, or rather a consequence of the implemented baseline control for this testcase? Essentially, this behavior could also 'challenge' the controller by starting from a non-optimal state, such that the controller is expected to heat immediately.

[EttoreZ]

Hey @Jaap-Neven thank you for the comment. I feel like your question opens a larger conversation that we could have with the group, here is what I think:

• It's not intentional, the scenarios are chosen just based on peak and typical day loads, so depending on how the baseline controller operates there could be a starting situation where comfort is not guaranteed no matter how hard MPC tries (like the one in your screenshot).

• This could lead some optimal control problem formulations (hard constraints on temperature) to give unfeasible solution. Now since this can happen in a real building, I would say it's good feedback for the control developer that their controller should be able to deal with that.

• The comparison between controllers in the same scenario is relative, so the final results should not be affected too much by the "bad" starting conditions.

[Jaap-Neven]

Hi @EttoreZ, thanks for the comments! I agree, especially with your second point. In the end it's important that controllers are benchmarked in the same way, which is the case here. And indeed, a perturbed initial state is an extra challenge for the controllers.

I will leave the issue open for now and will leave the choice to you on whether or not to keep it open for future reference.

[dhblum]

I agree with all of Ettore's points, this isn't something I think we should make any changes for right now. But we can keep the issue open and link to #539 to perhaps see if the baseline controller should/could be tuned a bit, and make any updates together with other updates to this test case when they occur.