Discussion of New Comfort Mannequin Features in Ladybug[+]

Wonderful community,

I am starting this issue to gather some thoughts on how we should implement the thermal comfort mannequin in Ladybug[+] since I will be be adding this in soon and it would be good to know what features should be designed in and what use cases people would like to use it for. Normally, I would post a topic like this in a GitHub issue but there are a number of questions here that could benefit from people’s knowledge of comfort literature and it would be good to have a wider community input. In particular, there are 4 things that I could use people’s thoughts on:

1. What should the source of the geometry be and how many geometry options should there be?

I was originally thinking of starting form the same comfort mannequins that we used in Ladybug legacy but I know that @AndreaZani905 has assembled a much better set of human geometries for his recent paper at the building simulation conference:
Annual Radiation Discomfort: A New Climate-Based Framework For Modeling Short-Wave Solar Radiation In Indoor Spaces
Andrea Zani1, Henry David Richardson, Alberto Tono, Stefano Schiavon, Edward Arens
BS2019_224_1_210338_Zani_2019-06-27_06-16_a.pdf (1.0 MB)
I know that you also did a good job, @AndreaZani905 , in making sure that the surface areas of the geometries match one another and match the assumptions of the PMV model, which makes them well suited as a set. If you are able to upload and share the geometries here, @AndreaZani905, I think we can use your work as the basis of the new comfort mannequins in Ladybug[+]. Also, if anyone has any other thoughts on different types of human geometries that we should support, please feel free to share your thoughts.

2. How should the mannequin’s be subdivided for multi-node comfort models?

Even though it may be some time before we get complete multi-node thermal comfort models in Ladybug (like the Fiala model that was used to develop UTCI or the Berkeley Advanced Human Thermal Comfort Model), I know that we want to set up the comfort mannequins of Ladybug[+] to be able to inform these models. For example, you should be able to get the mean radiant temperature of the hands separate from the torso. I honestly don’t know much about the Fiala model so I had been planning to subdivide the mannequins according to the description of the Berkeley model in this paper. I am not entirely sure if the Fiala model follows the same standard of human subdivision but, if anyone has any insight on this topic, we would really appreciate your thoughts.

3. What file format should the geometry data be stored in?

The two options that really came to mind here are JSON and CSV. A hybrid approach between these two file types is also an option. Personally, I had been leaning towards a pure JSON representation since it is quick to parse in nearly all computer languages and it handles the hierarchy / subdivision of the different body components well (mentioned in the mote above). This said, I know that JSON isn’t always as human-read-able or editable as CSV but it’s also true that a list of vertices in a CSV isn’t going to be readable no matter what you do. In any case, I put this question out there in case anyone has a preference here or has ideas about how they might use the raw geometry data that influences this decision.

4. What methods for view factor calculation should be used?

For a while, I had been considering whether it was worth embedding certain types of view factor data with the mannequins (like unobstructed sky view factors for each of the geometry mesh faces). However, I think most of the cases where people want to apply the mannequin involve some type of shading and so information like this would just add to the file size without adding much value or calculation speed. I had also considered for whether it is worth using EnergyPlus’s View3D utility to calculate view factors between the mannequin faces and interior surfaces. However, I have been leaning towards using Radiance for all view factor and shortwave solar calculations involving the mannequins after understanding the insights of @sarith 's recent paper at building simulation:
A Critical Evaluation of Radiance as a Tool for Calculating Radiation View Factors.
Sarith Subramaniam, Sabine Hoffmann
BS2019_238_5_210617_Subramaniam_2019-06-24_17-27_a.pdf (811.0 KB)
@sarith , if you have any further recommendations here, they would be great to know and if anyone else has any thoughts in this area, please post them.

Thank you all!


This is all looking really good, it’s great to see how much more advanced the new thermal comfort features in ladybug+ will be. I generally agree with your reasoning here, but have a couple of additional thoughts on your last two questions.

/3. I second using JSON for storing the view factors. It seamlessly transitions between languages, and has the critical feature of being built for the web. I know that there’s a handful of us in the LBT development community that are already using the python modules with cPython (for numpy/pandas integration) and JSON is the best way to store, access, and port data in these cases. Additionally, it’s nice to have the comfort geometry features consistent with honeybee-json.

I also agree that the idea of embedding view factors with the mannequin file would serve just to unnecessarily increase the file size. I’d add that from the perspective of overall programming robustness, I think it’s generally better to rely on functions to compute additional object data, rather then assigning it as properties whenever possible. This reflects a more ‘functional programming’ approach rather then OOP-style, which tends to be more robust as it prevents mutations/side-effects caused by forgetting to update object properties.

/4. Based on my understanding of Sarith’s paper, View3d calculates all surface view factors involved in the scene, and doesn’t use faster probabilistic ray-trace method? Definitely seems like Radiance would be better.

In addition to being faster, I think it’d be generally useful for Honeybee to expose Radiance-based view factors as a separate function, as there’s a couple of non-daylighting specific uses for it. Thermal comfort in this case, but also it can be useful when generating 2d images from 3d scene geometries. Personally, I’ve always been intrigued by the idea of using view factors to automate the “decomposition and recomposition” of building geometry zones for daylighting and energy simulation at scale as implemented by my old energy lab director at P+W: BIM-Centric-Daylight-Profiler-for-Simulation-BDP4SIM-A-methodology-for-automated-product-model-decomposition-and-recomposition-for-climate-based-daylighting-simulation.pdf. That link shows the paper for daylighting, but I recall there’s a paper floating around for energy model recomposition/decomposition as well.

I’ll leave it to the radiance/comfort experts to provide more insight into your other questions.