I’ve noticed an error with the LB Sunpath component when solar time is true for locations with latitude -90 to 23 and 67 to 90. The analemma for noon becomes a wobbly curve, which affects both the 3D and projections options. Aside from this some analemma curves appear to be randomly split in two on occasions, either with or without solar time.
I am using ladybug version 1.10.1 and Rhino 7. I’ve also tested with ladybug 1.8.0 and the result is the same. I attach a grasshopper definition and a sample EPW here.
It looks like McNeel probably made some changes to how they compute interpolated curves. Nothing has changed on the Ladybug Tools side of things but I realize that using the solar time option causes the LBT core libraries to return an interpolated curve that essentially evaluates to an arc that wraps in on itself. So McNeel’s new methods must be struggling with this type of edge case.
Let me see if there is a better way to send the analemmas to Rhino’s side when using solar time.
I got the chance to dig deeper and it seems my initial thought was wrong. The issue has nothing to do with any changes made on McNeel’s end and everything to do with a floating point tolerance bug that has existed in the ladybug code for several years now. I would have thought that a bug producing such an obviously incorrect sunpath would have been reported earlier. But I see that it only affects sunpaths displaying solar time - specifically for solar noon in a few locations in the southern hemisphere and solar midnight in the northern hemisphere (if you’re above the arctic circle). I guess the number of people using the sunpath with solar time isn’t all that big to begin with so maybe that is how it managed to fly under the radar for so long.
In any event, I pushed a fix here:
… and it should be available via the LB Versioner component in an hour or so.
