Any idea why I would be getting this error - Solution exception:Attempted to divide by zero?
It only occurs if the distance from base is more than 0 (which it needs to be). The component is up to date, and I’ve tried reinserting it onto the canvas.
So this is really strange. I upgraded to LB legacy ver 0.0.69 and restarted Rhino. The view analysis then works.
However, opening another Grasshopper file with some old ver 0.0.67 components causes BOTH grasshopper scripts to then fail. If I switch back to the 0.0.69 I get the original “Attempted to divide by zero” error. Could this be due to the Ladybug_Ladybug component?
The fact that we had a “Ladybug Ladybug” component in legacy created all types of weirdness. Whatever, Ladybug_Ladybug component last ran will determine what version of the “legacy core libraries” are active across all of the Grasshopper documents that are open for the Rhino instance. And it looks like there was a bug in version 0.0.67. So just stick to one version of the components whenever you work with legacy.
… Or you could just upgrade to the LBT plugin. There’s no more Ladybug_Ladybug and, for LBT, there will only ever be one version of the core libraries loaded per Rhino session. Also, the sky view component in the LBT plugin runs in ~1/3 of the time of the legacy component (mostly because we were smart about what data we dump into the Grasshopper UI). So I really recommend upgrading.
Thanks Chris. I will check out LBT.
I thought I had removed any old components but still getting an error. Do you know of a way to find the old components? The update components doesn’t work for clusters I believe. And things like Metahopper return LB components as generic python components.
Sorry quick clarification.
Ladybug Tools is the new version of LB which uses the same methodology correct?
And Ladybug Plus, which uses recipes is apart of Pollination Cloud, correct?
I just want to make sure before upgrading to LBT because when I looked into sunlight hours with Ladybug Plus, @mostapha and I came to the conclusion that for my specific needs the Legacy version was more applicable.
Sorry if I missed the announcement about this.
Hey @PaulWintour ,
The best way to remove old components in Legacy is just by running the “Ladybug_Update File” component. That should upgrade any of the old components on a canvas. I think that we eventually got the Update File component to update things inside of clusters (since we got the LBT equivalent component to do so). But I am admittedly not 100% sure.
No worries about missing the announcement. You can catch up here:
To clarify, the Ladybug[+] package eventually metamorphosed into LBT Ladybug. But it has undergone a lot of revision since the last time that you used it. If you are talking specifically about this issue here, I think that any sun position discrepancy at this point is entirely the result of the minuscule differences in sun positions from year to year. Ladybug uses 2017 to generate its sun positions so, if you are going to do a comparison with any other software, make sure that you match the years.
Thanks Chris. Yes I saw that announcement. I was just confused as it didn’t mention LB+ and as you say, a lot has changed.
The issue I was referring to was to do with the last vector of an analysis period (as per the link). From memory, the old analysis period component took the liberty of removing the last vector. So I needed to specify the hour/day/month manually in the sun path component to override this. But it looks like this has been updated with the latest LBT analysis period. Is this correct?
Comparing LB Legacy with LBT there does appear to be a discrepancy between sun vectors (21 June, 9-3pm). You mentioned LB used 2017 as the year. Is this for both or does LBT use a different year?
Hey @PaulWintour ,
I am not sure whether you want the last sun vector included or not but, whichever one you want, you definitely don’t need to edit any source code in the LBT plugin. Now, you can plug in whatever hoys_ that you want sum positions for and these can either include or exclude a certain hour. It looks like the default behavior with the analysis period is to include the hour in the LBT plugin:
… but, as I said, you can easily change that with a little list editing.
I checked and it seems the latest legacy plugin is using 2018 as its base year. But, even when I match it to 2017, there’s a very minor difference because there are some places in the LBT plugin where we added a few more decimal places, particularly to the coefficients used to correct for atmospheric refraction. So, a difference of 1% of a single degree (or 2.4 seconds of a day) is to be expected when we switch to using 5 significant figures for a coefficient instead of 4, for example.
But, for practical purposes, the change in those coefficients is less than the change in sun position from year to year. So, unless you are using these sun positions to calibrate the time of an atomic clock for the space station, you are going to be ok using either legacy or LBT.