Hi @chris,
I’m not sure i’m getting right the Ventilation/Air Flow in [+]. I’m trying to make the parallel of procedures i use in Legacy in [+].
Can you have a look at the attached and tell me if i’m getting right the AirFlow of Legacy in [+].
Assuming i am, is this a temporary procedure before the AirFlowNetwork will be implemented? I think that they are not related, but is worth to ask.
Are the _naturalVentilationType in the setEPNatVent implemented in [+]?
Another question: How the Ventilation object in [+] (connected to the program component) relates to the ventilation defined in WindowOpen component?
Last question:
Are the comfort analysis and evaluation will be implemented as they were in Legacy? I mean, creating spatial maps with Adaptive/PMV/etc models.
You are setting up the window-based ventilation correctly to match between legacy and [+], though I see that you didn’t connect the same boolean toggle to both the legacy and the [+] component’s wind_cross_vent input. Once you do this, the simulations should be pretty equivalent, using almost the exact same ZoneVentilation:WindAndStack objects.
And the current situation with ZoneVentilation objects is not temporary but instead represents just one option that people will have for modeling open windows (the other ones being different variations of the AFN). We are currently working on implementing these AFN variations so hopefully that will be available to test within a month or so. But the plan is to use the same definition of fraction glazing area and height that’s operable for both the ZoneVentilation and AFN options so that you don’t have to redefine everything for the AFN. We are also working on some methods to derive the AFN Crack objects from the ZoneInfiltration objects so that people don’t have to start from scratch.
The Ventilation object in the ProgramType represents minimum outdoor air ventilation requirements for the mechanical system. So it’s a completely separate parameter from the window-based ventilation, which is done primarily for cooling purposes and to enable the use of the adaptive comfort model. I tried to differentiate the window-based ventilation by calling it “ventilative cooling” where I could but it’s a little unfortunate that the building industry refers to both of these two very different things as “ventilation.” I’m open to suggested name changes if you have them, though I think this issue is going to be tough no matter what names we use.
And we will eventually implement the comfort maps, though the plan this time is to use Radiance for all shortwave solar calculation (and to compute view factors). So you will see the Radiance components finished before you see spatial maps of comfort in [+]. Here’s the full plan of what we are shooting for:
In the meantime, you can still plug the energy simulation results from the center of the room into the comfort calculator components. And I’ll probably get to implementing the psychrometric and adaptive charts within a month or two.
As you can see i’m trying to define the same ventilation when i use DF components and HB components. The DF model seems to work, but when i translate the DF model to HB i’m less succesful. The deconstructed rooms gives an error in the HB[+}_WindowOpen component:
No operable Apertures were found among the connected _rooms.
Make sure that you have set the is_oeprable property of Apertures to True.
It means that the “Operable” option was not active for the windows created in DF[+]. BTW i don’t see any input related to this Operable capability in the DF components and neither in the component you helped me with a couple of weeks ago.
This can be an issue when simulating? I mean, the windows are not operable at all?
BTW (I’m lazy to open a new topic), why the HB_AddSubface doesn’t have the operable input? Shouldn’t it?
All of the Honeybee components that create Apertures have an operable_ input, which you can use to setup Honeybee models in a manner where some Apertures are operable and others are not.
When you pass your rooms through the “HB Window Opening” component, only the operable apertures get the window-opening properties assigned to them. This is a new feature of Honeybee[+] that is intended to give you more customization over operable window strategies. The is_operable property is also coordinated with construction sets so that you can easily account for the fact that operable windows tend to have slightly worse U-values due to frame conduction:
In any case, Dragonfly is at such a higher level of abstraction that you can’t really set the is_operable property of individual windows. Instead, when you pass things through the “DF Window Opening” component, all of the Apertures become operable. And, if you don’t pass them through that component, all of them are not operable.
So, long story short, if you want to be able to use the “HB Way” after exporting to Honeybee from Dragonfly, you have to pass the dragonfly objects through the “DF Window Opening” component before export. Then I think the “HB Way” should overwrite anything assigned the “DF Way”.
But I realize that you cannot use it on entire Dragonfly Models. I think we’ll change this at some point just for the convenience of not having to deconstruct and then reconstruct the Model. You can already see that the Honeybee Visualize and Organize components can accept a Model just as easily as they can accept other objects like Rooms and I think we all agree that it’s useful. So it’s probably just a matter of time before we start applying this to other components.
