algorithmic modeling for Rhino
I have a question regarding the component "setEPNatVent", in which different types of natural ventilation can be set.
I am trying to simulate a large volume by splitting it into small thermal zones with AIR WALL as adjacency type, and I would like to input a specific amount of natural ventilation that these zones are getting (calculated in another program).
However, it is important to have E+ understanding that these zones are acquiring air from specific neighbouring zones (might changing over time within a year simulation).
My question is: how is the input (as shown in the image) interZoneAirFlowRate defining the incoming air temperature in a zone? Especially difficult to define this is when multiple zones are fed into this component. How does it understand whether the specific amount of air is flowing from one zone to another with a specific sensible heat level and moisture?
If this is not possible to be done through this component: Is there a way to trick E+ in making this set up possible? The goal is to have each zone getting a specific air flow rate from another zone, with the relative air temperature and relative humidity. Setting the mechanical system for each zone with the related air temperatures and ventilation rates is a good solution?
I hope the problem is clear and that someone can help me with this!
Replies are closed for this discussion.
Not sure I can be much help but I will try to put some thoughts on paper anyways. I haven't really used the component but I am imagining that what it does is creates (natural and other) ventilation in or between zones. Now this ventilation has to come from somewhere. Usually, it comes from the outside, so the temperature and humidity of the incoming air completely depends on the place in the world and your options in outdoorTempForNatVent. I am not sure if there can be an addition here to also allow for humidity. Perhaps a nice workaround for this (if outside air is the case) is through Ladybug. We could open the .epw data and select only those moments within the year where the temperature and humidity conditions are within the desired limits. Then that can be used to create a schedule for natvent (again not sure how we would link this schedule to the component but I'm sure Chris and Mostapha will know this).
However, in your case it seems you want this ventilation to come from other zones. That would mean that you would want specific temperature and humidity conditions for these zones (since you want your interzone ventilation with specific values on these). In that case I don't understand completely what E+ will be simulating. It's job mainly seems to be exactly to acquire those temperature for you. The way I see it you could try and condition your model near those conditions you want for each zone and then just allow for natvent between those zones, with a specific flow rate.
But tbh, when you absolutely need to set humidity and temperature for the interzone airflow, then that sounds more and more like a job for CFD and not E+.
Hope this makes somse sense.
Thank you for your post and I understand much better what you are trying to do now given this information and your post here:
At the moment, I have only implemented a simple way of using air walls in EnergyPlus, which basically mixes the air between zones joined by an air wall at a constant mixing rate (this mixes both the temperature of the zones and the humidity between the zones). This simple way of using air walls is what DesignBuilder does by default until you set the natural ventilation to be "calculated," in which case DB with try to build an Airflow Network for you.
These simple inter-zone mixing objects are separate from the natural ventilation objects currently implemented in Honeybee and these simple natVent objects operate on a zone-by-zone basis. Because Honeybee assigns these nat vent objects (as well as a lot of other things) on a zone-by-zone basis, this was also how I implemented the interZoneAirFlowRate, although I understand that this makes things very confusing and also limiting. So, right now, you can only use the interZoneAirFlowRate to increase or decrease the total air flow between one zone and all of its neighbors and you cannot yet specify a different flow rate to each zone that it is adjacent to. If this sounds confusing, the readMe output of the setEPNatVent component should always give you detailed information on how these mixing objects are being changed as you play with the interZoneAirFlowRate value.
I was planning to never bother with providing the ability to set different mixing levels for different adjacent zones as I was hoping to just implement the Airflow Network in Honeybee (thereby eliminating the need for such a messy method). At present, though, I have been able to model all of my natural ventilation cases well with just the simple objects and so my motivation to implement the AFN hasn't been as high as I was initially expecting.
I can try to get around to implementing the AFN but it is still going to be a while given everything else I have on my plate. The AFN might also be overkill depending on how complex your building is and uploading a GH file of your energy model would enable me to better help you.
If you really need the capability to set different mixing objects for different zones right now, you can try to override everything by putting you own mixing objects into the 'additionalStrings" input of the "Run Simulation" component. I give you an example of how to input such a mixing object in the attached file.
Hope all of this helps,
For some reason, the GH site did not take the file attachment. Here it is.
Ok. The problem seems to be with Harvard's internet that I am currently trying to use. Hopefully the attachment goes through this time now that I am using my phone's internet.
Chris and Theodoros,
Thank you for your ideas and extensive help.
CFD is in fact an option, but I decided to use airflow network done in another program and coupling it with E+ through Honeybee, for retrieving faster solutions. I am still working on how faster this process could be compared to a CFD analysis.
The file that Chris attached is exactly what I was looking for. I didn't know there was the possibility to customize the idf file through Honeybee. In this way I can easily change the airflow rate between zones in a specific way, and for each zone differently.
Thank you again.
Glad that you find it useful. I think that you will find the Airflow Network is several thousand times faster than running a CFD and this simplified airflow method with custom objects is even faster. As such, you can use an Airflow Network for non-steady-state calculations like those of E+. Still, the AFN (and especially this simplified airflow method) only works well if you set it up correctly. For this reason, it is sometimes useful to start with a point-in-time CFD calculation and use this to calibrate your AFN or airflow objects first.
I am very interested if you manage to finish your task and get it running?