Open antonszilasi opened 8 years ago
@antonszilasi , I will try to give you more feedback on your code soon. In the meantime, I just wanted to make sure that you are aware that OpenStudio seems to be close to having a full implementation of the airflow network:
I am not sure if they are all of the way there yet but I just wanted to make sure that you are aware of this becuase this is likely what we will be using in the future. We should try to make your implementation of the AFN here compatable with OpenStudio's structure.
-Chris
@chriswmackey I was aware of this, I guess I should work with them to port the code over
@antonszilasi , I apologize for not taking a deeper look at your proposed components and workflow until now. It's a bit difficult to know exactly what you are thinking about without a GH file but my initial reactions to the components in your image are as follows:
1) Do we need a separate component for zoneControls or could the inputs of this component just be on the Nat Vent component when you set _naturalVentilationType to 4? Having the inputs on the nat vent component change is going to be much more intuitive to users than making them grab a whole other component and helps us with the fact that we already have so many components now. If your present reason for a separate component is about changing some of the Nat Vent component inputs to list/item access or changing the type hints of the inputs, there is an easy way to to change these with GH API.
2) It seems like it would be best to integrate the natural ventilation characteristics of the windows with the hb_EPFenSurface class. As such, it might be better to have all of those natural ventilation properties of the windows assigned when you create the HB glazing (as opposed to plugging it into the Nat Vent component).
3) There are a lot of inputs on the component that assigns all of the natural ventilation properties of individual windows and all of them look like they are required to run the component now. Most of the time, I am sure that you don't want to assign all of these inputs and you would rather have a good default for them. Especially when it comes to schedule inputs, you really don't want to make a custom schedule every single time you use the component. I would strongly recommend using a project at your office that needs to use the airflow network in order to help inform you about which inputs are necessary to expose and which ones should have defaults assigned inside the component. I my experience, when I try using my components on real projects, I realize quickly that I don't want to deal with all possible inputs all of the time and I just want what is necessary. The HVAC components might be a good example of this where we used to have so many inputs on so many components such that adding a simple thing like an air-side economizer was a monumental task. As a result, I usually could not quickly test to see how my energy model ran with / without an economizer nor could or easily check whether my file had an air-side economizer by default. I could not have done a decent implementation of the HVAC systems in HB if I did not already understand how I wanted to use them on projects and I think a similar situation exists here.
-Chris
Is there any news or developments on this issue? Can Air Flow Networks be utilized - even in a very simple case - to predict thermal stratification in large rooms due to buoyancy effects in, say, large atria?
@hamborg ,
We don't have an update yet but I am thinking that we should integrate the AFN once we have Butterfly up and running for CFD (one of it's primary applications is supplying flow coefficients to the AFN).
On a sidenote EnergyPlus says that the AFN is not meant to model your case of large atria stratification: http://bigladdersoftware.com/epx/docs/8-5/input-output-reference/group-airflow-network.html#what-the-airflow-network-model-can-and-cannot-do
For air stratification estimation, you should use something like the Honeybee microclimate maps. -Chris
Hi everyone,
I´m currently trying to use the ladybug tools to analyze and optimize the control of (forced) natural and hybrid ventilation of climbing halls. Because of their room height and high air volume the assumption of a well mixed zone (energy plus zone) is pretty missleading espacially for looking at the comfort.
Therefore I was thinking about first using butterfly for getting the air change rate, when windows are mechanically being opened (eg. 1 min every 15 min at given wind speed). Then I want to use these ACH (mean value for air change per hour at given conditions) for my energy analysis in honeybee with one zone. And finally use a indoor microclimate mapping for the comfort analysis. Therefore I am thinking about using the CFD results for the air speed.
What are you thinking about this workflow? Does it make sense to try it like this or is it at least possible? Or does anybody has figured out a better workflow to deal with this kind of questions?
Thanks a lot
Hi all,
I have been fiddling around with AFN in Honeybee and was wondering if there is any implementation of this yet that I am not aware of?
I am aware of the AFN's shortcomings (especially stack-ventilation and large atriums), but would like to visualise basic airflows through a building without having to do a fully-fledged CFD simulation for each design idea. Is this something that could be achieved with the AFN?
Cheers, Max
@MaxMarschall I'll see if I can dig up that AFN old script which I had and post it here
@antonszilasi That would be great thanks!
Great Work @MaxMarschall
@mostaphaRoudsari @chriswmackey
I am about 60-70% developing a airflow network for Honeybee (not functional yet). I've put the code on my profile under the AFN branch on my profile.
I wanted your thoughts on how the components should be structured. I've written the AFN in Chris's nat vent component and it has two components that accompany it. One to create "DetailedOpenings" or windows and holes and another to set zone controls. See the picture below
Do you think this is a good work flow?
Let me know your thoughts