How can I prevent coordinates shift when using “loopmodel.linuxgccrelease”?

[Anonymous]

Dear friends,
I would like to use “loopmodel.linuxgccrelease” to remodel an internal loop of my heavy chain (HC). It works all fine except one defect: there are some coordinates shift between the output and the input. As I will finally combine light chain (LC) structure and heavy chain (HC) structure into one PDB file, these coordinates change will make the distance between LC and HC not the same as before. Can I ask how to solve this?

The input PDB and out PDB as well as the options files are attached.

My command line is:

~/Cheng/rosetta_2014.30.57114_bundle/main/source/bin/loopmodel.linuxgccrelease @/mnt/hgfs/Mutagenesis_Rosetta/4KMT/4.0_loop_modeling/loop.options -database ~/Cheng/rosetta_2014.30.57114_bundle/main/database >& /mnt/hgfs/Mutagenesis_Rosetta/4KMT/4.0_loop_modeling/loop.log &

Thank you very much.

Yours sincerely
Cheng

[Anonymous]

After loading the PDBs, I think the problem you are describing is that the coordinate frame has shifted – Rosetta’s output, for some (probably silly) reason, moves the whole structure around in space but not internally.

The solution, outside of Rosetta, is to just realign the structures afterwards. PyMOL does is just fine (A->align->to molecule-> (choose template)). If you only need t move one structure back to the original coordinate frame it’s not too much work. I don’t know of a way to prevent the problem in the first place.

[Anonymous]

Dear friends,
The coordinate shift problem also exists in the “minirosetta.linuxgccrelease”. The input and output files are attached with the options file as well.

However, there was no coordinate shift when I run “minirosetta.linuxgccrelease” last time? Can I ask how to prevent it from happening?

Thank you very much.

Yours sincerely
Cheng

[Anonymous]

Most protocols in Rosetta don’t worry about the absolute location of a protein – most don’t even worry about having a consistent orientation of multiple outputs. That’s why you often get drift – Rosetta doesn’t attempt to maintain absolute location/orientation. In protocols where you don’t get drift, it’s simply because Rosetta avoided any sampling technique that would result in drift, rather than doing anything that explicitly maintains absolute positioning.

What you can try is to impose some absolute orientation on to the protein. One way to do this is by using a constraint file with CoordinateConstraints. In this way you can bias Rosetta to keep certain atoms at certain positions. Just be careful – as overconstraining the system is a real possibility. Also, the constraints might not be on throughout the entirety of the protocol, so you may get some drift anyway.

For best results, use a post-step alignment like PyMol. The secondary structure hiccup you mentioned isn’t really much of a concern. Rosetta doesn’t output (or read in) any secondary structural information. The secondary structure you see in PyMol is due to PyMol’s heuristics about secondary structure detection. These are incomplete at times. Depending on how you made your PDB, PyMol might refuse to guess the secondary structure of some of the protein, and just display it as loops. Most notably this happens when combining PDBs – if one part has secondary structure annotated, and the other does not, PyMol will only use the annotated secondary structure, rendering the other half of the protein as loops. You can fix this within PyMol by using the “dss” command to “define (or determine) secondary structure”

[Anonymous]

Hi smlewis,
Thank you for your help. Yes, that is exactly what I mean. However, after using your alignment method in PyMOL, the resulting structure is without any secondary structure. I think PyMOL tries to superimpose all the atoms and redesign the structure, which is not ideal.

Yours sincerely
Cheng

[Anonymous]

Hi rmoretti,
Thank you so much for helping me this.

1) I am not sure but I think the problem may due to the aligned PDB itself. The input PDB, output PDB and aligned PDB are attached. As you can see from the aligned PDB, all of the Ca atoms are put in the beginning, which seems to make beta sheet overlapped with loop structure.

2) After I typed “dss” and entered, the PyMOL has frozen for a long time and seems to never come back to work. Does it require very good CPU? But I think PyMOL is not a solution if PyMOL cannot correct the coordinates.

3) Could you please show me an example for “CoordinateConstraints”? Or some demo file?

Thank you very much.

Yours sincerely
Cheng

[Anonymous]

It’s not that the Ca atoms have been moved to the front – you have all of your existing Ca atoms in place for the L chain. These CA atoms all are in the H chain – and they’re the reason you’re getting the funky representation. What you’re seeing is a Ca-only tube representation from these atoms. This is laid over the regular secondary structure of the L chain. (You can see this by showing the cartoon, and then hiding it either for the L or the H chain – you get the tube for the H chain, but the regular secondary structure for the L chain. Also deleting the chain H from a copy of the PDB and showing in PyMol also works.)

I’m not sure why you’re getting the Ca H chain. I’m guessing it has to do with the way you saved your PDB. – It looks like the coordinates for the Ca atoms are actually identical to the Ca coordinates for those residues in 4KMT_HC_FullAtom.pdb (which coincidentally is also chain H). I’m guessing that however you saved your structure, you got not only the aligned object, but also the atoms which it was aligned to in the object it was aligned to. It’s not a Rosetta issue, as those coordinates are not in the pre-aligned input file. Try using the File -> Save Molecule dialog, and selecting just the single object you want to save.

For the constraint file, the format of the constraint is simply something like:

CoordinateConstraint CA 117 CA 1 18.541 35.124 -13.751 BOUNDED 0 1.4 0.75 0.5 tag

This specifies to put the CA atom of (pose numbered) residue 117 within 1.4 angstroms of 18.541 35.124 -13.751. The “CA 1” is used to specify a reference atom with respect to which 117 is moving. (Ideally a virtual root residue connected to the protein by a jump, but an atom distant in sequence/physical space from the constrained atom can work.) The 0.75 specifies how tight to make the constraint (smaller numbers are more restrictive), and the 0.5 is a transition parameter which shouldn’t be changed.

To use, place one or more of those lines in a file, and provide the filename to your protocol with -cst_file and -cst_fa_file. (The former is for centroid mode – only reference backbone heavy atoms.) You may also need to mess with the scorefunctions used to turn on the coordinate_constraint term. (Some protocols will do this for you automatically if you use the -cst_weight and -cst_fa_weight options.)

It’s not foolproof, as it’s sometimes iffy if the constraints will get used or not. Again, the post run alignment step with PyMol is probably a safer bet, if you can get it to work.

[Anonymous]

Hi rmoretti,
Thanks so much!

1) Yes, the HC is loop and LC is regular secondary structure. I realise it is my incorrect saving method because I saved both the post-alignment structure and the alignment file into one PDB structure. After using your saving method, the aligned structure finally works! I am so happy now!

2) Your constrain file syntax is very comprehenive. I will try it later if needed.

Yours sincerely
Cheng

[Author]

Posts