Suggestions (or perhaps misconceptions) on air exchange features

natural-ventilation

#1

Hi,

I would find some enhancements in the possibilities for representation of air exchange helpful. It is also very likely that I have not yet figured out Honeybee possibilities. But, for the sake of discussion and continuous improvement of ladybug.tools, here my points:

  1. To my understanding what setEPNatVent offers in terms of interzone air flow rate is not actually interzone flow with for example ZoneMixing and ZoneCrossMixing classes in EnergyPlus, but an outdoor air provided by mechanical system (at least in case of a model without air wall). Interzone mixing is, however, needed in some cases even without air wall (for example imagine the air exchange between a sunspace and another zone, which one can parametrically explore).

  2. In the setEPZoneLoads you only offer infiltration for natural air exchange. I agree that in many cases it does not matter how we call the air that naturally comes to the building. But, firstly, it is helpful for modelers to differentiate between intentional and unintentional introduction of fresh air, but there are also cases where having both classes of natural air exchange helps (for example, to easily keep the fixed rate of uncontrollable infiltration, while doing parametric exploration of the natural ventilation).

  3. I am aware that you offer another EnergyPlus module for estimation of ventilation (based on ASHRAE HoF). But leaving aside the uncertainties associated with that model for estimation of ventilation in dynamic simulations (which has nothing to do with Honeybee), I still find it quite useful that the modeler can explore the implications of specific air change rates in a parametric simulation, without being worried about the actual ventilation rates in the beginning.

  4. Offering ZoneVentilation:DesignFlowRate class with all its thresholds for natural ventilation also provides the possibility to control it based on indoor environmental conditions. I saw in one of @chris videos how charmingly we can control infiltration based on the outdoor data in Honeybee. But as in case of the internal conditions, there is a feedback loop between ventilation and indoor conditions, one can benefit from the internal run-time data exchange of EnergyPlus.

  5. I realized that setting the setEPNatVent to mode 3 results in fan-based ventilation using ZoneVentilation:DesignFlowRate. But, as far as I could say, this is always on. I think there should be a possibility to set a schedule for this.

  6. I am not sure if there is a possibility to add specific EnergyPlus objects to the model made by Honeybee and continue with it in Honeybee to enjoy its powers in parametric environmental studies. Imagine, as an example, the zone:mixing class. One does tons of things with Honeybee. If that feature is not there yet, you just make that object in a text editor and attach it to your model.

PS: The time I spent to write such long comments just shows how much I enjoy working with your tools!

Best,
Farhang


#2

@farhang.tahmasebi ,
It would have been really helpful to break down your suggestions into multiple discussions as it makes it really hard to respond to all at once. I’ll answer what I can now:

  1. The SetEPAirflow component allows you to both add natural ventilation and a adjust the flowrate of air mixing objects that are automatically assigned when you have air walls between zones. If you need more customization of air mixing, you can add your own objects with additionalStrings as noted in this discussion (Interzone Airflow Rate for a large volume). You can get a decent approximation of the heat transfer from a sunspace with plain old air walls but a better practice would be to use these custom mixing objects and vary the airflow with the temperature difference between the sun space and the zone.

That’s all I have time for now. I’ll see if I can get to the other later.


#3

Hi @farhang.tahmasebi. Happy to hear that you’re still enjoying using Honeybee and we didn’t disappoint you! :wink: I leave the rest of the items to @chris but for number 6 you can use additionalString input. It’s available both for EnergyPlus and OpenStudio and you can simply add any standard EnergyPlus objects to the file as a string.

Another option is to use OpenStudio measures to add the missing parts. You can do much more with measure but it takes some time to write them and it will only work with the OpenStudio component.


#4

Thanks @chris and @mostapha. Those were only suggestions. So, don’t worry about answering them. If at some point you want to restructure natural ventilation components, you can have a look at them again. The additional string possibility, however, I was not aware of. It is exactly what I meant. Great.

Best,
Farhang


#5

Just my tuppence on the whole thread.

One of the big disadvantages to all of those methods in trying to apply natural ventilation is that they neglect much of the physics of the problems of natural ventilation in favour of simplicity and run-time. To more accurately simulate natural ventilation in Energy+ you need to use the Airflow Network library, and associated methods - these firstly apply a relatively realistic boundary condition to the system (e.g. wind based pressure coefficients and flows) and then do a proper mass and energy balance across openings/zones based on these wind pressures. Without that, you’re assuming a highly variable system is acting like a relatively predictable one, which of course it doesn’t.

Whilst they’re fiddly to set up, it’s a shame there currently isn’t an implementation of the airflow network methods in Honeybee (appreciate there’s not enough hours in the day!), as it’s really key to getting anything like a realistic solution to non-mechanical airflow simulations, and by bringing the CFD components into the parametric sphere with Butterfly, you’ve opened up the opportunity to do really accurate pressure coefficient calculations for openings, among other things.


#6

@EdWealend, I agree in principle that AFN model is a more sophisticated and reliable one. But note that in practice with that method comes also a lack of appropriate wind pressure coefficients for different settings, and more importantly lack of understanding of the required inputs such discharge coefficient. I do agree that, it is one step in the right direction to use AFN. But, given the required extensive inputs for AFN, I still believe that it is quite useful to parametrically explore the implications of assumed air changed rates for building performance.


#7

True enough, in the case of relative studies and optioneering, there’s probably not much harm in using the simpler methods, as long as the user is aware that in absolute terms, it’s massively inaccurate unless you’ve done some other simulation, like CFD, to calibrate your airflows in some way.

Having used it in anger, I personally think that the AFN method implemented in Energy+ is a pain in the arse, and a number of other software packages manage to make it much easier to work with natural ventilation (IES Macroflo, TAS etc). That said, it’s fairly easy to generate hourly wind-pressure coefficients for a building using the results of CFD simulations from Openfoam, and there are tables of discharge coefficients from empirical studies should you need them.


#8

I’ve never used IES before, but our building energy consultants seem to love it. Out of curiosity, how does IES Macroflo make it easier to use the natural ventilation?


#9

Sorry that I am just getting back to the conversation now. To address a few more points:

4+5) With Option 3 on the setEPairflow component (which uses the ZoneVentilation:DesignFlowRate) you can dynamically change the airflow using the schedule input. You can even see this in action in this example file .This is what I would recommend if you need full customization of the airflow on an hourly basis.

Judging from some of the comments made here, there also seem to be some misunderstandings about the capabilities of the E+ ventilation objects that are presently implemented in Honeybee. It’s important to emphasize the current objects are enough to give a complete representation of airflow for single zone cases, including both single-sided ventilation, stack-driven ventilation, and wind driven ventilation with pressure coefficients. The wind driven flows account for wind direction in relation to the orientation of the window and use the zone’s height from the ground in relation to a wind boundary profile to determine flow rates. For single zone cases, they should yield the same results as an airflow network and the cases where these objects fall short in comparison to the AFN is in the modeling of multi-zone airflow.

This said, I wholeheartedly agree that implementing the AFN is a step in the right direction and I will volunteer to add it to Honeybee as soon as the integration with the OpenStudio SDK is finished. There are also many other ways that someone could implement it for the time being, including the writing of an EnergyPlus measure, adding it with additionalStrings, or editing the Honeybee code as @AntonSzilasi did here.

I also want to point out that modeling natural ventilation to the point that the increased accuracy of the AFN is meaningful requires us to know a lot more information about the building we are modeling including:

1) Outdoor wind pressure coefficients that account for context objects around the building - this has already been brought up on this thread and is something that CFD integration can help with.

2) Schedules for opening and closing doors/windows between zones - this is typically one of the bigger unknowns for new projects and requires the modeler to know a lot about whether occupants are willing to leave doors open and understand their expectations of sound privacy. This challenge can be overcome by engaging with the future occupants of a building under design but the vast majority of projects that I have been a part of so far have not had the luxury of knowing exactly who the occupants are beforehand. Without knowing whether doors and interior windows will be closed, there is little point to the added accuracy of the AFN and so we must overcome this challenge as an industry to make the AFN useful.

3) Shifting thermal comfort models - while the use of wind and stack driven airflows offer the possibility of saving energy by shutting off mechanical fans, it’s important to highlight that this is not the major reason why naturally ventilated buildings use less energy than fully conditioned ones. Particularly in today’s profession where the use of airside economizers is common practice, there is often very little energy saved simply by opening the window to bring in outdoor air instead of delivering it (unconditioned) through a mechanical system. Much of the energy savings that we observe in real-world naturally ventilated buildings comes from the fact that occupant’s perception of thermal comfort is undeniably different in these buildings. This is recognized through international standards like the adaptive thermal comfort model, which supports the use of wider thermostat set-point ranges for naturally ventilated buildings than mechanically ventilated ones. As anyone who has run enough energy models will notice, changing the thermostat set point even by a degree can dramatically change the annual energy use. In every simulation I have run, these thermostat setpoint savings far outweigh any of the fan energy savings of naturally-driven airflow as opposed to fan-driven airflow. Therefore, even before we start to engage with the added accuracy of the AFN, modelers need to understand how this perception of comfort changes in naturally ventilated buildings and know how to apply the adaptive model to their designs. This is both a challenge in terms of educating people about what we already know from the existing adaptive comfort model as well as doing research into what triggers this shift in thermal comfort (since we have no comfort models for mixed-mode buildings or transitioning between air conditioning and natural ventilation modes).

I want to make it clear that an officially-endorsed AFN in Honeybee will require modelers to make decisions about these criteria and we would view a “single-click” AFN, which assigns a bunch of default assumptions for these criteria, as a potentially less accurate natural ventilation simulation than one done with simpler natural ventilation objects that the modeler fully understands. So the lack of an officially-supported AFN in Honeybee isn’t because we don’t think it’s important. We just want to be sure that, when we do implement it, people are actually getting increased accuracy out of its use rather than mistaking a more complicated model for a more accurate one.


#10

Main benefits - it does the creation of AFN type objects automatically, does bulk airflow movement pretty accurately, and gives a good selection of user friendly ways of entering the various coefficients.


#11

Hi Chris,

Thanks for your response. The information on how energy+ simulated single zone models is very useful, and you’re correct I wasn’t aware of the detail of some of the capabilities of that component - the opening effectiveness is particularly useful.

Some more questions though, the component currently seems to allow application of a custom stack discharge coefficient, but not custom window discharge coefficients, is that correct? Is it possible to set multiple types of window discharge coefficients in one zone?

Most of the comments about adaptive comfort and mixed mode ring true, I’m UK based, and we try to use natural ventilation by default on domestic properties, and often design moderately complex natural ventilation and mixed mode systems on commercial properties, hence why our software tools tend to do these things fairly well and why we miss them when they’re not there!


#12

Thanks Chris for your detailed explanations as always.

One question regarding the setEPairflow component. You suggested Option 3 for a “full customization of the airflow on an hourly basis”.
But what about a forced natural ventilation, where one possibly want to customize the airflow in a smaller timestep (e.g. mechanically opening windows 1 min every 15 min)?
Is it somehow possible to create schedules (minute basis) to use it for example to analyze different control strategies for a forced natural ventilation?

Thanks a lot