Target RNA structure automatically modified before threading

[Crystal Clitheroe]

Hello Samuel

I am currently trying out MMB 17 to comparatively model a medium sized RNA structure (Ribozyme, 54nt). I had no problems with the RNA threading example in the tutorial and discussed else where in these forums (Good tutorial!).

For my template I'm using an X-ray determined structure (4oji.pdb, though I cleaned it of all the HetATOMs). This template is 54nt, and I'm testing out the program trying simply to thread a shortened version of the template sequence to itself (residues 7-54).

The problem is that, the template structure seems to be automatically denatured before the threading even begins. See the image files attached.

Structure of Template in last.1.pdb

last.1.png (62.23 KiB) Viewed 241 times

-->

Structure of Template in first trajectory.2.pdb frame.

traj_Frame1.png (64.58 KiB) Viewed 241 times

Below is a copy of my script (commands.twister_test.dat) based on that of the tutorial:

Code: Select all

# Before running this, # Put 4oji_clean.pdb in last.1.pdb 

firstStage 2 
lastStage 2 

# The reporting interval is set empirically, it has no particular physical meaning in this case:
reportingInterval .5 
numReportingIntervals 80 

# 4oji -- "target" fragment  
RNA A 1 CCGCCUAACACUGCCAAUGCCGGUCCCAAGCCCGGAUAAAAGUGGAGGGGGCGG

# Twister wildtype -- "threaded" fragment   
RNA B 7 AACACUGCCAAUGCCGGUCCCAAGCCCGGAUAAAAGUGGAGGGGGCGG  


mobilizer Rigid A 

# Old way to prevent steric clashes, as described in Flores & Altman, RNA 2010:
#contact AllHeavyAtomSterics C 146 164 

# More modern way, using "Physics where you want it" applied to target only:
setDefaultMDParameters
includeResidues B FirstResidue LastResidue

# Note that for large molecules, the force field can get expensive. In such cases, try threading it in parts.

#Alignment forces. More modern way, which pulls together like-named atoms in corresponding residues:

# First, specify that the alignment is explicit, rather than using a SeqAn gapped alignment. Internally, this simply applies a high penalty to gaps: 
alignmentForces noGap

# Next, specify the force constant for the alignment springs. There is not much physical meaning to this choice of force constant, it is just empirically sufficient to pull the chains together nicely:
alignmentForces forceConstant 300.0

# Finally, specify corresponding residue stretches to be pulled together on template and target:
alignmentForces B 7 54 A 7 54

Is this an error or is there a reason why the template would be modified by the program prior threading?

Thanks and kind regards
Crystal

[Samuel Flores]

Hi Crystal,

I just realized I didn't answer you earlier. Bug me if that happens!

Before I tell you the answer, I intended for MMB to be as easy to use, and as flexible with respect to the structural and other data it takes, as possible. I also intended for MMB not to think too much for you, as guessing your intentions is dangerous. Unfortunately these two objectives cannot be satisfied simultaneously.

In this case what is happening is the authors departed quite a bit from customary PDB notation. It may be legal, since the PDB standard is a bit loose, but in any case they did a number of things that I would not ordinarily expect.

They duplicated the atoms in a few residues, and chose a rather unusual notation to express that. For instance:

ATOM 19 N1 A C A 1 -16.827 46.541 3.527 0.63 43.90 N
ATOM 20 N1 B C A 1 -16.782 46.554 3.558 0.37 44.90 N

In the above they appear to have made special atom names "N1 A" and "N1 B" which appear to be alternate locations of N1. I have never seen this before. In particular the use of a space in the middle of the atom names seems unorthodox, though again it may be legal. In these cases, you can replace column 17 with whitespace, and then delete the duplicate atoms leaving only one atom in each instance. Make sure you do not inadvertently shift the remainder of the line. I'm sure you know the PDB uses a fixed column format.

They have a "DU" residue, whereas all other residues are canonical RNA as far as I can tell from a quick glance. This one can be renamed just " U" .. again make sure you do not shift the rest of the line.

As I am a bit impatient I turned off the MD force field. I think you do not need it, because your sequence appears to be identical in the overlapping region.

Lastly, I used loadSequencesFromPdb to read in the template chain. This command allows insertion codes and gaps in numbering. At a glance it did not look like you had non-consecutive numbering, but in any case if I did not do this I got the crappy coordinate matching issue you observed. You would still need the "RNA " command to instantiate the target strand (you would have to turn off the command if you do a stage 3, and allow loadSequencesFromPdb to load both strands, but that is another story which you can see in my commands.dat).

Sound complicated? Hope not. In any case I append my commands.dat. You should have no trouble, but let me know otherwise.

SimTK won't let me attach a PDB for some reason but email me at samuelfloresc@gmail.com and I can send it to you (/Users/Sam/Downloads/last.1.pdb for my reference). Cleaning yours up manually may be a good exercise for you anyway.

Let me know how it goes

Sam


#commands.dat:

# Before running this, # Put 4oji_clean.pdb in last.1.pdb

firstStage 2
lastStage 2

# The reporting interval is set empirically, it has no particular physical meaning in this case:
readAtStage 2
reportingInterval .5
readBlockEnd

readAtStage 3
reportingInterval .5
readBlockEnd
#readAtStage 4
#reportingInterval 5
#readBlockEnd
numReportingIntervals 80

# 4oji -- "target" fragment
#RNA A 1 CCGCCUAACACUGCCAAUGCCGGUCCCAAGCCCGGAUAAAAGUGGAGGGGGCGG

loadSequencesFromPdb
# Twister wildtype -- "threaded" fragment
readAtStage 2
RNA B 7 AACACUGCCAAUGCCGGUCCCAAGCCCGGAUAAAAGUGGAGGGGGCGG
readBlockEnd

mobilizer Rigid A

# Old way to prevent steric clashes, as described in Flores & Altman, RNA 2010:
#contact AllHeavyAtomSterics C 146 164

# More modern way, using "Physics where you want it" applied to target only:
#setDefaultMDParameters
#includeResidues B FirstResidue LastResidue

# Note that for large molecules, the force field can get expensive. In such cases, try threading it in parts.

#Alignment forces. More modern way, which pulls together like-named atoms in corresponding residues:

# First, specify that the alignment is explicit, rather than using a SeqAn gapped alignment. Internally, this simply applies a high penalty to gaps:
alignmentForces noGap

# Next, specify the force constant for the alignment springs. There is not much physical meaning to this choice of force constant, it is just empirically sufficient to pull the chains together nicely:
alignmentForces forceConstant 300.0

# Finally, specify corresponding residue stretches to be pulled together on template and target:
alignmentForces B 7 54 A 7 54

[Crystal Clitheroe]

Thanks Sam!

You got back to me so soon! I will try the new script today, thanks for taking such a close look at my template file, I guess I should have done that. The alternate residues I think represent different conformations from saturation with manganese during the original experiment.

I'll try cleaning up the file myself and see if I come right. If not I'll send my my last.1 to double check if that's ok?

Thanks
Crys

[Crystal Clitheroe]

Dear Samuel

I finally came right with the modelling, though I think for my project I will used different templates so the I don't have to worry about the atoms with the alternate conformations. I have two other questions about the software though.

1) Is it possible to do multi-template homology modelling?
2) Is it possible to model structure using a template structure that retains some HETATMs (like Mg2+ ions interacting with the catalytic site) such that the model also has the ions in the same areas? Or would we have to introduce the ions after modelling using the monoAtoms command?

Thanks
Crystal