possible rotate_mol labeling issue

[auffinger]

Dear Xiang-Jun,

I noticed an odd behavior of rotate_mol

If I apply the command
rotate_mol -ac to the coordinates below I get an output where the residue C is changed for a DC

original file

ATOM    814  C1'   C A  38       3.595   3.773  -0.589  1.00 73.86           C 
ATOM    815  N1    C A  38       4.587   2.642  -0.702  1.00 73.00           N 
ATOM    816  C2    C A  38       5.926   2.894  -1.060  1.00 73.87           C 
ATOM    817  O2    C A  38       6.307   4.051  -1.290  1.00 74.90           O 
ATOM    818  N3    C A  38       6.791   1.846  -1.144  1.00 73.76           N 
ATOM    819  C4    C A  38       6.371   0.600  -0.888  1.00 72.72           C 
ATOM    820  N4    C A  38       7.261  -0.396  -0.986  1.00 72.70           N 
ATOM    821  C5    C A  38       5.018   0.320  -0.526  1.00 71.49           C 
ATOM    822  C6    C A  38       4.176   1.359  -0.445  1.00 71.64           C 

output

REMARK    3DNA v2.1 (c) 2013 Dr. Xiang-Jun Lu (xiangjun@x3dna.org; http://x3dna.org)
ATOM      1  C1'  DC A  38      -0.773  -2.615  -0.004  1.00 73.86           C 
ATOM      2  N1   DC A  38      -0.478  -1.136   0.003  1.00 73.00           N 
ATOM      3  C2   DC A  38       0.851  -0.668   0.002  1.00 73.87           C 
ATOM      4  O2   DC A  38       1.797  -1.468  -0.001  1.00 74.90           O 
ATOM      5  N3   DC A  38       1.074   0.675   0.001  1.00 73.76           N 
ATOM      6  C4   DC A  38       0.044   1.532  -0.002  1.00 72.72           C 
ATOM      7  N4   DC A  38       0.317   2.843  -0.002  1.00 72.70           N 
ATOM      8  C5   DC A  38      -1.312   1.081   0.001  1.00 71.49           C 
ATOM      9  C6   DC A  38      -1.519  -0.243   0.001  1.00 71.64           C 
END

This is kid of odd and happens for all the files of that kind.

Can you check this ?
I used the latest download.

Best,

Pascal

[xiangjun]

Hi Pascal,

I won't take the issue you experienced as a 'bug' since rotate_mol works as expected. Here is how: as of 3DNA v2.1, the default output follows PDB format v3.x where DNA bases are named DA/DC/DG/DT etc. The program judges if a fragment is RNA/DNA based on the existence/absence of O2' atom. Since your example does not contain O2' atoms, it is taken as DNA. Thus the nucleotide Cs are converted to DCs.

You could use the -pdbv3=false option to get the desired behavior. Please have a try and post back if that works.

Since you bring up the issue, I may consider to refine the code so that when backbone atoms do not exist, 3DNA leaves a nucleotide as is.

Xiang-Jun

[auffinger]

Hi Xiang-Jun,

I tried to be careful by not saying that this was a bug since I know that you are very thoughtful about your programs and was thinking that this was related to unknown options/features of your program.
First, it would be nice to have manuals for them but I know you are working on them.
Then, you should may be have a forum topic for clarification issues (the bug report was my only possible choice - sorry).

For now, I tried the -pdbv3 option and it solves my issue, thanks.

On the other side, I think that you may be should reconsider the option of checking if an O2' is present since it lacks universality.
I was living with this program behavior for a while without realizing that I didn't get the expected results.
Just pay attention to your definition of backbone atoms.
Some files might contain C1' atoms and no other backbone atoms, so this seems a tricky issue.

Best,

Pascal

[xiangjun]

Hi Pascal,

Thanks for your thoughtful comments.

First, it would be nice to have manuals for them but I know you are working on them.

See the thread "O1P_O2P still needed ?" you started. It was at that time, I said: "Moreover, the -pdbv3 option is now on by default, so you do not have to bother with adding it in every 3DNA program. The previous behavior is still available by setting explicitly -pdbv3=no." (yes/no, true/false, on/off, 1/0 pairs are all okay for the setting).

Maybe I should have written a detailed manual about the various options, but experience has taught me it is not easy to keep things (commandline vs online vs hardcopy PDF) synchronized. Wrong documentation is worse than no documentation, and people do not like to read long manuals at all.

With DSSR, I have tried to make default options sensible for the most general use cases so that a regular user can get started right away [think of the 'deceitfully' simple user interface of Google]. For expert users like you, I won't expect a 'static' manual could fill your need . So I am always quick in fixing bugs and in classifying user confusions.

Then, you should may be have a forum topic for clarification issues (the bug report was my only possible choice - sorry).

I have already moved the thread to "General discussions (Q&As)". The current categories may not be comprehensive, but already contains some overlaps.

For now, I tried the -pdbv3 option and it solves my issue, thanks.

I am glad the trick works.

On the other side, I think that you may be should reconsider the option of checking if an O2' is present since it lacks universality.
I was living with this program behavior for a while without realizing that I didn't get the expected results.
Just pay attention to your definition of backbone atoms.
Some files might contain C1' atoms and no other backbone atoms, so this seems a tricky issue.

I agree "this seems a tricky issue". In addition to set -pdbv3=false (or no/off/0) explicitly, How about checking for both the existence of phosphorus (P) and absence of O2' for DNA? Then your case won't qualify as a DNA fragment, and so Cs are not converted to DCs by default.

HTH,

Xiang-Jun

PS: Did you check the new feature "x3dna-dssr --non-pair" for non-pairing interactions (H-bonds or base-stacking) that you requested?

[auffinger]

Hi Xiang-Jun,

Yes, but what would you do for terminal residues that lack phosphate groups. Why not simply rely on the pdb author labeling ?
As for manuals, I understand your point. One way to solve this would be to include a manual for all options
available through a -help option. This manual would be updated along with the addition/modification of program options.
And all users could rely on this.


Pascal

[xiangjun]

Yes, but what would you do for terminal residues that lack phosphate groups. Why not simply rely on the pdb author labeling ?

We are considering just the default setting of the pdbv3 option. It's tricky to make it work for every situation, and that's why it is a command-line option to begin with. Users can always with set pdbv3=false to keep nucleotide name as is. I believe that's what you need to do.

If by "Why not simply rely on the pdb author labeling ?" you mean to set pdbv3=false as the default, then we are on ground zero. Again, see how this switch of default setting in 3DNA got started by following the thread "O1P_O2P still needed ?".

When the PDB format is switched from v2.x to v3.x, I do not know how many programs break. I remember at one time MolProbity had two versions, one for each PDB format. 3DNA tries to accommodate many variants of the so-called PDB format. Obviously, for certain cases, manual setting is needed from the user.

As for manuals, I understand your point. One way to solve this would be to include a manual for all options
available through a -help option. This manual would be updated along with the addition/modification of program options.
And all users could rely on this.

Good suggestion. The only issue is that the 'global' settings need to be repeated in each program. Maybe I can put them on the Forum, or find a way to avoid duplication. One principle of software design is DRY: "Don't repeat yourself".

Thanks,

Xiang-Jun

[auffinger]

Hi Xiang-Jun,

Sorry to continue with this issue but I realized that with the pdbv3=false option, I get the old O1P/O2P back which certainly something I don't want.
I must say I am stuck here. In one case wrong phosphate names in the other wrong residue names.

When I wrote rely on the pdb file, I meant that for the residue names. Why check if they are correct and eventually bother to change them ?
It seems to me an unnecessary task.

Please, I would appreciate your quick help on this.
In the mean time I used a sed command.

Best,

Pascal

[xiangjun]

Hi Pascal,

Sorry to hear that. Again, could you please attach some concrete examples I can check with? I promise a quick fix for you.

Xiang-Jun

[auffinger]

Hi Xiang-Jun,

Sorry for not having replied earlier. I thing you can use any file containing a nucleotide and if you use the file -pdbv3=false, the program turns OP1/2 into O1/2P.
If you take any base file as the one I sent you earlier (see above) then the residue labels might get changed C->DC, G->DG, and so on, The only way to solve this is the -pdbv3=false option, thus this option is good for base files but not for nucleotides, basically.

That describes the problem, I think.

Pascal

[xiangjun]

Hi Pascal,

Thanks for posting back. Now I understand clearly the problem.

3DNA always 'standardizes' atom/residues names internally (e.g. O1P/OL/OP1, DC5/DC3 etc) to account for the numerous PDB variants. If -pdbv3=true, then PDB v3 naming convention is adopted. If -pdbv3=false, then the internally used O1P/O2P is written out, and that's the issue you are experiencing.

It's been the situation in 3DNA from the very beginning, and I've never heard of a complaint from users. Your question has made me to rethink the whole design to come up with a new solution. I will get 3DNA updated in a couple of days that should fix the problem. So stay tuned!

Xiang-Jun
I've released DSSR-beta-r10-on-20130430 with features you requested. Please give it a try and report back your thoughts.

[xiangjun]

Hi Pascal,

I've updated 3DNA v2.1 to 2013may02 where rotate_mol and frame_mol would preserve atom/residue names in the original PDB file. Please have a try, and report back if that fits your needs.

Xiang-Jun