As of now, the comfort recipes can accept the wind speed from CFD result. Is there a plan for the comfort recipes to accept temperature spatial variations from CFD result?
I many cases I found that we need to investigate the effect of local heat source that will change the temperature distribution in occupied space. It would be great if this can be input into the comfort recipes for analysis.
Thoughts?
This is definitely something that we will consider as we implement comfort maps in Honeybee[+]. At the least, I think we would provide options to input a CSV with air temperatures for each comfort map node at each hour. However, I would be wary about setting up official workflows for time series comfort maps with this type of temperature CFD result. Given that solar radiation is oftentimes one of the biggest heat sources in a zone, you would have to run a lot of CFD simulations to model the effect of how the air temperature distribution changes with the movement of the sun over the day. Still, if we manage to agree on workflows that confidently increase the accuracy of the results, I could see such workflows as being “officially endorsed.”
Implementing support for the CSV temperature input in the Legacy Honeybee would be a large effort that I don’t expect to undertake. However, I will note that there are a number of ways that you can “hack” the current comfort map workflows to insert your own custom air temperatures (and this doesn’t involve any editing of source code). In particular, I would point you to this example file that, true to its title, “deconstructs” the comfort map calculation into ~20 smaller components. While it is not very calculation-efficient, you can use it to understand what is happening in the source code under the hood and insert your custom values where you like. Also, if you are happy with how the comfort maps do the radiant temperature calculation, you can always just run them with a fast comfort model (like the adaptive model), get the radiant temperature results out of the maps, and then plug them into a PMV Comfort Calculator component along with the air temperatures from your CFD results. You can then use the Recolor Mesh component to help you display the results.
I hope that helps!
This can be an alternative workflow:
Hi Mostapha, thanks for pointing this out. I will definitely try this on my machine.
However, this solution is not practical for me. Firstly, I always run production cases to the cloud, where I do not have control over the source code. Secondly, I am not sure if the programs generated from these source code can run in parallel.
For simplicity, I prefer to do the final processing in Honeybee. But I will try these code anyway, thanks.
Thank you for pointing out the hack. I will definitely take this route for now.
As for the official workflow, well, I do not want to endorse a workflow with CFD calculation for every time step either. Typically we run CFD only for one or two worst case scenarios, with the intent to verify whether or not the AC system can cope with all the loads (convective + radiative).
What we need is an object to update the PMV calculation only for those time steps (or even one time step at a time) with a new temperature and air velocity values.
Note: CFD for every time step has been implemented in ESP-r, although it was for calculating the convective heat transfer coefficient, not for comfort. There is a “gopher” run, a quick CFD simulation, that runs every time step that will decide whether or not to call a full CFD run for that time step. If the gopher decides the flow regime is similar, then the full CFD run will not be invoked. EnergyPlus has a similar capability, though, the CFD code is not part of EnergyPlus. Just to point out that CFD for every time step is not unheard of. But I really do not see we are going in this direction.
I tried the example, but the workflow choked on a warning on Step 3, saying that the result has more than 8760.
This is strangely caused by the different year in the RunPeriod. The simulation calls for the TypicalAutumnWeek, which correctly gives the date and the months. But the year was set to be different, making the simulation runs for more than 8760 hours.
Is this only in my machine? Any thought on this?
In the mean time, I am setting a different period for the simulation.
Thanks
That results from a bug in OpenStudio version 2.7. We recommend that people use OpenStudio 2.5 instead of 2.7 if they need a completely bug-free experience with Honeybee. Hopefully, we will be able to say that OpenStudio 2.8 is also bug free when it is released.
