rotate_mol ambiguous orientations

[auffinger]

Dear Xiang-Jun,

Recently we used rotate_mol in order to ovelay base pairs of a same class and originating from different PDB structures. As we understood, rotate_mol sets the input structure with respect of its principal moments of inertia. Also it works generally fine, in some instances we got contradictory results by using rotate_mol -ac  (see attached files and pictures). Did we miss some options ? How could we easely use rotate_mol for overlaying such structures.

Best regards,

Pascal

[attachment=0:q0e397s7]GA_12.png[/attachment:q0e397s7]

[xiangjun]

Dear Pascal,

Thanks for providing an example of ambiguous orientations generated by the utility program "rotate_mol". For your two attached structures, "GA_1.pdb" and "GA_2.pdb", the default option "-b" does what you want:
[pre:1qwe6ej8]# GA_1.pdb and GA_2.pdb have Mac 'r' instead of 'n' as line separator
sed 's/r/n/gi' < GA_1.pdb > GA_1x.pdb
sed 's/r/n/gi' < GA_2.pdb > GA_2x.pdb

# -b is the default, thus can be ignored
rotate_mol -b GA_1x.pdb GA_1x_rotmol.pdb
rotate_mol -b GA_2x.pdb GA_2x_rotmol.pdb

# combined into a single PDB file
cat GA_1x_rotmol.pdb GA_2x_rotmol.pdb > GA_rotmol.pdb

# displayed with RasMol (note -nmrpdb option); see attached image
rasmol -nmrpdb GA_rotmol.pdb[/pre:1qwe6ej8][attachment=0:1qwe6ej8]GA_rotmol.png[/attachment:1qwe6ej8]
Does this solve your problem? Do you have more examples with the mis-orientation issue?

Xiang-Jun

[auffinger]

Hi Xiang-Jun,

Yes it works as you say. The fact that spurious characters were present in the files originated from the fact that I used MSW to edit them when I transfered them from a linux to a mac (sorry about that). The original files do not contain these characters. Although, using the -b option worked in the previous case, here is another example (which I should have sent you at the first) place of what is troubling me. Could you check this one ? Its an AA pair.

Pascal

[xiangjun]

Hi Pascal,

Yes it works as you say.

Glad to hear that it works.

The fact that spurious characters were present in the files originated from the fact that I used MSW to edit them when I transfered them from a linux to a mac (sorry about that). The original files do not contain these characters.

Thanks for sharing the background information about the issue related to the Mac 'r' line break character. It is actually a good thing that I have access to these two file so that I could refine 3DNA in future versions to handle such cases automatically. Remember, I always welcome concrete/reproducible examples that can show 3DNA's deficiencies so I can further improve it.

Although, using the -b option worked in the previous case, here is another example (which I should have sent you at the first) place of what is troubling me. Could you check this one ? Its an AA pair.

It really helps that you posted the issue with the GA pair first. The AA pair follows the same principle, but in a much subtler way. There is a directionality with AA pair, which is best seen using the base-pair parameters:

[pre:326fe38j]find_pair AAA.pdb stdout | analyze
#     bp        Shear    Stretch   Stagger    Buckle  Propeller  Opening
#    1 A-A     -6.15     -4.93     -0.22    -13.63     -5.09    -23.13

find_pair AA.pdb stdout | analyze
#     bp        Shear    Stretch   Stagger    Buckle  Propeller  Opening
#    1 A-A       6.12     -4.47      0.17      0.49     -6.69    -22.10[/pre:326fe38j]
As mentioned in the 2003 3DNA NAR paper, the [mono:326fe38j][yellow:326fe38j]M-N[/yellow:326fe38j][/mono:326fe38j] type pair (as is the case here, so are the A-T/G-C Watson-Crick base pairs) has the sign reversed for x-axis parameters (i.e., Shear and Buckle) if the order of the bases is reversed (i.e., [mono:326fe38j][yellow:326fe38j]N-M[/yellow:326fe38j][/mono:326fe38j]). Again, as documented in that paper, among the six base pair parameters,  Shear, Stretch and Opening are most discriminative of different types of base pairs.

Note that for AAA.pdb, the A-A pair has a negative Shear of [mono:326fe38j]-6.15[/mono:326fe38j] ångström, whilst the A-A pair in AA.pdb has positive [mono:326fe38j]+6.12[/mono:326fe38j] ångström. In such case, reverse the order of the two adenines in either PDB file (but keep the other file as is), and repeat the script from my previous post, you will get what you want (as shown below).

[attachment=0:326fe38j]A-Ar_rotmol_b.png[/attachment:326fe38j]

Given the above information, one could solve the orientation problem by writing a purpose-specific script to automate the above process.

Xiang-Jun

[auffinger]

Dear Xiang-Jun,

Thanks for your quick reply. Yet, I am not quite sure that its only a matter of positive and negative shear value. Here is another example for AC cWCWC pairs. AC1 and AC3 are oriented similarly, also they have positive and negative shear values while AC66 has a different orientation. Any clues since I do really not know how to solve this ? I join a pymol file that contains a superposition of about 150 similar AC cWCWC base pairs on which you can see some further ""misoriented"" base pairs.

Pascal

[attachment=0:1sowrmee]AC3_66.png[/attachment:1sowrmee]

[xiangjun]

Dear Pascal,

Yet, I am not quite sure that its only a matter of positive and negative shear value. Here is another example for AC cWCWC pairs. AC1 and AC3 are oriented similarly, also they have positive and negative shear values while AC66 has a different orientation.

Nice follow-up with an even tricker example of AC pairs . All our previous discussions are still valid, especially Shear etc values with regard to AA pair (or other NN pairs, i.e., with the same type of nucleotide). Note that your three AC cases have the following base-pair parameters:

Code: [Select]

 bp            Shear    Stretch   Stagger    Buckle  Propeller  Opening
  AC1  1 A-C    -2.72     -0.48      0.14      2.60    -12.14     10.78
  AC3  1 A-C    -2.40     -0.35      0.15     -4.40     -8.70      9.47
AC66   1 A-C    -1.27     -0.46     -0.10     -2.06    -10.93      2.43As is clear, AC1 is more similar to AC3  than to AC66. That explains why "AC1 and AC3 are oriented similarly" but "AC66 has a different orientation."  Note also all three AC pairs have [red:1w2yfc0t]negative[/red:1w2yfc0t] Shear values.

Any clues since I do really not know how to solve this ? I join a pymol file that contains a superposition of about 150 similar AC cWCWC base pairs on which you can see some further ""misoriented"" base pairs.

I have refined [mono:1w2yfc0t]rotate_mol[/mono:1w2yfc0t] using your AC examples as a test case, so that now all the "150 similar AC cWCWC base pairs" are oriented as you would expected; see the attached figure below.

[attachment=0:1w2yfc0t]AC_all_rotmol.png[/attachment:1w2yfc0t]
Please have a try and report back how it goes -- there could be some other subtleties to check [mono:1w2yfc0t]rotate_mol[/mono:1w2yfc0t] against.

Xiang-Jun

[auffinger]

Hi Xiang_Jun,

Yes, it works fine for the AC cWCWC base pairs I sent you. Many thanks for that. Yet, unfortunately it"s not the end of the story. Here is another example with an ensemble of AC tHWC pairs, for which three orientations can be distinguished (see AC1, AC2, and AC42). Any clues ? Can rotate_mol provide a consistent orientation for all base pair types ? Again, many base pair types seem to be affected by this issue. Do you take into account the mass of the atoms and/or the C1' atoms with the base (-b) option ? Although this might not change a lot of things.

Best regards,

Pascal

[attachment=0:2t129ljn]AC.png[/attachment:2t129ljn]

[xiangjun]

Hi Pascal,

Yes, it works fine for the AC cWCWC base pairs I sent you. Many thanks for that.

Glad to see we are making progress.

Yet, unfortunately it"s not the end of the story.

That's completely understandable and well expected.

Here is another example with an ensemble of AC tHWC pairs, for which three orientations can be distinguished (see AC1, AC2, and AC42). Any clues ? Can rotate_mol provide a consistent orientation for all base pair types ? Again, many base pair types seem to be affected by this issue. Do you take into account the mass of the atoms and/or the C1' atoms with the base (-b) option ? Although this might not change a lot of things.

Your new set of example AC pairs provides me yet another opportunity to refine [mono:2ovkr65m]rotate_mol[/mono:2ovkr65m] to specify the orientation. See the following image generated with Jmol of the 107 AC pairs. Hope this solves your problem.

[attachment=0:2ovkr65m]AC_all_set2_rotmol_jmol.png[/attachment:2ovkr65m]
As always, have a try and report back how it goes. As time permits, I am willing to solve other related issues you may experience.

Xiang-Jun

[auffinger]

Thanks Xiang_Jun,

This part of the problem is solved. I will scan the other base pairs to see if everything is fine now.

Pascal

[auffinger]

Hi Xiang_Jun,

Here is another one. Thanks for taking care of it.

Pascal

[auffinger]

Hi Xiang_Jun,

Another one, hope it will come to an end or do you have to write a patch for each specific base pair?

Pascal

[xiangjun]

Hi Pascal,

Here is another one. Thanks for taking care of it.

This GA pair provides me yet another great example to further refine [mono:ct3w1txr]rotate_mol[/mono:ct3w1txr]  to eliminate an ambiguity in specifying the orientation. Attached below is the properly orientated 671 GA pairs based on your file "GA_all.pdb":

[attachment=1:ct3w1txr]GA_all_set2_rotmol.png[/attachment:ct3w1txr]

Another one, hope it will come to an end or do you have to write a patch for each specific base pair?

This time, it is your fault  .  As shown in the figure below, "GA_bis_57.pdb" does not belong to the same class of base pair as represented by "GA_bis_1.pdb" (of 56 other examples). Running [mono:ct3w1txr]find_pair/analyze[/mono:ct3w1txr], you will immediately see that they have quite distinct base pair parameters; they certainly belong to different classes according to the Leontis-Westhof classification. Simply thinking of overlapping an AU Watson-Crick pair over an AU Hoogsteen pair -- do not expect to align them.

[attachment=2:ct3w1txr]GA_all_set2_rotmol.png[/attachment:ct3w1txr]

[hr:ct3w1txr][/hr:ct3w1txr]
Up to this point, I believe that your problem has been solved, from my understanding of the issue. Of course, do not be shy to show me further counterexamples  .

Xiang-Jun