Hi All,
Thank you all for your replies.
Attached is the prmtop (bdh.prmtop) and initial inpcrd files(bdh.inpcrd) and the input files for minimization, equilibration and production run as well.
Since I was running a 100ns simulation I was running the simulation in smaller step sizes and the attached outputs were from my 105th run so the input co-ordinates used for that specific simulation are from restart file( 104.production-run.rst) and the input for the production run is named as 105.production-run.in.
I really appreciate your help. I will be looking forward to a solution.
Thanks
Roma
________________________________
From: David Cerutti <dscerutti.gmail.com>
Sent: Monday, February 19, 2018 1:48:36 AM
To: David A Case
Cc: AMBER Mailing List
Subject: Re: [AMBER] Problem with using Monte Carlo Barostat algorithm in pmemd cuda
Oh, wow. This looks ominous. I have been tied down putting out another
fire, but here's my take:
You have both of the problems that I have been trying to deal with prior to
the Amber18 release. First, it's a small box--but more specifically it
looks to be one that will get two hash cells in each direction. Second,
it's an octahedron, which by certain math in the Amber16 implementation
will leave the GPU code thinking that it has plenty of room to let atoms
diffuse before updating the pair list. Please post prmtop and input
coordinates. If this is what I think it may be, the pair list is not
getting refreshed nearly often enough, and that in turn is allowing atoms
to diffuse far outside of where they should be in order to guarantee sane
non-bonded interactions. In your case, it may come to pass that two atoms
diffuse close enough to each other without the non-bonded direct space
interactions being properly counted. The reciprocal space electrostatic
forces are driving them together without a direct space vdW interaction to
say "whoa, hold up!" Then, when the pairlist does finally refresh, the
particles are right on top of each other and the direct space vdW kicks in
for a tremendous force.
This is all hypothetical at the moment--and it may very well be that it is
not the actual reason that you're experiencing this problem. From my
perspective, the way the code used to work this CAN happen, but even with
the fix I've implemented there are other issues with very small boxes in
the GPU code that I do not fully understand. We're working to make all of
this right in Amber18, but pair lists are trickier to maintain with all the
trimming we want to do to make the code fast. The solution I'm working
towards is one that will do even more trimming than Amber16, but completely
reworks the way imaging is handled which I'm hoping will make those lurking
problems with small boxes go away.
Dave
On Sun, Feb 18, 2018 at 8:22 PM, David A Case <david.case.rutgers.edu>
wrote:
> On Sat, Feb 17, 2018, Roma Mukhopadhyay wrote:
> >
> > Attached are the two production run files with exact same input but the
> > energy values are different, and this difference is based on the random
> > seed number, which I still don't understand why should influence my
> > energy (I am using ntt=1). If I use the same ig number I get the exact
> > same value, but still the system crashes with NaN.
>
> > > I have been trying to simulate my molecule of interest using
> > > barostat=1, which uses Monte Carlo Barostat algorithm in pmemd cuda,
> > > but the simulation keeps on crashing within 0.5 ns giving NaN values
> > > for energy. However when I run the same simulation in pmemd platform
> > > it works fine. Has anyone faced the same issue?
>
> One guess is that you are hitting an error in pmemd.cuda with small box
> sizes:
>
> Box X = 27.978 Box Y = 27.978 Box Z = 27.978
> Alpha = 109.471 Beta = 109.471 Gamma = 109.471
>
> Could you post the prmtop and starting coordinates? I think Dave Cerutti
> (cc-ed here) knows what may be going on. Even if (or especially if) my
> guess
> is wrong, it would be very helpful to be able to reproduce the problem.
>
> [If I am correct, the barostat use may be exposing the problem, but not
> really
> causing it.]
>
> ...thx....dac
>
>
_______________________________________________
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 Sun Feb 18 2018 - 21:00:02 PST
