"Solution Exception: Invalid result folder" on AnnualDaylight

I’m experiencing the same top level error ; although the logs reveal another symptom/cause?
PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: ‘C:\Users\swalt\AppData\Local\Temp\tmpn4k3pyhr’

Runtime error (ValueErrorException): Invalid result folder: C:\Users\swalt\simulation\DaylightTest\annual_daylight\metrics/da

Hi all,
Just solved the problem for my case → be careful to not give an absolute folder path to the “folder” input of the HB Recipe Settings (just as in the honeybee legacy), but simply a folder name (without space or slash), which will be saved in the same folder than the grasshopper file.

1 Like

Thanks @chris - I had a similar issue - appreciate your solution on this.

I get the same error when using the annual daylight sample file. I specificaly get it only when I use BSDF modifier to define the glass. This error happens only with the Annual daylight component. The direct sun hours component appeared to work, but no matter what xml file I used it gave the same results.

BSDF modifiers were not supported in the LBT 1.2 stable release but they are currently available in the development version of the plugin (which you can get using the “LB Versioner” component) and they will be available in the soon-to-come LBT 1.3 release.

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)

@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

@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.

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

1 Like

This is great, thank you Chris!

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:


Can someone please help? Much appreciated!

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.

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

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!

@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:

@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

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:

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.

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

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

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.

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”.