I am trying to use the UTCIMap component (v1.9.0) to resolve the UTCI spatially for a sample project site. However, I find that whenever my analysis period is less than a month, the simulation runs but gives NaN values. However, if it is over a month, the results are normal. I have uploaded a screenshot showing the successful results’ visualisation, as well as two screenshots of the failed results’ error and NaN values.
Here are the model and the GH script. Would be very grateful if anyone could help.
20260223_UTCI_test.3dm (243.7 KB)
OutdoorComfort_UTCI_testing.gh (82.6 KB)
A bit of an update, I’ve found that this issue occurs only under certain period of time under certain weather files. I however cannot quite tell what’s wrong with those weather files after comparing the problematic periods with those that are okay, as well as with weather files that are ok.
I feel that the issue may be more related to the choice of weather file, rather than whether the period is over a month or not.
P.S. I have already updated ladybug tools with the versioner and also pollination.
I’ve tested a few weather files using this analysis period “7/31 to 7/31 between 8 and 18 @1”. Here is what I found.
AUS_VIC.Melbourne.948660_IWEC.epw
works fine
CAN_BC_Vancouver.Harbour.CS.712010_TMYx.epw
works fine
CHN_Hong.Kong.SAR.450070_CityUHK.epw
works fine
CHN_Shanghai.Shanghai.583620_CSWD.epw
works fine
CHN_SH_Shanghai-Hongqiao.Intl.AP.583670_TMYx.epw
works fine
CHN_SH_Shanghai-Pudong.Intl.AP.583211_TMYx.epw
nan
HKG_KOW_Hong.Kong.Obs.450050_TMYx.epw
works fine
HKG_NT_Ta.Kwu.Ling.450320_TMYx.2004-2018.epw
works fine
JPN_TK_Tokyo.476620_JGMY.epw
works fine
JPN_TK_Tokyo-Chiyoda.476620_TMYx.epw
works fine
USA_NY_New.York-Downtown.Manhattan.Heli.720553_TMYx.epw
works fine
Hi @homan95,
Thank you for running additional tests.
In short, the recipe saves the various NumPy files using the lowest possible data type without compromising accuracy, in order to reduce disk space usage. In your case, the issue occurred during the UTCI matrix calculation. The air temperature file used in that step was saved as float16, which led to overflow issues later in the NumPy calculations.
I suspect the annual/monthly analysis worked because the same file was saved as float32 at that time (it now contains different data).
I’ve updated the code so that all files are converted to float32 during the calculation process to prevent this issue.
You should receive the fix within an hour after updating your core libraries using LB Versioner. However, I recommend installing the newly released 1.10.0 first, and then running LB Versioner afterward.
It appears to be working now, thank you!
