Hi Ladybug Discourse
We are two students from Denmark currently working on our bachelor project.
We have been doing some in our mind “complicated” outdoor microclimate simulations
and have run in to an issue regarding the “HB UTCI Comfort Map” which gives us the following result
(picture 1). There seems to be an error with some of the pixels on the map
as the values don’t seem to correlate with the neighboring values.
There appears to be a sort of bleeding or slipstream of different MRT values. We also ran
a simple scenario with just a single building which had no issues. We looked into the geometry
and capped all holes that appeared when creating the “HB Room”, however, this did not fix
the problem. We were wondering if anyone had the same problem or would be so kind as
to look into our script and let us know if something was put together in the wrong way.
As a side note we found that the shadows cast by the buildings were considerably longer
using this component compared to the ladybug MRT component. Does anyone have a note on
this or an explanation as to why this happens?
Measuring height is set to the same height for both.
mrt_issues.gh (280.9 KB)
Rasmus and Lucas
Advanced case with the “bleed”
Simple case without the “bleed”
Hi Rasmus, Lucas,
Honestly I’m not sure what’s causing the bleed, I simplified your script a bit and reran but I didn’t get the bleed effect you’re showing.
Looking at your script, I’d advise simplifying your inputs. Firstly, you’re modelling rooms from closed meshes for the buildings. Usually for this type of external comfort type analysis I model the buildings as shades in HB inputting simplified polysurfaces. I believe the shade type has a surface temperature equal to air temperature, and working from simplified polysurfaces reduces the number of surfaces in your simulation (and therefore simulation time). The meshes you’re inputting have a lot of surfaces that could cause slowdown.
I’m not exactly sure how the UTCI Map runs input rooms, but I assume it’s the same as any other energy plus simulation - which means you’ve got unconditioned rooms, with lots of surfaces to simulate heat transfer for, and potentially internal gains set to default office type. Important to consider how the temperature for each surface is being generated, and if you’ve got rooms with abnormally hot internal temperatures that might give inaccuracies in terms of their external surface temperature.
From what I understand the ground surface temperature is a key factor of external comfort that the UTCI Map is intended to simulate. The ground surface that you’re sending for simulation doesn’t have multiple top surfaces to take advantage of this. Something like this would do:
I’m also not sure how UTCI map handles the run period for the simulation - I ran it for a whole year and then post processed the results, but that might result in the simulation taking much longer than needed. For me it took ~2h to run on a pretty high end laptop.
Here’s a link to my edited version of the script - internalising the breps of the converted meshes pushed it over the upload size limit.
Thank you so much for your time! It seems to be working for us now.
We initially simplified the meshes to improve simulation times, but then we got the bleed. That is why we tried a more complex model. However, it looks like a very good solution you have created by simplifying all the meshes. Also, we did not know about the ground having to be split up to utilize the utci map, so thank you for that as well.
Again thank you so much for looking it to our issue