Rosetta3.3 enzyme_design errors

Member Site › Forums › Rosetta 3 › Rosetta 3 – General › Rosetta3.3 enzyme_design errors

  • This topic has 7 replies, 5 voices, and was last updated 11 years ago by Anonymous.
Viewing 2 reply threads
  • Author
    Posts
    • January 25, 2012 at 11:33 am #1144
      pbradley
      Participant

        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?

      • January 25, 2012 at 3:02 pm #6569
        pbradley
        Participant

          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
              B) double check your constraints.

            • January 25, 2012 at 4:04 pm #6572
              pbradley
              Participant

                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
                pbradley
                Participant

                  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.

                  • Author
                    Posts
                  Viewing 2 reply threads
                  • You must be logged in to reply to this topic.