 | |||||||||||||||
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
 |
AMBER Archive (2008)
Subject: AMBER: Problem with box dimension in AmberTools ptraj
From: Steve Spronk (spronk_at_umich.edu)
Date: Tue Jul 22 2008 - 01:35:47 CDT
- Next message: Alan: "AMBER: amber ff and how it deals with out-plane chiral C"
- Previous message: David A. Case: "Re: AMBER: Where is ICO read from the ix array?"
- Next in thread: Thomas Cheatham: "Re: AMBER: Problem with box dimension in AmberTools ptraj"
- Reply: Thomas Cheatham: "Re: AMBER: Problem with box dimension in AmberTools ptraj"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
I was having trouble imaging with the latest version of ptraj found in the
AmberTools 1.0 package. I noticed that the archives have several other
instances in the past few months of problems with imaging, but it didn't
seem like there was any resolution to these problems.
In my investigations into the weirdness of the imaging, I came across what
might be the issue. It seems to me that if you read in an Amber coordinate
file with box information and write out a new one, the box dimensions are
altered upon output. As a test case of this, I have a 50-frame MD
trajectory written out by sander (the Amber 8 version-our most recent sander
installation). It's too large to attach, but the file
(traj_from_sander.mdcrd) and the prmtop file used to create it (prot.prmtop)
are available on line at http://www-personal.umich.edu/~spronk.
I ran ptraj with prot.prmtop and the following very simple script *twice*:
trajin traj_from_sander.mdcrd
trajout traj_from_ptraj8.mdcrd
#trajout traj_from_ptraj10.mdcrd
First I ran it "as is" with the version of ptraj that came with Amber 8,
which wrote out traj_from_ptraj8.mdcrd. Then I swapped the commenting on
the trajout lines (commenting out the ptraj8 line and uncommenting the
ptraj10 line) and re-ran using the version that we downloaded with
AmberTools 1.0 (associated with Amber 10), to create
traj_from_ptraj10.mdcrd.
All three of my trajectory files should be essentially identical, right?
But the diff results (below) show that while ptraj8 does reproduce the
sander trajectory exactly, the box vector line for each frame of the ptraj10
trajectory is different. ptraj 10 writes out a box size of 84.372 84.372
84.372 regardless of the actual box size of the particular frame. (I've
confirmed this with another trajectory that was run with pressure coupling,
in which the box size changed throughout the run. For this trajectory, too,
every box dimension was 84.372.) The 84.372 box dimensions happen to be the
exact dimension of the box as specified in the prmtop file.
I think that this is a bug: the box dimensions from the prmtop file should
not be used to overwrite the box information for the individual frames of
the input trajectory. The change in box vector would really screw up the
imaging. But this would happen only for cases in which the coordinate files
were created by ptraj, not sander, which may be why some people have had
problems and presumably most people haven't.
Am I doing something wrong? Can anyone else confirm this?
Here are the diff results:
$ diff traj_from_ptraj8.mdcrd traj_from_sander.mdcrd
1c1
< rdparm transformed trajectory
--->
$ diff traj_from_ptraj10.mdcrd traj_from_sander.mdcrd
1c1
< trajectory generated by ptraj
---
>
12198c12198
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
24395c24395
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
36592c36592
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
48789c48789
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
60986c60986
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
73183c73183
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
85380c85380
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
97577c97577
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
109774c109774
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
121971c121971
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
134168c134168
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
146365c146365
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
158562c158562
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
170759c170759
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
182956c182956
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
195153c195153
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
207350c207350
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
219547c219547
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
231744c231744
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
243941c243941
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
256138c256138
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
268335c268335
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
280532c280532
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
292729c292729
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
304926c304926
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
317123c317123
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
329320c329320
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
341517c341517
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
353714c353714
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
365911c365911
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
378108c378108
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
390305c390305
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
402502c402502
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
414699c414699
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
426896c426896
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
439093c439093
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
451290c451290
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
463487c463487
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
475684c475684
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
487881c487881
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
500078c500078
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
512275c512275
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
524472c524472
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
536669c536669
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
548866c548866
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
561063c561063
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
573260c573260
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
585457c585457
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
597654c597654
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
609851c609851
< 84.372 84.372 84.372
---
> 80.960 80.960 80.960
----------------------------------------------------------------------- The AMBER Mail Reflector To post, send mail to amber_at_scripps.edu To unsubscribe, send "unsubscribe amber" (in the *body* of the email) to majordomo_at_scripps.edu
- Next message: Alan: "AMBER: amber ff and how it deals with out-plane chiral C"
- Previous message: David A. Case: "Re: AMBER: Where is ICO read from the ix array?"
- Next in thread: Thomas Cheatham: "Re: AMBER: Problem with box dimension in AmberTools ptraj"
- Reply: Thomas Cheatham: "Re: AMBER: Problem with box dimension in AmberTools ptraj"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
|
VU Home |
VUMC Home |
People Finder |
University Calendar
webmaster- modified on January 30, 2009 |