op1_op2. request for an option to keep the pdb header

[auffinger]

Dear Xiang-Jun,

I was for a whole no longer using op1_op2 since I thought that the PDB
had taken care of the wrong anionic oxygen attributions.
That was assuming a little too mach and such misattributions are still found in the PDB.
(see for exemple residue 625 chain 0 in 4HUB that interacts through its N3 with the "OP1" of a m1A - should be OP2).
(other examples can be found)

Thus using op1_op2 seems still mandatory.
Yet, we stopped using it also because it gets rid of some parts of the header, especially
those that describe symmetry operations.

I such I kindly ask for a version with a -header option that would keep the original header
for those who need it.

Best,

Pascal

[xiangjun]

I was for a whole no longer using op1_op2 since I thought that the PDB
had taken care of the wrong anionic oxygen attributions.
That was assuming a little too mach and such misattributions are still found in the PDB.
(see for exemple residue 625 chain 0 in 4HUB that interacts through its N3 with the "OP1" of a m1A - should be OP2).
(other examples can be found)

No surprise.

Thus using op1_op2 seems still mandatory.
Yet, we stopped using it also because it gets rid of some parts of the header, especially
those that describe symmetry operations.

The 3DNA programs in general, op1_op2 in particular, are just tools meant to be employed as users see fit. Early on in 3DNA development, I noticed a larger than expected RMSD value between a rebuilt structure vs its experimental counterpart. The source of the discrepancy was traced to wrong labeling of the O1P/O2P (OP1/OP2) atoms. So I wrote the small op1_op2 utility program to make the correction, and distributed it with the 3DNA package, in the hope that it may be useful to others as well. I am glad to know that it is still of some value to the community.

I such I kindly ask for a version with a -header option that would keep the original header
for those who need it.

Note that op1_op2 was designed to be simple and small. Moreover, nearly all 3DNA programs check only ATOM/HETATM records, without bothering about anything else. At this stage, I do not feel it is of general interest to expand op1_op2 for your specific need.

So the answer is no -- sorry. However, that's not the end of the world. For one thing, you could bring up the issues to the PDB, and they should (be able to) fix such problems. Or, you can write a script to combine output from op1_op2 and incorporate whatever else you want from the original PDB file.

As an example, running op1_op2 on 4hub produces the following diagnostic message (in addition to the corrected coordinate file):

o1p_o2p 4hub.pdb 4hub-corrected.pdb 
*PO4 group at residue 1MA  628  on chain 0 [#621] does NOT conform to convention*
*PO4 group at residue UR3 2619  on chain 0 [#2510] does NOT conform to convention*

From the above information, you should be able to locate the two phosphate group, and correct the wrong OP1/OP2 labeling.

HTH,

Xiang-Jun

[auffinger]

OK Xiang-Jun, thanks.

Its difficult to know if this means a lot of work for you or if its easy to fix.
It might have been useful to others (or not)
especially since PDB will not be quick at fixing this or will not fix it at all.
Anyway, I will figure something out and surely let them know.

Best,

Pascal

[xiangjun]

Hi Pascal,

For sophisticated PDB manipulations, you may also want to try programs in Phenix or CCP4.

Xiang-Jun