For some reason my Ladybug_Outdoor Solar Temperature Adjustor v0.0.69 component is breaking when I have a large analysis period. See attached file. If works from Jan 1 - Dec 4th, but if I go to Dec 5th or larger, it breaks. See attached gh file.2020-0820 outdoor UTCI from climate data.gh (540.0 KB)
Hi @LelandCurtis,
I noticed that the issue happens in the specific EPW you are using.
Tried with different ones and it works fine.
For debugging purposes (@chris) the error says:
Runtime error (ValueErrorException): math domain error
Traceback:
line 1565, in solInitOutput, “”
line 1222, in mainSimple, “”
line 1542, in script
In any case once you get it work you can expect an error in the LB_OutdoorComfortCalculator since the inputs have different lengths (8760 values VS the length of your chosen period). You need to do some cleaning there.
-A.
Thanks @AbrahamYezioro, that fixed it. It works fine for another weather file. I was only using the analysis period to find the bug, but thanks for the heads up. @chris let me know if you figure out why it would be breaking for some weather files.
Thanks guys!
It was a weird floating point error in the sun position calculation that only has a 1 in a billion chance of happening for a given sun position. But you won the lottery!
I just pushed a fix to catch the error:
And here’s your fixed file:
2020-0820 outdoor UTCI from climate data_CWM.gh (542.1 KB)
1 Like
Hello Chris, I’ve been getting the before mentioned bug. I’m still baffled, I tried updating as instructed but I’m still getting an error message. It has something to do with different EPW files, I get around 40% of them to work fine, and 60% give back the error which I copied below.
Copied from the “Ladybug_Surface Hourly Solar” readMe!:
Runtime error (ValueErrorException): math domain error
Traceback:
line 1565, in solInitOutput, “”
line 131, in main, “”
line 210, in script
Any help kindly appreciated.
Hi @Gspahr,
- Please update your installation using Update_Ladybug
- update your components in your Gh definition
- Make sure to use the latest Ladybug_Ladybug Component.
Thanks for posting the right instructions, @devang .
However, I can see now that this issue is probably going to keep coming given the number of posts that the forum has gotten about it in the last week or so. The rise of this issue seems to have coincided with a Rhino update on July 17 that possibly updated the IronPython that ships with Rhino and consequently broke this sun position calculation code that had been previously working for the last 7 years.
In any case, this all seemed to merit a change in the components on Food4Rhino so I just updated the .zip file for “Ladybug 0.0.69 and Honeybee 0.0.66 [Legacy Plugins]” to have the fixed components. So people installing from Food4Rhino going forward should have the fix. And, if anyone needs to identify whether their Gasshopper script has the fix, the version of Ladybug_Ladybug should be from August 20 2020 or greater:
Thank you very much @devang and @chris.
Now that I have solved the issue I can see plain as day where and why I was failing, which could be useful for anyone else getting this error (and likely a n00b like myself 
).
My mistake was at step 2, I was only updating without replacing the broken component on my canvas. After that everything came back on track!
Hi Chris -
I spoke with the developers about this and there hasn’t been an IronPython update recently. Could there be something else that we should be looking into?
-wim
Thanks for confirming @wim . It may remain a mystery what actually triggered the rise of this issue but it seems it resulted from some change in the way floating point tolerance was being treated. I just know that previously, we were able to avoid cases of the IronPython math module performing an acos (ArcCosine) operation on a value greater than 1 but, now, we get cases of trying to perform an acos operation on 1 + Python floating point tolerance.
In any case, looking through the ladybug commit log, I would like to take back my speculative guess that it might have been linked to the July 17 Rhino update. From commits like this it seems that I was actually trying to fix part of this issue back in May. And I think the reason why everyone suddenly reported the error now is that we did a stable release of Ladybug Tools on Food4Rhino a little bit before July 17. So I think we can rule out that July Rhino update and maybe I should also note that this error never would have happened if I knew how to write good, robust code 7 years ago 
.
In any case, it’s all fixed now and maybe we can just let the issue rest.
1 Like