"Solution Exception: Invalid result folder" on AnnualDaylight

grasshopper honeybee
, ,
22

Thank you Chris. Apologies for my late response. I upgraded to LBT 1.2. However the BSDF modifier still creates issues with the Annual Daylight component and the Point View analysis. All the components are up to date.

With Point view analysis, no images were created for luminance.
With the annual daylight component, this is the error I get when I use a BSDF modifier.
"1. Solution exception:The recipe failed to run with the following summary:

Scheduled 435 tasks of which:

  • 147 ran successfully:
    • 1 CreateDirectSky(…)
    • 1 CreateOctree(…)
    • 1 CreateOctreeWithSuns(…)
    • 1 CreateRadFolder(…)
    • 1 CreateSkyDome(…)
      …
  • 274 failed:
    • 137 DirectSkyLoop(…)
    • 137 TotalSkyLoop(…)
  • 14 were left pending, among these:
    • 4 were missing external dependencies:
      • 1 AnnualDaylightRaytracing(…)
      • 1 AnnualDaylightRaytracingLoop(…)
      • 1 DirectSky(…)
      • 1 TotalSky(…)
    • 6 had missing dependencies:
      • 1 CalculateAnnualMetrics(…)
      • 1 LetAnnualDaylightFly(…)
      • 1 MergeRawResults(…)
      • 1 OutputMatrixMath(…)
      • 1 _AnnualDaylightRayTracing_5cabed59Orchestrator(…)
        …
    • 4 was not granted run permission by the scheduler:
      • 1 AnnualDaylightRaytracing(…)
      • 1 AnnualDaylightRaytracingLoop(…)
      • 1 DirectSky(…)
      • 1 TotalSky(…)
        This progress looks :frowning: because there were failed tasks
        Use the report_out attribute of recipe settings to see a full report."

21-0820 cleaned up.gh (129.9 KB)Doubleclearwithwhitefrit_50.xml (136.4 KB)

23

@JG ,

Glad to see that you are using a newer development version of the plugin. I cannot run your file as you didn’t internalize any of the geometry but I just ran a test and I can see that the BSDF capability of the recipes has been broken in the latest development version of the plugin. I’m working towards a fix now. In the meantime, you can use the “LB Versioner” to go back to version 1.2.76 of the plugin and the BSDF modifiers will work for that version.

1 Like
24

@JG ,

So I just merged a fix that should ensure BSDF modifiers work for all of the latest recipes except point-in-time-view. We’re working on this last case but your original error with the annual-daylight recipe has been addressed.

25

The point-in-time-view recipe has now also been fixed. So this bug is no more!

1 Like
26

This is great, thank you Chris!

27

Hi all,

Thanks for this useful post.
I am having the same issue but I can’t find out why. The strange thing is that it was working fine with no errors and suddenly this started happening.
This is the message I get from the report:

image
image1380×675 103 KB

Can someone please help? Much appreciated!

28

You should upgrade to LBT 1.3. You’ll see in the Release Notes that we have much better reporting for when the simulation fails like this. You’ll get a report like what @JG posted. There’s also a high chance that your issue was already solved thanks to bug fixes in the LBT 1.3 release.

29

Unfortunately just installed 1.3 and got a similar error while running one of the sample files (comfort_mapping.gh)

      {0;0}
  1. Runtime error (PythonException): The recipe failed to run with the following summary:

Scheduled 27 tasks of which:

  • 16 ran successfully:
    • 2 CopyGridInfo(…)
    • 1 CopySunUpHours(…)
    • 1 CreateModelOccSchedules(…)
    • 1 CreateOctree(…)
    • 1 CreateOctreeWithSuns(…)
      …
  • 3 failed:
    • 1 CreateDirectSky(…)
    • 1 CreateTotalSky(…)
    • 1 RunEnergySimulation(…)
  • 8 were left pending, among these:
    • 1 were missing external dependencies:
      • 1 RunIrradianceSimulation(…)
    • 6 had failed dependencies:
      • 1 AnnualIrradianceRaytracing(…)
      • 1 ComputeTcp(…)
      • 1 LetPmvComfortMapFly(…)
      • 1 RunComfortMap(…)
      • 1 _AnnualIrradianceEntryPoint_6d4da049Orchestrator(…)
        …
    • 4 had missing dependencies:
      • 1 ComputeTcp(…)
      • 1 LetPmvComfortMapFly(…)
      • 1 RunComfortMap(…)
      • 1 _Main_6d4da049Orchestrator(…)
    • 1 was not granted run permission by the scheduler:
      • 1 RunIrradianceSimulation(…)

This progress looks :frowning: because there were failed tasks

Use the report_out attribute of recipe settings to see a full report.

Traceback:
line 171, in script

30

Hi Chris,
Thanks so much for the fast reply!! I will try upgrading.
Can I just ask, if a simulation was set up with say version 1.2, and the components are then updated to a later version, should the simulation be run again? Could there be inconsistencies between previous results (from when the script was working) and new results because of the upgrade?
Thank you!

31

@rastermadre , It looks like there’s something incorrect about your Model input based on the tasks that are failing. Did you use the LB Sync Grasshopper File to sync the versions of the components on your canvas to your new 1.3.0 installation? It’s all running correctly on my end:

image
image2436×1110 270 KB

@mica.micillo , the results should not change significantly from one version to another. It’s always possible that there could be a small change because we fixed a bug between the two versions or there was a change in the underlying simulation engines to make the calculation faster or more accurate. But these shouldn’t be big enough to merit re-running simulations.

1 Like
32

Thank you for your response!

I am using the original file in ‘samples’, rhino model in meters,
I checked that versions of Radiance, OpenStudio are conform the compatibility matrix
I’ve added the Sync Grasshopper File component, still no luck, still failing:

image
image1140×563 29.3 KB

looks like the error happens around here:

log

2021-09-09 13:12:42 INFO: Started running ParseSunUpHours…
2021-09-09 13:12:43 INFO: — Logging error —
2021-09-09 13:12:43 INFO: Traceback (most recent call last):
2021-09-09 13:12:43 INFO: File “c:\users\daria ivanciucova\ladybug_tools\python\lib\site-packages\honeybee_radiance\cli\sky.py”, line 329, in sunpath_from_wea_rad
2021-09-09 13:12:43 INFO: run_command(cmd.to_radiance(), env=folders.env)
2021-09-09 13:12:43 INFO: File “c:\users\daria ivanciucova\ladybug_tools\python\lib\site-packages\honeybee_radiance_command_command_util.py”, line 78, in run_command
2021-09-09 13:12:43 INFO: raise RuntimeError(‘None zero return code: %d’ % rc)
2021-09-09 13:12:43 INFO: RuntimeError: None zero return code: 1

What else could it be?

Same error happens when running the annual_daylight.gh from sample files.

I apologise in advance if I’m missing something obvious, I am new to ladybug tools and grasshopper in general.

33

Thanks for posting more details bout the logs, @rastermadre . From that message, it is clear that one of the Radiance commands in failing and is returning an error that there’s been an invalid input for the command.

Looking even more closely at the message, I see that you have a whitespace in your username and I would bet that this is to blame. Can you try plugging in a folder_ for the simulation settings that does not have a white space in the path? I’ll continue to see if I can recreate the issue on my end and push a fix if I can.

1 Like
34

You’re right! it’s the damn whitespace! Thanks a lot! Everything running smoothly now :mechanical_arm:

35

Ok. I just pushed some fixes for the whitespace issue. You can get the fix right now using the “LB Versioner” but I think this is a big enough problem that I’m also going to update the Food4Rhino installer.gh to include the fix. If you wouldn’t mind testing everything on your end to make sure the fixes are working, that would be a big help.

36

The installer.gh on Food4Rhino was just updated with the fix so you can use that if you don’t want to use the “LB Versioner”.

37

Brilliant, thank’s so much for a quick response @chris . Unfortunately, it’s still failing when running from an account with whitespace in the username, this time around TotalSkyLoop.

I’ve attached a log file that I’ve found in the simulation folder, if it is of any help?
logs.log (639.0 KB)

38

Thank you, @rastermadre .

That log file was VERY helpful. I just merged a fix into the core libraries that should address this case once and for all:

You should be able to get it with the “LB Versioner” within an hour or so. If you wouldn’t mind testing one more time and confirming that it all works, then I’ll update the Foo4Rhino installer (hopefully for the last time). Thanks again for reporting the issue and for sending over everything I needed to understand the issue.

39

@rastermadre ,
If I don’t hear from you by tomorrow, I am going to assume that the issue is fixed and I will update the installer.gh that is on Food4Rhino. Thanks again for all of your help, here.

40

@chris, sorry but still looks like it’s failing

logs.log (638.5 KB)

41

Thank you for your patience and for testing it again, @rastermadre . I finally was able to configure my setup in order to recreate the exact issue that you are having and I was able to test a few possible solutions.

To summarize the technical issue that was happening:
It seems that there’s an issue in Radiance’s rflumtx command in that it doesn’t pass the file paths in quotes to the rcontrib command that is running under the hood (resulting in the rcontrib command failing in spite of the input for the rfluxmtx command input being valid with all file paths in quotes). I might bring this up on the Radiance forum if @mostapha , @sarith and/or @mikkel think that this is unexpected behavior.

More importantly for now:
I was able to find a workaround that should work just for the LBT recipes. So I am now very confident that I fixed your original error with this commit:

If you are willing to run the LB Versioner and test one last time, it would be appreciated but I feel confident enough to push the new fix into the installer.gh on Food4Rhino. Thanks again for all of your help here!

1 Like