Hi Ali,
Thanks for providing a sample AMBER MD trajectory file (
actg3_md.pdb) which allow me to trace where the problem is.
A portion of PDB ATOM record from the file is as below:
1 2 3 4 5 6 7 8
12345678901234567890123456789012345678901234567890123456789012345678901234567890
ATOM 11 N9 DA5 1 0.781 -4.705 -0.553 0.00 0.00
ATOM 12 C8 DA5 1 -0.573 -5.051 -0.401 0.00 0.00
ATOM 13 H8 DA5 1 -0.879 -6.079 -0.526 0.00 0.00
ATOM 14 N7 DA5 1 -1.349 -3.982 -0.328 0.00 0.00
ATOM 15 C5 DA5 1 -0.421 -2.977 -0.164 0.00 0.00
ATOM 16 C6 DA5 1 -0.512 -1.582 0.086 0.00 0.00
According to
the PDB format specification, columns 55 to 60 [Real(6.2)] is for atom occupancy. Normally, it is
1.00 -- check one of PDB entries (e.g.,
355d) for an example. Now, as you can see, AMBER puts
0.00 there. It happens that in the 2012dec09 release of 3DNA, I added checking for atom occupancy (see "
What's new?" for details). It is in that release that atoms with zero occupancy are ignored -- so
find_pair would judge that your MD trajectories contains no base pairs. That explains your observation:
By the previous release (2012Nov26) there is not any problem!
You raised an interesting question:
Is it not possible that 3DNA analyze directly the output trajectory file of famous MD codes such as Amber?
Surely I'll like to make 3DNA directly applicable to the output trajectory file of the famous AMBER package. So I have now made checking for
-occupancy optional that can be turned on by user explicitly. Download the updated 3DNA v2.1 2012dec10 release, and it should have solved the problem.
Xiang-Jun