I just wanted to post this for @ayezioro that he knows how the comfort mapping recipes work if he wants to test them.
The ReadMe explains a fair amount about what is going on under the hood but I left a few things vague because they are going to change in the future and I am not positive that I will remember to update the docs. In particular, there are several things to be aware of about how the new maps compare with legacy:
- Given that I saw many legacy users would get lost connecting/managing the different inputs across the thermal mapping components, I decided to wrap the whole process into the recipe. So the energy simulation happens in the recipe and it occurs while the other calculations of the recipe are happening (rather than being a pre-step before the recipe). This results in performance improvements when all that you need is a comfort map but I realize that it hinders the use of the energy simulation for purposes other than comfort mapping. If it becomes a pain point, I can add an alternative version of the recipe that works from an sql file instead of the model and epw. But I would like to know your thoughts here.
- The new recipes are trying to better-capitalize on the fact that Honeybee is an interoperability hub between EnergyPlus and Radiance. So, even though the energy properties are what dictate the thermal conditions, you need to assign HB-Radiance sensor grids to tell the recipe where you want the map to be.
- The shortwave calculation is a huge improvement over legacy in that we now use Radiance to compute the amount of shortwave solar irradiance that falls onto each sensor point. This allows us to account for shortwave reflections across the model (legacy only accounted for the ground reflected shortwave). It also means that we better-account for the solar position in the direct calculation.
- At the moment, the longwave calculation is not as good as legacy and this is only because I haven’t gotten the time yet to implement the process of using Radiance to compute view factors. I should hopefully be able to get this done in the next month or so but just bear in mind that the longwave MRT is currently just the zone-average MRT for all points in a given room. Or, if the points are outdoor, the longwave MRT is that of a person standing in an open field.
1 Like
Thanks @chris!
I’ll start testing the cloud recipes.
Just to let you know that i already started to test the “local” ones.
First thing i thought is that i am impressed by the much simpler process. At first i didn’t understood how did you do. Then i read that both E+ and Radiance are happening in the components.
I’m very happy that you started to implement this.
So far i can’t tell if it is really important to have the energy simulation separated from the comfort. For what i see now it is fine to have them separated. But i need to test better to draw a more educated conclusion.
For now i like very much as it is, is quick (relatively), is simple, is clear. I would enhance a bit the explanations and concepts. For instance TCP, HSP, CSP, important to assign them to academic concepts, give references and such.
Thanks again for the heads up!! And keep going strong.
-A.
Thanks, @ayezioro,
Glad to hear that you like them so far and I am glad that you agree the simpler process is a benefit.
For the names of the metrics, I have to admit that I don’t have a stellar bibliography of sources to point to but I think this might be because there isn’t any other software that I know of that does indoor comfort mapping like this. I know that Tarek Rakha used the “Thermal Comfort Percent” metric in his PhD thesis, which was on outdoor thermal comfort mapping, and I thought the name of the metric was really clear. So that’s probably the best reference that I can point to.
Maybe it also helps to know how we phrased this to the SBIR committee when we were applying for a grant to reimplement the comfort maps:
By evaluating the acceptability of thermal conditions over all of the occupied hours of the simulation, three additional spatial thermal comfort metrics will be calculated:
- Thermal Comfort Percent (TCP) - is the percentage of occupied hours that meet the comfort standard.
- Heat Sensation Percent (HSP) - is the percentage of occupied hours that are warmer than conditions that meet the comfort standard.
- Cold Sensation Percent (CSP) - is the percentage of occupied hours that are colder than conditions that meet the comfort standard.
It is worth recognizing that the past decade has included several attempts to define metrics that describe thermal comfort conditions across space and time, many of which have been modeled on annual daylight metrics like daylight autonomy[6][7][8]. However, there remains little consensus over these metrics and a number of them contain ambiguities that lessen their usefulness as a communication tool. The spatial comfort metrics above were chosen for three reasons: 1) There is relatively little ambiguity in their definitions, 2) the names of the metrics accurately describe what they measure, and 3) anecdotally, they have been found to be the most useful for communicating the results of microclimate maps in the current Ladybug Tools plugins. More metrics can be added in the future, particularly if there is a clear consensus from committees of experts on new, useful metrics.
[7] Jianxiang, H. (2013). Microclimate, Thermal Comfort and Urban Form. MIT Department of Architecture, Cambridge, MA: Doctoral dissertation
[8] Levitt, B., Ubbelohde, M., Loisos, G., & Brown, N. (2013). Thermal Autonomy as Metric and Design Process. CaGBC National Conference and Expo: Pushing the Boundary-Net Positive Buildings, (pp. 47-58). Vancouver
[9] Rakha, T. (2015) Towards comfortable and walkable cities: spatially resolved outdoor thermal comfort analysis linked to travel survey-based human activity schedules. MIT Department of Architecture, Cambridge, MA: Doctoral dissertation
Hi @chris,
I’m fine with the names and sources. I’m using, based on the Legacy version, mostly Thermal Autonomy (TA), with which i also live OK, reminding the Daylight Autonomy you mentioned above. The later is always a consensual one, while the comfort is still open or to be defined. Personally i prefer the TA because it has more purpose than the neutral TCP.
In any case i’m very happy you are “almost” wrapping the components. They will be very popular and beyond.
I foresee that comfort studies will be performed together with Energy ones. Each will support the other. The reason i mention this is to ask you if you have already some conclusions about simulation times when you run both of them together. How much of the EnergyPlus embedded simulations on comfort components repeat the processes of the "just’ Energy simulations? Can you estimate the time that will be “repeated” in the comfort simulations?
Not sure that my question is clear enough, hope yes though.
-A.
Hey @ayezioro,
Sorry for the late response. I have been busy working up to the release that should hopefully go out tomorrow.
The main issue with using “Thermal Autonomy” is that it has a published definition and, while this definition is vague and ambiguous, I think several people would say that the thermal autonomy output from the Legacy component isn’t really thermal autonomy. The ambiguity comes from the fact that Thermal Autonomy is supposed to be the percent of occupied time that’s comfortable BY PASSIVE MEANS ONLY. And it turns out that it’s extremely tough to have a clear definition of exactly what counts as passive. For example, is a ceiling fan passive even though it uses electricity?
With all this said, Thermal Autonomy is pretty clearly a specific flavor of Thermal Comfort Percent (you basically just take TCP and just tack the “passive means only” onto the definition). So, if you run an energy simulation without any HVAC system, then I think you can probably argue that the TCP metric that you get out of the Honeybee thermal maps is equivalent to TA.
But the way that I tried to compute TA in Legacy was probably not correct since I essentially counted “passive means only” as any hour when the HVAC didn’t run. And this is probably cheating because, in theory, I could run the HVAC intensely for one hour and not run it the next instead of running it normally for two hours. And both cases could have the 2 hours as comfortable. Yet I would get 1 extra hour of TA in the first scenario even though I didn’t really improve thermal comfort passively.
So I just found it’s a lot better to just not engage with a ambiguity of TA and stick to the much clearer TCP metric. And, if we use TCP, there’s nothing stopping you from coming up with your own definition of what counts as passive and using that to say that your TCP is equivalent to a certain TA value.
In any case, to get to the run time question: It isn’t necessarily true that the run time is longer. The steps of the recipe execute concurrently as long as you have more than one worker. In the tests that I have done so far, the energy simulation usually finishes before the Radiance simulation so, as long as you are running the comfort map with two or more workers, there will be zero addition runtime. I guess you can say that there’s more CPU-time but not any more wait time for you.
Hi @chris,
Thanks for this thorough answer.
I’m in the middle of a paper using TA definition. My “luck” is that it uses ONLY passive strategies as i’m talking about old buildings trying to understand their comfort potential.
In this sense i agree about what you say and for other cases i should be more careful about using some terms “lightly”. The TCP is more comprehensive and will draw less fire.
As for the calculations time, thanks for the explanation too. Clear now.
And lastly, very excited about the coming up release. You all are working so hard, but bringing a lot of good stuff to so many people. Thanks for that.
-A.