Grasshopper breakpoint during optimization

I’m optimizing with the Wallacei plugin after about 60 analyses, unfortunately, it gives me this message (Grasshopper breakpoint) every time on a component. What is the problem?

A few examples of this error :

Thanks for your response

This might be a question for the McNeel forum since it’s an error that’s being issued from Rhino and not Ladybug Tools. Maybe they can at least tell you what a “Grasshopper breakpoint” is. Or they might know what output log to check to see what might have triggered the error.

Thanks for your attention @chris
I simulated many times. This problem could not be solved. So I decided to simplify my model step by step, realizing that removing schedule programs from the workflow would no longer freeze Wallacei. What do you think is the problem?


Maybe the programs were eating up a lot of memory in your file. You can always add JSON files of the programs to:


Then, they will load up whenever you start up Grasshopper and this might keep them from eating up memory as you iterate through options.

Of course, this is all speculation and McNeel is the authority on issues like this.

@chris If I understand correctly, should something similar be done with this photo?

Yes, writing the program JSONs like that means they will get loaded up whenever you open a Grasshopper script that contains Honeybee components. Then, you can assign the programs to Rooms by using the name of the program instead of a program object created within the Grasshopper definition.

FYI, it’s also possible to write multiple program objects into a single JSON (the “HB Dump Objects” component can take a list of program objects) but what you have there is perfectly fine.

@chris One question I have is that if the program changes in the Grasshopper environment, Is this method still useful? for example, The area of the room varies and this changes the schedule of people in Workflow.

Programs that you write to JSON into your standards folder cannot be changed from the Grasshopper environment. They are loaded up when you open the Grasshopper definition and then they are static for the entire time that you use Grasshopper. This is partly why I thought that they could help with memory optimization of multiple runs. The only way to change them is by overwriting the files or editing the files in a text editor and then restarting Rhino.

Are you saying that you’ll need hundreds of variations of these programs to do all options of your parametric run? If so, writing them all to JSON might not be that helpful.

Oh, this is so bad! I change programs depending on the area of space. In fact, the area of space varies in optimization.

Have you solved this problem in this multi-objective optimization and breakpoint? I have the same problem as you,.