[TopologyBroker Exception]: BBTorsion at pos 468unitialized…unclaimed

This topic has 5 replies, 3 voices, and was last updated 11 years, 8 months ago by Anonymous.

Viewing 2 reply threads

Author

Posts
- April 10, 2013 at 10:07 pm #1552
  Anonymous
  Greetings,
  
  I am trying to run minirosetta to create ab initio the missing ends from a crystal structure (2JLO) as in rosetta_demos/homology_modeling_with_end_extension, but I get this strange error:
  
  protocols.relax.FastRelax: ================== Using default script ==================
  protocols.evaluation.ChiWellRmsdEvaluatorCreator: Evaluation Creator active …
  protocols.general_abinitio: AbrelaxMover: S_0001
  loops: Extended: (-0,+0) LOOP 1 9 0 0 0
  loops: Extended: (-1,+0) LOOP 467 667 0 0 0
  protocols.topo_broker: Enlarged loops:
  protocols.topo_broker: LOOP begin end cut skip_rate extended
  protocols.topo_broker: LOOP 1 9 0 0 0
  protocols.topo_broker: LOOP 467 667 0 0 0
  protocols.topo_broker:
  protocols.jd2.JobDistributor:
  
  [ERROR] Exception caught by JobDistributor for job S_0001*************** Error in Broker Setup: ***************
  
  [TopologyBroker Exception]: BBTorsion at pos 467unitialized…unclaimed
  BBTorsion at pos 468unitialized…unclaimed
  BBTorsion at pos 469unitialized…unclaimed
  BBTorsion at pos 470unitialized…unclaimed
  BBTorsion at pos 471unitialized…unclaimed
  
  I set residues 10-467 to remain rigid but as you can see rosetta sees 467-667 as a loop: “protocols.topo_broker: LOOP 467 667 0 0 0”. However, the last residue is 510 in the full-length protein. What does that strange error about BBTorsion mean?
  
  I have attached the whole log file as well as the input files (apart from the fragments of course). Hopefuly you can reproduce it with:
  
  minirosetta.linuxgccrelease @broker.args
- April 11, 2013 at 9:39 pm #8617
  Anonymous
  I have looked but didn’t spot anything obvious. I’ll see if I can reproduce it.
- April 11, 2013 at 11:53 pm #8620
  Anonymous
  Removing the -random_grow_loops_by option from the args file or setting it to 0 should remove the output regarding 667, but I don’t think it will actually fix the problem. (It looks like in practice the extra “residues” from those lines are ignored.)
  
  How are your fragments? Do they cover the whole of the extended protein, or just the original portion? You can do something like a “grep ‘position’ ROBETTA_files_C-term/aat000_03_05.200_v1_3”, assuming the files aren’t gzipped. You should see a line from 1 to N-(size-1) (So for the 3-mer fragments on your 501 aa protein, you should see numbers from 1 to 498; for the 9-mer fragments it should be 1 to 492).
  
  Another thing to do is to increase the level of output verbosity (by uncommenting the -out:level 500 statement in the flags file). Sometimes more output information can help track down things that might be off.
- April 11, 2013 at 10:17 pm #8618
  Anonymous
  Perhaps because it is a transmembrane protein the protocol doesn’t work (probably needs modifications).
- April 12, 2013 at 8:34 pm #8622
  Anonymous
  Thanks a lot! The problem was the fragments. I had created just for the C-terminus hopping to be more focused but didn’t work. This time I created fragments for the full length protein, the model is created but I get a lot of these messages:
  
  protocols.simple_moves.FragmentMover: couldn’t find fragment to insert!!
  
  I have attached the whole log file.
- April 12, 2013 at 9:14 pm #8623
  Anonymous
  Don’t worry about those messages too much. With -increase_cycles 1, you’re running over 2000 cycles per stage. Not being able to find a fragment that passes the quality check for a couple of dozen of them shouldn’t be too much of an issue – at least that’s how I read the code.
  
  The big question is whether the output you’re getting looks reasonable (keeping in mind that for production runs you’ll want to do several thousand of them).
Author

Posts

Viewing 2 reply threads

You must be logged in to reply to this topic.