By default, doors do not open in the natural ventilation simulation but, yes, it’s definitely possible to setup a Honeybee model where doors open according to the same ventilation strategy as the windows. We haven’t exposed a Grasshopper component that allows you to switch on this operability for the door but it only takes a couple lines of Python if you want to do this. I put some sample code below if you want to paste this in a GHPython component and plug a Honeybee _door into it and get an operable honeybee door out.
Yes, if you set the glass_ option to True on the door, the default E+ Construction and Radiance Modifier will change to be transparent instead of opaque (according to the Room ConstructionSet/ModifierSet or the Honeybee default generic ConstructionSet/ModifierSet). This also allows you to assign WindowConstructions to the door instead of being forced to use OpaqueConstruction. FYI, you can always check the construction assigned to everything using “HB Color Face Attributes” like so:
There’s no other reason except that we already have over 250 components in the plugin and I think we all have an interest in keeping the number of components and component inputs to a reasonable size for sake of the people learning the plugin.
As I explained in a post to @AbrahamYezioro , now that the Ladybug Tools code is organized into a well-documented SDK, the threshold of effort that’s needed to “grant wishes” is incredibly low compared to where it used to be. The tougher issues at this point are more “political” than technical. For example, if we all have an interest in keeping the components to a reasonable size, which inputs/outputs do we choose to expose as opposed to recommending people build their own Python component using methods on the SDK layer?
Certainly, if enough people tell us that they continually find it annoying that a certain feature isn’t exposed on a component, we’ll add it but we don’t want to say yes to everything since doing so would be helping advanced users with niche applications at the expense of new users who are trying to wrap their heads around the mainstream applications. But that’s why we have this forum. Hearing feedback from a big community allows us to realize what is mainstream and what is niche much better than any one individual ever could.
I am currently doing an overheating study for a naturally ventilated Passive House building according to CIBSE TM59, which says that windows should be modelled as open when the indoor temperature is above 22C and the space is occupied.
It also allows you to model interior doors as open during the daytime.
Therefore, I would need two independent opening algorithms; one for the windows and one for the interior doors. Is this currently possible with HB / OpenStudio?
I have built a simple example of this scenario and have implemented your above code for the door, but I’ve noticed that there is no argument for specifying an opening algorithm. Instead, this is done at the room level with WindowOpen and VentControl components.
I have also noticed that I can’t query the outputs related to natural ventilation that you mentioned here. For example, there is no “Zone Ventilation Current Density Volume”; there is a “System Node Current Density Volume Flow Rate” in the rdd but no data attached to it:
However, the control logic that we have implemented in Honeybee is on the Room level so you won’t be able to close the door separately from the windows of the room. Still, you can schedule both of them to close at night using a schedule on the room’s VentilationContorl object.
If you really need to controls for the door to be separated from the windows, the only way to do this right now is to edit the EMS control logic in the IDF that Honeybee outputs. You could do that manually or with an OpenStudio measure but I’ll warn that there’s a big learning curve to jump between just editing the Honeybee properties in Grasshopper to editing EMS logic in an IDF (or with the OpenStudio SDK in the case of a measure).
Also, you should use the “HB Read Result Dictionary” component to check which outputs you can request from a given EnergyPlus simulation. And you need to request these outputs from the simulation in order to be able to import them after the simulation is run:
Thanks @chris, I have messed with the EMS before and know the pain it involves…
In the meantime, the client has agreed that we can model the doors as closed, but when I have a free moment I’ll try your LBT SDK solution.
Thanks for answering the question - I’m sure this will come up again in future so it’s good to have this information.
Well done, @MR_Yuki . That is the right way to do it if you’re trying to represent an exterior door that remains open at certain times.
Yes, honeybee Doors don’t have an is_operable property like the Apertures do (since you probably can’t call it a door if it’s not operable). But all that you need to care about for your case is the .properties.energy.vent_opening that you have in your sample.
I’ve been trying to add internal doors to my honeybee model but somehow I’m getting error while running the final simulation. If I remove the internal doors the model seems to run fine, so I’m guessing only the internal doors are creating the problem. Can someone help me with identifying the problem?
I’ve added the error snip.