Hello AMBER community,
I have recently been playing with the "nativecontacts" command in cpptraj
to build contact maps for my system of interest. However, I am noticing
that the outputted map doesn't follow the atomselection as one might
suggest. For example, if I want to observe the contacts for DNA backbone
atoms in my system of interest, I call the routine as follows:
nativecontacts "(:1-5)&(.P,OP*,C3',C4',C5')" noimage writecontacts
"test.contacts" out "test.out" distance 5 name 5A reference map mapout
"test.map"
Now, the log created by cpptraj suggests that the function is correctly
applying the selection mask:
ACTION SETUP FOR PARM 'system.prmtop' (1 actions):
0: [nativecontacts "(:1-5)&(.P,OP*,C3',C4',C5')" noimage writecontacts
"test.contacts" out "test.out" distance 5 name 5A reference map mapout
"test.map" ]
Mask [(:1-5)&(.P,OP*,C3',C4',C5')] corresponds to 27 atoms.
27 potential contact sites for '(:1-5)&(.P,OP*,C3',C4',C5')'
Imaging disabled.
In short, this is what I would expect to see. However, once I inspect the
"test.map" file for parsing, I see that the atom indices of each column
don't "skip" to masked atoms, but instead they increment from the initial
atom in the mask to the final one, including all atoms between and not just
the masked ones. In the example below, it doesn't iterate over 27 atoms,
but actually 149 atoms:
#Atom Atom 5A[map]
3.000 3.000 0.0000
4.000 3.000 0.0000
5.000 3.000 0.0000
6.000 3.000 -1.0000
7.000 3.000 0.0000
8.000 3.000 0.0000
9.000 3.000 0.0000
10.000 3.000 0.0000
11.000 3.000 0.0000
...
143.000 3.000 0.0000
144.000 3.000 0.0000
145.000 3.000 0.0000
146.000 3.000 0.0000
147.000 3.000 0.0000
148.000 3.000 0.0000
149.000 3.000 0.0000
150.000 3.000 0.0000
151.000 3.000 0.0000
3.000 4.000 0.0000
...
Is this a known bug or is this a deliberate action taken by the command?
Of course, I can post-process the data files to include only the contacts I
am interested in, but scaling up my tests to the full extent of my system
results in files that are orders of magnitude larger than they need to be
(~20GB!), and most of that data is "garbage"! This not only takes up
unnecessary amounts of hard disk space, but also significantly increases
post-processing time. If anyone could offer insight to this situation, it
would be greatly appreciated. Thanks!
Take care,
Sam Bowerman
Ph.D. Candidate
Department of Physics
Illinois Institute of Technology
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Apr 07 2015 - 11:00:03 PDT
