Rosetta3.3 enzyme_design errors

[pbradley]

Hi all,
Has anyone else experience stability issues with the enzyme_design app compiled with the Intel compilers? I am getting bus errors/seg faults sometimes, but not when I run exactly the same input with a binary binary compiled with GCC.

As a separate I am also coming across this error sometimes:

ERROR: Dispatch error. Arrived at TrieCountPairGeneric with incompatible count pair data!
ERROR:: Exit from: src/core/scoring/etable/etrie/TrieCountPairGeneric.cc line: 473

Has anyone come across this error?

[pbradley]

actually I don’t think it is due to the compiler now. It looks like there is something about the restraints that occasionally causes problems with the gradient calculation/minimization:

core.optimization.LineMinimizer: Inaccurate G! step= 4.76837e-09 Deriv= -2590.07 Finite Diff= 1.06006e+11
core.pack.task: Packer task: initialize from command line()
ERROR: Dispatch error. Arrived at TrieCountPairGeneric with incompatible count pair data!
ERROR:: Exit from: src/core/scoring/etable/etrie/TrieCountPairGeneric.cc line: 473

[Anonymous]

Hi,

This is a problem with the trie-vs-trie code — the minimizer inaccurate G information isn’t causing the exit, but rather, a bad collision in the starting conformation is hitting a problem with the way we compute derivatives for the Lennard-Jones term. That happens from time to time.

I’d like to try and find out what’s going wrong with the trie code, though. Would you be willing to send me the test case that you’re using so I can duplicate the problem and debug it? Email me at my aleaverfay account on gmail.

Best,
Andrew

[Anonymous]

I don’t know if this is true for enzyme design, but I know with regular constraints, Rosetta will let you specify nonexistent atoms, then do atom-data lookup in the wrong places, occasionally leading to segfaults. This usually happens when you use all-atom constraints during the centroid phase of a protocol.

You could:

A) deliberately put non-existent atoms in your constraint file to see if it fails, or
double check your constraints.

[pbradley]

hi there,
I’m actually working on (Cloud) PDBs output from RosettaMatch. For some of these enzyme_design works fine without problem (using the same cst file), for others it either seg faults during sidechain repacking or complains about some problem during minimization and exits. Some of the constraints are ambiguous – i.e. using atom_type rather than atom_name but these are resolved OK for the runs that are OK.
So I am really not sure what the problem could be at the moment but I will double check again.

thanks for the help!

[pbradley]

Hi Andrew,
Sure I’d be pleased to help. In confidence of course. I’ll send a tar ball when I can.

[Anonymous]

any update? I got the same error below when running

>packer_task = standard_packer_task(pose)
core.pack.task: Packer task: initialize from command line()

using pyrosetta 55906 downloaded on 2013-10-16.

[Anonymous]

The issue discussed above should be fixed in the version of PyRosetta you have – it’s quite possible you have a slightly different issue, though.

From what you’ve posted, though, I don’t see that you’re experiencing any problems. The message that you’ve bolded (“core.pack.task: Packer task: initialize from command line() “) isn’t an error message – it’s simply an informational message telling you that the packer task has been initialized from any parameters passed on the commandline. (Or, as you’re using PyRosetta, the options you’ve initialized PyRosetta with.) It’s a completely normal and expected message to be receiving from Rosetta.

[Author]

Posts