Report: Significant Deviation from Expected Results When Using Seasonal Schedule in Cooling Schedule

[ZhengrongTao]

hi @chris ,
I’m not sure who would be the most appropriate person to address this issue, but I believe you are the best person to delegate this problem to.：)

I have been assisting a user with the issue of “how to turn off the IdealAirSystem during transitional seasons to reduce heating and cooling loads”. In this process, I modified the Seasonal Schedule to eliminate the need for cooling and heating during the transition seasons. However, this resulted in significant changes in the peaks of heating and cooling loads, which was completely contrary to the expected outcome.

I managed to identify the problem through a few simple cases. Eventually, I discovered that the Setpoint Cooling Schedule generated by HB Seasonal Schedule did not operate as planned. Instead, there was an issue of uncontrolled indoor temperatures during the set periods, leading to an increase in cooling load.

I create three scenarios where only the Setpoint Cooling Schedule and Setpoint Heating Schedule are slightly different. In these scenarios, the “Base Model” remains unaltered, “Change Model1” utilizes the Seasonal Schedule, and “Change Model2” employs a FixedIntervalSchedule created using the values outputted by the Seasonal Schedule.

Theoretically, the results of “Change Model1” should be identical to those of “Change Model2”, as the numerical values of their schedules are exactly the same.

However, looking at the distribution of indoor temperatures, something unexpected occurred. There was a significant difference between the results of “Change Model1” and “Change Model2”.

figure 1 Base Model

figure 2 Change Model 1

figure 3 Change Model 2

Currently, the results of “Change Model2” align with the expected conditions, suggesting that the Seasonal Schedule is the primary cause of the issue.

I have created a simple model as an attachment, using LBT 1.7.26 (the case was created in Rhino 8).
Case.gh (117.2 KB)

best.
Zhengrong

[ZhengrongTao]

@chris A lot of users have already mentioned this to me recently, and I think the situation is affecting quite a few users, can you put a fix for this issue on the agenda?

[MingboPeng]

Hi @ZhengrongTao, we are aware of the difference between two schedule types. We tend to think that’s by design. E+ will use the correct design day from the seasonal schedule to size the system, whereas for the fixed schedule type, E+ just uses one day schedule to size the system, which makes it sized incorrectly.

We will do more investigations before making the conclusion.

[ZhengrongTao]

@MingboPeng Thank you！I can understand your explanation.

But I would like to add that actually in the creation of the timetable, it would be possible to fall short of expectations.

I managed to produce a schedule that runs intermittently throughout the day in specific intervals, but as I can see by the output of the shc2data component, he doesn’t output what I need.

So I don’t really think it’s likely to be in e+, although that’s the primary application scenario.
sch2data.gh (26.8 KB)
best.
zhengrong

[chris]

I just wanted to confirm that I checked the original sample file and I the reason why you get a different result between Seasonal Schedules and FixedInterval Schedules is that Seasonal Schedules have a dedicated slot for the the sizing design day schedule while FixedInterval Schedules do not. As Mingbo said, the FixedInterval Schedules will just pull whatever schedule values are assigned on the date of the design day. So this caused your cooling system to be undersized in at least one of your simulations.

In particular, I would say that this is not the best way to build a season schedule:

You can see from the hover text that the _summer_des_ schedule is that of the _base_schedule when you don’t plug in anything. So you are essentially sizing your cooling system with a thermostat setpoint of 50C on the summer design day with the setup in that screenshot. You should either plug in a value (or list of values) for the design days or use the “real” schedule for the _base_schedule_ like so:

Note that the “unmet hours” outputs are also good things to check that things are working as you intend them. I can see that this explains things pretty clearly for the difference in cooling load here:

[chris]

Also, to answer your second question, that is not the way to make schedule that runs intermittently throughout the day. I realize that you have to dig a little into the component descriptions to understand the correct way but the analysis periods only specify the date ranges of daily schedule when they are used in the context of season schedules. You have to construct the daily schedule up from 24 values and only use the analysis periods to dictate what your date ranges like so:

sch2data_correct.gh (23.9 KB)

[ZhengrongTao]

Thanks for the clarification, that’s clear enough!