My first post here, many thanks for creating this lively forum.
I am using Ladybug for calculation of the UTCI, using the LB UTCI Comfort component. The mrt input for the component is calculated by the LB Outdoor Solar MRT component.
I would like to gain some insight into the way the MRT is being calculated by the LB Outdoor Solar MRT component. More specifically, I would like to understand how the MRT is derived, if we don’t enter any material properties for the surrounding context (i.e. buildings)?
In case of the ground, there is the possibility of entering the ground reflectivity (ground_ref). However, in case of the remaining context surfaces (buildings), this option is not available. While I understand that for the _surface_temp input a simplified assumption (“…outdoor dry bulb temperature is used when such surface temperatures are unknown”) is made, I am wondering if this is sufficient for the MRT calculation without entering other additional parameters (at least such as surface reflectance, emissivity, etc)?
Are there any assumptions on default values made here, or is this being left out of the calculation altogether?
PS: I am aware of the possibility of using the HB UTCI Comfort Map based on EnergyPlus, taking to account material properties - understood that this would be a better option for the surrounding context MRT. However, at this point I would like to leave this option aside and explore the UTCI calc., based purely on Ladybug - its calculation methods, underlaying assumptions, limitations etc.
When I’m trying to get to the bottom of the exact calculation for an output it’s usually necessary to go down into the code. It’s a bit of a rabbit hole but hopefully useful for you.
For LB Outdoor Solar MRT if you go to the LB primer page for it, there’s a link to the source code.
That will take you to the code being used in the grasshopper component here:
The code in the grasshopper components will reference code from the SDK, in this case the key method is
from ladybug_comfort.collection.solarcal import OutdoorSolarCal
Then clicking on the source code for OutdoorSolarCal, for this particular method things get a bit more complicated, as the code is using a method imported from elsewhere to do the key calc:
result = outdoor_sky_heat_exch(t_srfs, ……
When you look at the source code you can see how the actual calculation is being carried out.
Cross referencing the original inputs from the component code and following them through should explain exactly what inputs are assumed and what the assumptions are.
Hope that I’ve written that out in a way that can be followed. Chris and the team have done a great job on the documentation of the code, if there’s something that isn’t explained in quite the amount of detail you need I find diving through the code is the best way to fully resolve what you’re interested in.