We are trying to figure this one out: when we check the OpenStudio results, we have mismatched schedules in the Pollination schedule editor vs. the OpenStudio report. See some example below:
ClgSetPt set to 27 °C in the editor, for some reason it is reported as 28 °C.
A more serious question can be seen below: the Occupancy schedule does not reflect the one set up at all - a similar peak intensity is being shown although the weekend occupancy should indicate no occupancy.
We have weird results in the OS report elsewhere: without changing any model input, there is an approx. 10% increase in the average number of occupants in the Outdoor Air section (is this linked to the infiltration question that @mingbo fixed here), that we are unsure about?
Left one: results after the latest update, right one: results from before.
The whole set of questions came up when service hot water was excluded from the calculation, and a decrease was anticipated. Instead, there is a significant increase in the electricity consumption, approx. 46% annually. I suspect this is mostly due to the incorrect occupancy assignment (significant usage calculated during the weekends)?
The left is the older result, the right one is the newer result:
I just wanted to thank you for documenting these issues in a way that is comprehensive and really easy to understand. It helps us to move fast and fix them for you quickly. Really appreciate it.
We are happy to help!
Many of these are discovered by the team, @ney and others not on this forum yet.
Do you have an estimate, when this will be fixed or how long it will take?
We are doing this project and if we cannot be sure if the results are reliable (e.g. our inputs are really taken “as is”), we need to think of alternatives ASAP.
We need to inform the project team (architects, HVAC engineers, and the client) on a weekly basis, and we cannot really explain these things to them right now, why the results are changing at this magnitude, what is happening under the hood, that puts us in an awkward position.
I know this can be frustrating and I’m really sorry that it happened on a project with a short deadline. I will be surprised if there are many cases like this but if there are any we are committed to fixing them for you right away. You can count on us as an extension of your team. We will not leave you in the middle of a project to deal with such issues.
@mingbo already found the cause of the issue and @chriswmackey should be able to fix it. We will keep you posted on the progress. It shouldn’t take a long time to fix. The information is exported to HBJSON correctly. The HBJSON → OSM is where the data are not translated as expected. It might be an issue in the OpenStudio API similar to the other issue that you found. If that’s the case, we will implement a workaround. If it is on our end, we will implement a fix.
Nice to meet you, @ney! And thank you for your contribution. Really appreciate it!
I really appreciate the work you are doing, and I’m sure I can talk on behalf of the team!
I don’t want at all to interpret my messages as rude, we are pressed by time and need to find a solution for this particular project.
We are contemplating our options if we need to finish the project by migrating the IDF to DesignBuilder, or should we use Honeybee to run the simulation. As we have many layers of translation, we are stuck with the troubleshooting after a certain depth.
Not at all! I totally understand and this is on us to fix for you. I was just reiterating that we are committed to getting you where you need to be.
@chriswmackey is working on a fix. The source of the issue was there were two different ScheduleDay with the same ID under two different ScheduleRuleset. The export is correct but the translator was picking the wrong one because of the ID conflict. This should have not happened because the ScheduleRuleset objects are self-contained. We are improving our translator to fix the issue for your model and also avoid it from happening for everyone else.
@furtonb and @ney, version 1.9.10 of the Rhino plugin should be released in an hour or so. Give it a try whenever you get a chance and let us know if the issue has been resolved.
PO_CheckUpdates tells that the machine has the latest update installed:
The About tab shows the same version number:
I’ve sniffed around the Pollination Github repository, but couldn’t find the 1.9.10 release.
Could you help where to look?
If I understand correctly, the problem was caused by duplicated “Day Names” in the Schedules, so we renamed the “Day Name” in each schedule to ensure unique values, but the problem persisted (1.9.9).
Let us know how it goes. I believe @chriswmackey already sent you a fixed version of your model in a private message. Let us know if you need any help.
@mostapha I’m happy to say that the OS results and the PO Schedule editor looks aligned now!
We have some funky schedules, but that is on us.
Thank you for your effort and very quick fix!
Yes, I haven’t had the time to thank him.
A quick note: the rooms lost their names, which would’ve made it hard to work further with that model. The problem is described in this thread, I think.
Did you try o use the PO_ResetIdentifier command? Here is the video that shows how you can use it. Just make sure there are no duplicate names in your model.
