The crashes may be related to runaway memory use by the undo system in Foldit. It also seems related to specific poses of the protein, with some poses causing crashes while similar poses don't crash.
There are couple of tricks which may reduce the crashing, although the puzzle will still be quite slow.
The first step is to adjust the undo settings. In the Undo menu, select Graph Properties, and adjust the settings of the sliders, "Max Graph Length" and "Memory Usage". Move the sliders all the way to the left, setting max graph length to 25, and memory usage to 0%. Click on "Apply" for each setting.
As an added precaution, try closing and restarting your client, then verify the undo graph settings are still in place.
These settings limit the amount of undo information the client is keeping, and seem to eliminate crashes in at least some recipes.
The second approach is to modify recipes. This method works for Lua recipes using the "v2" interface, and can be as simple as adding one line of code.
Simply including this code near the beginning of a recipe:
undo.SetUndo ( false )
should reduce or eliminate crashes in at least some recipes.
If a recipe includes this code alone, it should be possible to undo the entire run of the recipe with just a control-z (or the equivalent) after the recipe completes. As with setting the graph properties, the result should be fewer crashes.
If you want more than one undo step, toggling undo status as follows may do the trick:
save.Quicksave ( 3 ) -- save the current solution undo.SetUndo ( true ) -- turn undo on save.Quickload ( 3 ) -- reload; this should trigger an undo undo.SetUndo ( false ) -- turn undo off again
You'd do these steps whenever the recipe detects a gain that it wants to save. (The "3" on the Quicksave/Quickload commands can be any slot.) Thanks to berto for developing this technique.
(Another alternative is to use save.SaveSolution to create a saved solution. The advantage of SaveSolution is that the save should be available even if the recipe later crashes. Not sure about others, but Beta Folders have been slow to make use of this somewhat recent feature.)
There's more in these feedbacks:
crashes on puzzle 1766 TIM barrel redesign
Memory leak in client 20191029-32048a6a12-win_x86
If you end up with a lot of all-helix solutions, it might be helpful to add a secondary structure requirement to future puzzles like this. Also, with so many residues, more than 7 days would be good.
This keeps crashing with recipes that I'd use for early game. I love the concept, but it is too large :(