Honeybee_door_detail

Hello everyone. Just a couple of query regarding door component is honeybee-

  1. As we have operable window option for natural ventilation simulation, is it possible to have an operable door to study any ventilation through the door opening?
  2. If the glass option is toggled true in the door component does it allow direct sun light through it for both energy plus simulation and radiance?
1 Like

Hey @Asisnath ,

All good questions. Here are the answers:

  1. 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.

  2. 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:

Sample code to make doors operable:

from honeybee_energy.ventcool.opening import VentilationOpening

door = _door.duplicate()  # duplicate to avoid editing the input
door.properties.energy.vent_opening = VentilationOpening()

FYI, you can set all of the properties about the opening on the VentilationOpening input arguments.

2 Likes

Thank you for the sample code and clearification.
Just out of curiousity,is there any reason for not exposing operable door option in the component. @chris hris

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.

2 Likes

Very well said. I agree to your points. :+1:

Dear @chris,

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?

image
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.


Interior Doors.gh (72.1 KB)

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:

Hi @MaxMarschall ,

If you want to use the current Honeybee components to model an open door, then I would suggest modeling as an aperture. However, if you’re willing to do a bit of scripting with the Ladybug Tools SDK, you’ll see that you can assign AFN ventilation properties to doors just as you would apertures. So you can just write a GHPython component that can assign a custom VentilationOpening object to the door to customize the physicals properties of how it opens.

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:


Interior Doors (1).gh (78.6 KB)

2 Likes

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.

Hi @MaxMarschall Did you by any means tried and succeeded creating a python script for opening door as per schedule though it may have a zone level control logic?

@Asisnath no in the end we decided to keep all the doors closed for the simulation since we were assessing overheating risk and this represented the worst case scenario we were after…

Hi Chris,
Could it possible that the python command to make doors interior doesn´t work with 1.4.1?
Thanks in advance.
Patricia