first of all thank you for your reply. Here below my answers point by point:
I’d recommend plugging in the driectNormalRadiation into the solar temperature adjustor as this will be much faster and will give you pretty comparable results (since the SolarCal method has been pretty close to the detailed mannequin in my experience).
I have used the directNormalRadiation as an input in the solar temperature adjustor.
The reason why the CPU is cycling when you use a detailed mannequin geometry is that it’s running a radiation simulation for each timestep of the period you have requested. Really, the mannequin is made more for point-in-time studies where you are trying to understand what parts of the person are causing the elevated MRT.
I have used this component to get the spatial solarAdjustedMRT (SAMRT) considering the hottest week taken from an .epw file in order then to calculate the outdoor UTCI of a district of about 1000x750 meters with a resolution of 5 meters:
It has taken two days: the very long time to calculate the SAMRT doesn’t depend by the performance of the pc. The result without considering the trees effect, based on the average values over the considered period is as reported below:
Then I used the same extreme hot week and a more little area with a resolution of 1 meters and trees effect (the yellow area in the first image) and the performances are very different: more memory used and a costant CPU usage.
The problem is that the LBseparatedata doesn’t allow to use this ammount of data:
Maybe I can solve this issue considering a low resolution (2 meters instead of 1 meter) or considering a single day instead of the complete extreme hot week. It is correct?
Another consideration: it would be great if there is a method to upgrade the performance considering a widely area with a good resolution!