Question-and-Answer Resource for the Building Energy Modeling Community
 | 1 | initial version |
Got the file from @Mark and took a look. The issue is that this model has a schedule named "Always On Discrete" that has a value of 0.33 instead of 1.
There are several other schedules named "Always On Discrete N" where N is an integer in this model. These schedules are all always on with a value of 1.
The OpenStudio Model has a method named Model::alwaysOnDiscrete that looks for a schedule matching the pattern of an always on discrete schedule. The exact pattern that OS is looking for is a schedule named "Always On Discrete" with value 1 and type limits of "Discrete". If found the method returns the existing schedule, if it is not found it creates a new one.
In this model since there is already a schedule named Always On Discrete but it does not fit the pattern of the always on schedule (because it has value 0.33), OS makes a new one. Since the name "Always On Discrete" is taken, OpenStudio appends a digit to make the new schedule's name unique. In fact every time that OS attempts to access the Model::alwaysOnDiscrete it creates a new schedule. Behind the scenes OS calls this method frequently so the model had accumulated several always on schedules.
When OS makes the plant operation schemes it expects an "Always On Discrete" schedule with value 1 to already be in the model AND idf. Because in this model each call to ::alwaysOnDiscrete ends up making a new schedule, that new schedule never gets translated into the idf. The translation process expects schedules to already be translated before plants are translated.
This is perhaps too much detail, but it might be helpful for some people to know that Model::alwaysOnDiscrete is a little special and that there is an OS API to create it. The bottom line is that this particular problem was caused by the schedule having an unexpected value of 0.33. OpenStudio should be robust enough to handle this, and I intend to make a couple of changes to make it more robust.
