My question is, if I add as input not only the Tdrybulb from EPW but also the surface temperature from OpenStudio simulation, how does the component consider this input?
I try to explain myself better. I have for exemple this type of geometry:
I simulated 3 scenarios for understand how the component consider that input, which are:
Scenario 1: only Tdrybulb as input
Scenario 2: Tdrybulb + all face_outdoor_temp from FaceResult component (OpenStudio simulation)
Scenario 3: Tdrybulb + only selected faces that are in front of the grid points from face_outdoor_temp (OpenStudio simulation)
Another question related to this topic. If I have an urban district, how does the component consider the temperature of the different surfaces/ground? Does it average all temperatures or does it somehow recognize the surfaces adjacent to the grid points in space?
Basically, it’s scenario 1 if you don’t have your surface temps (and therefore are assuming surrounding surfaces are temperature of ambient air).
If you do have surface temperatures, you can calculate an average of the different surfaces temperatures weighted by the view factor, from the location at which you are calculating the MRT. This makes more sense then your scenarios 2 and 3, since you’ll notice the inputs for the OutdoorSolarMRT components don’t include the raw surface geometries. Therefore it has no way to understand surface geometry relationships, you have to precompute the surface temperatures beforehand to account for such geometric relationships.
Thank you @SaeranVasanthakumar.
The OutdoorSolarMRT component as input has sky_exposure which relates the grid to the context thanks to HumanToSky component. I thought this input took into account the sky view factor.
In the following image you can see the results of two outputs: the ground colors correspond to the legend and this data cames from the ViewPercent component, while the ground numbers came from the HumanToSky component. The results are equal.
The sky_exposure parameter will account for the changing sky exposure, but doesn’t account for how the surface temperatures of those buildings impact the MRT. Thus the “surface geometries” refers to surfaces blocking the view to the sky, including the ground), but not the sky “surface”.
For example if you had a person sitting beside a metal wall with a high surface temperature, the sky exposure parameter will account for how much the sky is blocked by that wall - but won’t account for the geometric exposure of the individual to the hot metal wall. It seems that in this component, the way to account for the wall is to average all surface temperatures, weighted by view factor, into an hourly data collection, and use that as a _surface_temp input.
Hey Guys, I hope you don’t mind that I moved this to a new topic as the old thread where this was being discussed was for the legacy plugin and you are using the new LBT plugin.
All of @SaeranVasanthakumar 's responses are correct. The Ladybug components for MRT do a decent job of accounting for sky/sun heat exchange but they have limits in that their means of accounting for surrounding surface temperatures. W should hopefully be rolling out some honeybee microclimate-mapping components soon, which will use EnergyPlus surface temperatures to give a more accurate assessment of long wave MRT.
