You are here

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

6 posts / 0 new
Last post
[TopologyBroker Exception]: BBTorsion at pos 468unitialized...unclaimed


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

[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

log.txt8.23 KB
2JLO_A.tpb_.txt124 bytes
2JLO_A_10-467.region.txt19 bytes
Post Situation: 
Wed, 2013-04-10 15:07

I have looked but didn't spot anything obvious. I'll see if I can reproduce it.

Thu, 2013-04-11 14:39

Perhaps because it is a transmembrane protein the protocol doesn't work (probably needs modifications).

Thu, 2013-04-11 15:17

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.

Thu, 2013-04-11 16:53

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.

Fri, 2013-04-12 13:34

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).

Fri, 2013-04-12 14:14