Thanks for using 3DNA.
Firstly, a detour: you mentioned the "o1p_o2p" utility program which was designed to check for correct labelling of the O1P and O2P atoms of nucleotides in a PDB file. The utility was initially written when I noticed the incorrect O1P/O2P labelling problem in the NDB entry
adh008 (9dna) used as a test case in the 3DNA distribution.
To my surprise,
even as of today, the problem is still there in the
NDB (adh008) and
PDB (9dna). To make it concrete, here is the except from corresponding data files in PDB format:
NDB Asymmetric Unit coordinates
[pdb format, Unix compressed(.Z):
pdb9dna.ent]:
ATOM 24 P C A 2 35.309 46.286 11.717 1.00 28.71 9DNA 87
ATOM 25 O1P C A 2 35.789 44.945 11.170 1.00 26.94 9DNA 88
ATOM 26 O2P C A 2 36.213 47.108 12.492 1.00 25.98 9DNA 89
[/list]
NDB Biological Unit coordinates
[pdb format:
9dna.pdb1]:
ATOM 20 P C A 2 35.309 46.286 11.717 1.00 28.71 P
ATOM 37 OP1 C A 2 36.213 47.108 12.492 1.00 25.98 O
ATOM 38 OP2 C A 2 35.789 44.945 11.170 1.00 26.94 O
[/list]
9DNA.pdb]:
ATOM 24 P C A 2 35.309 46.286 11.717 1.00 28.71 9DNA 87
ATOM 25 O1P C A 2 35.789 44.945 11.170 1.00 26.94 9DNA 88
ATOM 26 O2P C A 2 36.213 47.108 12.492 1.00 25.98 9DNA 89
[/list]
Have you noticed the inconsistencies?
I am impressed you cared to run "o1p_o2p" to check for the correct O1P/O2P labelling in your interested DNA structures. From my limited experience, I feel those days people are much more interested in solving problems of "grand importance". Yet, whenever checked seriously, even "simple" issues claimed to have been resolved for so many years still have left so many details to be worked out. From
SCHNAaP and
SCHNArP, to
resolving the discrepancies, to 3DNA and its continuous support/further refinements over the years (in my
spare time), I have been trying to solve one specific problem that apparently
has made a much bigger impact than I originally expected ten years ago.
Now, to answer your question. As of 3DNA v1.5, the
auxiliary.par file does
not contain the O1P (and O2P for that matter) xyz coordinates w.r.t. the middle frame. I am getting that info into v2.0 which hopefully could be released in the near future.
In the meantime, please check the file "stacking.pdb" which contains all the info you asked and much more. Of course, you need to have some (script) programming skills to extract the info you need and be careful about other technical details such as residue numbering, and direction of middle frame etc. I would say it's well worth the efforts ...
HTH,
Xiang-Jun