Hi @chris
We were just running a project with different Doas loops and discovered that the heat recovering values are not beiing translated to Openstudio. (LBT version 1.3.6)
This is th HB model sent to Openstudio:
Opening the OpenStudio Application gives me this:
After reimporting the OSM model it is clear all Heatrevovery info is gone.
220119_Basis_main_model.7z (329.8 KB)
Some update:
We discovered that not all system names are beiing translated to openstudio. The system names that passe through to OpenStudio do have the heat recovery, but for all doas systems where the system name is not anymore visible in the DOAS name the heatrecovery is skipped.
This does remind me at this discussion:
Extra Update:
The same problem I have with availability schedules added to the DOAS loops.
Only for three loops this scheme is added.
I’ll try to investigate this today, @Erikbeeren . I was able to recreate the issue on my machine and my best guess is that you’ve somehow found a way to create a naming conflict since only a small fraction of the Rooms in your model are being assigned to an air loop (perhaps one air loop is overwriting another?)
Hey @Erikbeeren ,
It seems, for some reason, the OpenStudio standards gem is not adding all of the rooms associated with a given HVAC system to the DOAS air loop. If this is true, then it may be a bug on the OpenStudio standards side of things that is out of our hands to fix.
At the least, I should be able to make sure that the names and the properties of the HVAC system make it to your air loops but you may not have all of your zones on the air loop until we figure out what is going wrong with the OpenStudio standards gem.
Alright, I think I figured out what is going on. Only 109 of your total 367 Rooms actually have an outdoor air ventilation requirement and so the standards gem is smart enough to sense this and it doesn’t add these Rooms to the DOAS. This causes our honeybee code to not find the air loop that’s associated with a given set of zones and, as a result, the air loop doesn’t get the correct name or any of the properties that you’ve assigned in honeybee.
These “no ventilation” zones are still getting an FCU, though, in order to meet the heating/cooling setpoints. So I guess the problem is the exact opposite of a bug in the standards gem. The gem is just smarter than I realized.
Let me push a fix now that will ensure the air loop name and properties are transferred over in this case.
I have added a fix for this case into the development version of the plugin:
And I have verified that it ensures all of your HVAC properties are transferred, @Erikbeeren
You should be able to get the fix with the LB Versioner within the hour.
Thanks again for reporting this one!
Hi @chris,
Thank you for the quick response and solution. The heat recovery works now. The ventilation schedules however are not being attached or interpreted in the right manner. Perhaps also becuase of this smart gem. I realise it is probably not really logic to add a doas system to rooms without ventilation requirements. Perhaps we have to add some really small ventilation values to these rooms.
But if I take the existing model and look at the system nodes of rooms with a ventilation schedule (for exemple room 00_007) I get the following airflowrates:
There is only some difference visible due to heating demands in the morning.
When looking at the heat recovery inlet node, it outputs this mass flow rate overview:
This can not be the case because there are a lot of rooms with ventilation requirements.
Hi @Erikbeeren ,
A minimum sample file to recreate the case you want me to look at would be really helpful here since I can’t simulate your 367-room model on my decrepit laptop at the moment. This issue in the post that you linked to is outdated since it was addressed at the bottom there. From the code that was added here I’m confident that, if a ventilation schedule is assigned to all of the Rooms of an HVAC system, it will be found and applied to the outdoor air controller. I just tested this with a model that has a couple of rooms and it’s definitely working.
But the ventilation schedule source code does not average together the values of multiple different ventilation schedules (or lack thereof). The current setup is only geared towards the case that all rooms connected to the air loop have the same ventilation schedule. I figured that this is what should be happening in “good practice” because the outdoor air obviously gets mixed across all of the Rooms connected to the air loop. So, if all the rooms didn’t have the same schedule, this would mean that, at a low hour of the schedule, some rooms that have the low schedule are getting slightly more outdoor air than they need to meet their requirement while others are getting less than that. So I purposefully default to ignoring the schedule for this case where all the schedules are different in order to ensure that sufficient outdoor air is always applied to all Rooms.
Long story short, you need to apply the same ventilation schedule to all Rooms connected to a given HVAC system if you want to make use of this feature.
That is exactly what we did, and it worked. The incomming air is following the ventilation schedule now. But because the ventlation schedules have to be added to the building program and different programs are added to one DOAS loop, this gave some confusion. We were not expecting this to happen. But thank you for all the efforts.
Glad that solved it!
Yes, I can see why this would be unexpected and I’m happy to take suggestions for alternative behaviors. But I’m confident that the current implementation is preferable to one where you get a successful simulation that doesn’t have the ventilation requirement met for all rooms (a “silent failure” as some might call it). Would it have helped if the OpenStudio component turned orange with a message whenever a case like this is discovered?
yes I think so, or some information at the input of the ventilation schedule.
I added some warnings on the components that assign the HVAC systems:
I realized that it would be a bit easier to report it there than on the Model To OSM component and I can avoid some cases where the warning isn’t necessary.
