Any reasons why this script fails when trying to set up annual daylight simulation from faces only (i.e. no rooms)?
Works fine if a room hierarchy is used.
EDIT: looks like honeybee_radiance.lightpath module needs a room.
test_faces.gh (71.6 KB)
Hi @ao,
The annual-daylight recipe was recently changed. I see that I forgot to add some code I had lying around for cases where a grid has no light path. If your model is room based the light paths will be added automatically hence why it failed for your model.
I think it should work in Grasshopper now if you update the core libraries with the LB Versioner component. I am unable to test it inside Grasshopper right now, but it works when I run it outside.
Hi Mikkel,
I think I’m facing a same issue as the one reported by ao. The error log reports an issue with the light_path Key within the grid, so it looks the same. However, unlike ao, his code doesn’t work for me, with rooms or with face geometry…
I’ve tested other recipes, such as annual irradiance and annual glare, and it all went well, so that rules out issues with the geometry.
Here is the log from the component:
daylight_error.txt (8.5 KB)
Thanks for the help!
edit: just confirmed that the issue is related to the latest code. Downgrading to version 1.5.7, I don’t see anymore the Preparing Multiphase error. It appears that the code is trying to run the Multiphase, even when there is no light-path, which the code detected earlier.
Hi @pmcmm,
I can see by the line numbers reported in the errors that it’s not using the latest version of honeybee-radiance. Can you run LB Versioner again, and then check what version of lbt_gh you have in Honeybee Check Versions?
Hi Mikkel,
I’ve done what you asked, here is the result using ao’s script:
I’m on version 1.5.14, which was released 2 days ago. Your reply above is 1 day old, it possible the update didn’t go through?
You are right that the update is not in 1.5.14, but in the development version that you should get when you run LB Versioner. If that is not the case, then I think we need @chris for this.
ok great, at least we found the source of the problem. Indeed, it seems I don’t get access to developer’s version through versioner. Wouldn’t it be easier just to do a new release with the bug fix?
Thanks for the fast reply Mikkel!
I’ve manually copy pasted your code review into my code following this commit:
Unfortunately, it didn’t fix the issue, the light_path is being requested from other classes, here is more info (from 1.5.14):
error.txt (5.8 KB)
yes, this fixes it! BTW in the latest release 1.5.15 your fixes are already integrated, no need to mess around with the code. Great!
oh, found another bump on the road, now on version 1.5.17. So right now the daylight is running, I get results from the component, but the .ill files are not written on the disk. See the screenshot below:
No errors coming from the component this time. Is this still a leftover from the light_path code change?
Hi @pmcmm,
The results are in __static_apertures__/default/total but they are stored as .npy (NumPy) files. This is one of the recent changes of the annual-daylight recipe.
oh, I see. That way it reduces the amount of time lost converting the .ill into a numpy array, smart 
Yep, this one was my fault. There was a dependency conflict across the LBT core libraries, which was causing the Versioner to revert to some older versions of some of the libraries. I fixed it yesterday and it should all be good going forward.