crashes on puzzle 1766 TIM barrel redesign

Started by LociOiling

LociOiling Lv 1

On puzzle 1766, one pose in particular generates frequent crashes. It's shared with scientists as "26196.978 - crashes".

The solution crashes with various recipes. One example is Microidealize 4.0. On low wiggle power, the recipe crashes after idealizing a dozen or so sections. The exact crash seems to happen at different spots, but it's hard to be sure exactly what was happening at the point of the crash.

No debug.txt is generated. The traceback lines at the end of log.txt are all "no symbol (no line)", which is the pattern in recent crashes.

The recipe TIM Crash is a simplified demonstration. It consists of a series of idealize steps for a specific range of segments, 64-66. The series is the same as what Microidealize 4.0 does. Simply repeating the same steps for the same segments a number of times causes a crash. TIM Crash repeats the series up to 30 times, but it probably won't take that long.

In this case, it seems like the idealize step does something bad to the protein that causes an error down around the Rosetta level. Perhaps the error or something related overwrites memory each time it happens, eventually causing a crash.

Here are the last few lines of a typical log.txt for TIM Crash. Note the "no proper DoF" messages for 64 and 65.

***** STARTING THREAD ActionIdealize
RT: 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
core.kinematics.AtomTree: [ ERROR ] No proper DoF can be found for these four atoms: 64-2, 64-3, 65-1, 65-2!
core.kinematics.AtomTree: [ WARNING ] DOF for this torsion angle could not be found in AtomTree.
core.conformation.Conformation: [ WARNING ] Unable to set torsion angle in atom_tree: TorsionID 64 BB 3
core.kinematics.AtomTree: [ ERROR ] No proper DoF can be found for these four atoms: 249-2, 249-3, 250-1, 250-2!
core.kinematics.AtomTree: [ WARNING ] DOF for this torsion angle could not be found in AtomTree.
core.conformation.Conformation: [ WARNING ] Unable to set torsion angle in atom_tree: TorsionID 249 BB 3
core.kinematics.AtomTree: [ ERROR ] No proper DoF can be found for these four atoms: 434-2, 434-3, 435-1, 435-2!
core.kinematics.AtomTree: [ WARNING ] DOF for this torsion angle could not be found in AtomTree.
core.conformation.Conformation: [ WARNING ] Unable to set torsion angle in atom_tree: TorsionID 434 BB 3
Resymmetrized pose
Resymmetrized pose
***** ENDING THREAD ActionIdealize
Resymmetrized pose
Resymmetrized pose
***** STARTING THREAD ActionGlobalMinimize
RT: 1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
Resymmetrized pose
***** ENDING THREAD ActionGlobalMinimize
Resymmetrized pose

UNHANDLED EXCEPTION
  1: no symbol (no line)
  2: no symbol (no line)
  3: no symbol (no line)
  4: no symbol (no line)
  5: no symbol (no line)
  6: no symbol (no line)
  7: no symbol (no line)
  8: no symbol (no line)
  9: no symbol (no line)
 10: no symbol (no line)
 11: no symbol (no line)
 12: no symbol (no line)
 13: no symbol (no line)
 14: no symbol (no line)
 15: no symbol (no line)
 16: no symbol (no line)
 17: no symbol (no line)
 18: no symbol (no line)
 19: no symbol (no line)
 20: no symbol (no line)
 21: no symbol (no line)
 22: no symbol (no line)

Skippysk8s Lv 1

this puzzle crashes on helix twister, dremix, anything that mutates in a recipe…. I think it is too big for my machine. I've given up much to my regret. Never kept it running even an hour with a recipe

LociOiling Lv 1

This feedback about the current memory leak got me thinking: Memory leak in client 20191029-32048a6a12-win_x86

Using Process Explorer, a client starts out with "peak private bytes" under 700,000 K.

Running the TIM Crash recipe, peak private bytes steadily increases to just under 1,800,000 K before the crash.

As an experiment, I added this code:

undo.SetUndo ( false )

just before the loop. Now the recipe runs through 30 cycles without a crash. Peak private bytes maxes out at around 750,000 K.

So I guess the underlying issue may have something to do with the undo settings and the overall size of the puzzle versus an issue with symmetry.

I've added undo.SetUndo ( false ) to Microidealize 4.0 as well, and it seems to be working. So far, MI 4 has completed at least twice as many cycles as before.

bkoep Staff Lv 1

This is super helpful, LociOiling! We'll take a close look at the Undo features and see if we can figure out what's going on.

If you're up for another experiment, can you tell me if it helps to decrease the Undo Memory Usage setting instead of using the LUA command? (I'm thinking of the setting in the Undo menu, under "Graph Properties")

LociOiling Lv 1

My previous undo graph properties were at their maximum values, max graph length = 100, memory usage = 100%.

I reduced these to max len = 25 memory = 0%, the minimum values.

I ran the original version of TIM crash, without the SetUndo command.

This time, "peak private bytes" remained unchanged while the recipe ran, versus a slight increase with the SetUndo version of the recipe.

The TIM crash recipe ran to completion.

Using the unmodified version of Microidealize 4.0, there's a slight growth in peak private bytes, but it seems to plateau after a couple of sections. MI 4 is running longer with the reduced graph settings, but the test will take a little longer to complete.

When changing the graph settings, it seems necessary to click the "apply" buttons for both settings. I tried a test with a different recipe, but got a quick crash when I skipped this step. On a second attempt, after applying the settings and then restarting the client to verify they held, this recipe is also running longer.