Hello everyone. Just a couple of query regarding door component is honeybee-
Hey @Asisnath ,
All good questions. Here are the answers:
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:
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.
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.
Very well said. I agree to your points. 
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?
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:
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:
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
I’ve menaged to make my new doors but needed to make the out var as you guys can see:
from honeybee_energy.ventcool.opening import VentilationOpening
door = _door.duplicate() # duplicate to avoid editing the input
door.properties.energy.vent_opening = VentilationOpening(fraction_area_operable=1, fraction_height_operable=0, discharge_coefficient=0.45, wind_cross_vent=True, flow_coefficient_closed=0, flow_exponent_closed=0.65, two_way_threshold=0.0001)
out=door
Still need to simulate and test. But I can’t see it as Operable in face in Collor Face Attribute. (but I belive I won’t need it)
Thanks.
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.
Hello,
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.
(upload://jyz09mzOJN9SE7IY6IeQjI0jPEv.gh) (263.8 KB)
I cannot upload the rhino file since it exceeds the upload requirements.
@chris if you can have a look that would be very helpful.
Hello Chris. I copied and pasted the code to make door operable in Ladybug 1.70 in the GHPyton component but it gave an error as a result. As I have little knowledge about Python I don’t know if I did something wrong or if I missed something.
Hi everyone,
I would like my interior doors to be always open. How could I do that ?
Thanks, have a good day !
