Ray,
Another thing, as follow-up:
The EPB difference in my previous example was low because I
used consecutive frames from the trajectory (1 ps apart in that
case). If I pick frames that are 10 ps apart the error becomes
much larger. If the solute conformation is very different, sander
crashes:
either "pb_crggrd: index exceeds box range, bail." or
"pb_fdfrc(): Atom out of focusing box"
Just to be clear, I'm not doing MD. I'm doing post-processing
with imin=5 (ie eventually for MMPBSA).
--Niel
________________________________________
From: Ray Luo, Ph.D. [ray.luo.uci.edu]
Sent: Monday, October 17, 2011 9:54 PM
To: AMBER Mailing List
Subject: Re: [AMBER] sander pbsa and imin = 5 problem
Dear Niel,
This is because the PB solvent is a numerical/iterative procedure, and
its energy does dependent on how the initial condition is set up. Note
that your EPB number is precise to the fourth digit, which has
exceeded the preset convergent criterion (accept = 0.001 by default
meaning at least three digits precise). If you want to make EPB more
precise, i.e. less dependent on the initial condition, you can set
accept to a smaller value, i.e. 10^-4 or lower. I.e. a tighter
convergent criterion gives you more significant digits. Of course, it
will be slower to compute each frame.
All the best,
Ray
On Mon, Oct 17, 2011 at 8:27 PM, Niel Henriksen <niel.henriksen.utah.edu> wrote:
> Hi all,
>
> My last post didn't receive any replies, so I'll try to rephrase.
>
> I'm doing pbsa calculations using sander with the imin=5
> trajectory reading capability. I've found that the "EPB" value
> is dependent on order in which the frames of the trajectory
> are read.
>
> For instance, take a trajectory with two frames, A and B:
> EPB = -12567.2929 for frame A if the order is A --> B
> EPB = -12567.5574 for frame A if the order is B --> A
>
> I believe the grid is only being calculated for the first frame.
> This can actually cause sander to crash if the conformation
> of the system changes drastically from one frame to the next.
>
> This is either a bug, or there is some setting to make the grid
> recalculate each step that I'm not aware of. Either way it should
> be of interest to the developers of MMPBSA (hopefully).
>
> The files to reproduce the problem are here:
> http://www.amber.utah.edu/biodata/sander-pb-order/
>
> the commands I used are:
> sander -O -i sander.in -p com.topo -c inpcrds -y frames_A-B.traj -o frames_A-B.out
> sander -O -i sander.in -p com.topo -c inpcrds -y frames_B-A.traj -o frames_B-A.out
>
> I'll try to track down the problem/solution, but I'm sure there is
> someone who is more familiar with the code who can do it
> faster.
>
> Thanks for any help,
> --Niel
>
> PS
> my previous post:
> http://archive.ambermd.org/201110/0294.html
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Mon Oct 17 2011 - 22:30:02 PDT
