Member Site › Forums › Rosetta 3 › Rosetta 3 – General › Rosetta3.3 enzyme_design errors
- This topic has 7 replies, 5 voices, and was last updated 10 years, 9 months ago by
Anonymous.
-
AuthorPosts
-
-
January 25, 2012 at 11:33 am #1144
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: 473Has anyone come across this error?
-
January 25, 2012 at 3:02 pm #6569
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 -
January 25, 2012 at 4:13 pm #6573
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 -
January 25, 2012 at 3:53 pm #6571
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.
-
January 25, 2012 at 4:04 pm #6572
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!
-
January 25, 2012 at 4:26 pm #6575
Hi Andrew,
Sure I’d be pleased to help. In confidence of course. I’ll send a tar ball when I can. -
December 12, 2013 at 4:42 pm #9596
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.
-
December 13, 2013 at 3:44 pm #9601
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.
-
-
AuthorPosts
- You must be logged in to reply to this topic.