Occassional Image Based Simulation "failed to read results"

Occassionally my Image Based Simulation will fail for no apparent reason. I don’t think it’s the geometry or materials or RAD parameters or the way I have things configured, because the same render will usually work at a different time. Sometimes I’ll restart Rhino+Grasshopper and sometimes I’ll just delete the C:\ladybug\xx\imageBasedSimulation\ folder, and usually it will work again, or I’ll do a different render and then try the one that failed, and it may work.

I found this because I was doing renders one after the other and only changing the sun angle (date/time) of the Climate Based Sky. Every now and then, one will fail. Then I restart/clean and try it again and it succeeds.

It’s not a big deal when it’s a low quality render, but it really sucks when it’s a high quality render :grimacing:

Do you think it could be a caching problem with Ladybug or Rhino or a Radiance problem?

I’ve copied the files for a failed case up to Google Drive in case it helps to pinpoint the error:
https://drive.google.com/file/d/1Nce-a0f_xcmIcruMgvI9bstc9ooyNhj4/view?usp=sharing

@sarith , it’s the same office geometry and site that I’ve been posting in other threads.

Hi @delrocco, I think Mostapha, Chris or Abraham will be able to answer that. I usually stick to commandline Radiance. Btw, you can always launch the simulation from outside of Grasshopper by running the .bat file that is created. That way, at least you’d know if the error is from Gh or Radiance.

I didn’t know that, thx!

This is happening because rpict has reported a 2_0" warning as a new line in the log file. Not sure why this is happening but it has to do with Radiance not Honeybee. When Honeybee parses the log file it assumes that an error has been reported.

image

I made the parser more relaxed and changed the error to be a warning. This change should address edge cases like this as well as the issues with Accelarad non-standard reporting.

This was a couple weeks ago, and I’ve worked on 2 other projects since then, so I’m a little fuzzy about this… but I think I may have been mistaken about my quote above.

I think what was happening was that I would make a configuration change in my scene, which would run a MSH2RAD component, and according to what @sarith found, we have to do a manual post-process search+replace in the mesh and material .rad files when that component ran. We weren’t sure if that (.rad file corruption) was happening because of my scene or a bug in MSH2RAD, but I believe it was the later. I actually wanted to attempt to fix that bug (if it is one) when I got time as my first contribution to Ladybug Tools.

Anyway, if I didn’t do the post-process search+replace when doing my rendering, then that would trip Radiance with that error I believe. And that corresponds to what you found in the log.

1 Like

Thank you for the clarification. I fixed the issue that you mentioned in the other topic. That was an issue with parsing Radiance materials which doesn’t really have to do much with rpict error logging which was the issue here. In any case you should now be able to run the whole workflow with no issues. :crossed_fingers:

1 Like