Yep, that's why I moved the bug over to pmemd and away from pmemd.cuda...
On Fri, Aug 16, 2013 at 6:17 PM, B. Lachele Foley <lfoley.ccrc.uga.edu>wrote:
> We only had one, the HO (Ho) term. It's been made non-zero which at least
> fixed the issue in the highly charged, perfectly aligned situation where we
> first saw it. BTW, we (specifically Matt) first observed it on CPU.
>
> Can changing the LJ A term like that potentially mess up other things like
> hydrogen bonding?
>
> :-) Lachele
>
> Dr. B. Lachele Foley
> Complex Carbohydrate Research Center
> The University of Georgia
> Athens, GA USA
> lfoley.uga.edu
> http://glycam.ccrc.uga.edu
>
> ________________________________________
> From: Scott Le Grand [varelse2005.gmail.com]
> Sent: Friday, August 16, 2013 9:11 PM
> To: AMBER Developers Mailing List
> Subject: Re: [AMBER-Developers] Zero VDW radii causing havoc.
>
> There are a heck of a lot more TIP3P waters running around your test case.
> Anything with an effective zero VDW radius is a problem.
>
> 20 years ago, I used to see these when I did global conformational search
> of proteins. And when it happened, energies would plummet into a deep
> abyss and hose the search process. The only thing different with MD is
> that the finite timestep messes up a water badly enough that the fast Shake
> recovers it into a bizarre position that now hits a bunch of other atoms
> and then all you-know-what breaks loose and we're off to NaNdyland...
>
> The more things change...
>
>
> On Fri, Aug 16, 2013 at 6:06 PM, B. Lachele Foley <lfoley.ccrc.uga.edu
> >wrote:
>
> > Jason said: "The problem-case hydrogens in the relevant carbohydrates
> > (and lipid?) force fields should be modified if they represent problems
> in
> > normal simulation. "
> >
> > FYI: Scott Le Grand, in the bug report Ross mentioned, just said it was
> > two TIP3P waters doing it.
> >
> > :-) Lachele
> >
> > Dr. B. Lachele Foley
> > Complex Carbohydrate Research Center
> > The University of Georgia
> > Athens, GA USA
> > lfoley.uga.edu
> > http://glycam.ccrc.uga.edu
> >
> > ________________________________________
> > From: Jason Swails [jason.swails.gmail.com]
> > Sent: Friday, August 16, 2013 3:28 PM
> > To: AMBER Developers Mailing List
> > Subject: Re: [AMBER-Developers] Zero VDW radii causing havoc.
> >
> > On Aug 16, 2013, at 11:39 AM, David A Case <case.biomaps.rutgers.edu>
> > wrote:
> >
> > > On Fri, Aug 16, 2013, Ross Walker wrote:
> > >
> > >> So I am proposing that we have code in rdparm that detects zero VDW
> > radii,
> > >> prints a warning message about it and then adjusts these radii in the
> > code
> > >> to 0.0000001.
> > >
> > > I don't understand how/why this fixes any problem. First, you would
> have
> > > to get to distances comparable to the radius for such a term to have
> any
> > > effect. You would have already very much messed things up by that
> point.
> > > Second, atoms like OH have a zero epsilon as well as a zero radius, so
> > > just changing the radius would have no effect.
> >
> > I think Ross meant changing the A and B coefficients to 1E-6 or so, not
> > the pre-combined values.
> >
> > I'm with Dave on this though. I've run many microseconds of net
> simulation
> > and I've never seen a problem with zero vdW terms in HO atom types. I
> > realize there are some cases where this bug hits you, but as I recall it
> is
> > a strange case with carbohydrates. I'm wary about just making these
> changes
> > under the assumption it will have only remedial effects. The problem-case
> > hydrogens in the relevant carbohydrates (and lipid?) force fields should
> be
> > modified if they represent problems in normal simulation.
> >
> > I can also quite easily write a quick parmed action to implement these
> > changes without having to hard-code this new convention immediately into
> > every md engine we have.
> >
> > Also, I think that the amber codes should implement the Amber force field
> > exactly as it is defined in the prmtop. Implicitly changing parameters in
> > the MD codes is a bad idea, IMO. (How hard would it have been to validate
> > chamber if CHARMM took that approach?) So if we decide to implement this
> > change, it should be done in LEaP, not rdparm (but again, I think the LJ
> > terms should be derivable straight from the combining rules).
> >
> > > Note that Istvan's lmodprmtop hack directly changes the LJ A term from
> > > zero to 1000. This has the advantage of not assuming any particular
> > mixing
> > > rules, i.e. it still works when NBFIX like changes have been used.
> >
> > As an aside, should lmodprmtop functionality be incorporated into parmed
> > and/or cpptraj if it does simple things? (I'm not sure what else it
> does...)
> >
> > All the best,
> > Jason
> >
> > _______________________________________________
> > AMBER-Developers mailing list
> > AMBER-Developers.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
> >
> >
> > _______________________________________________
> > AMBER-Developers mailing list
> > AMBER-Developers.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Aug 16 2013 - 18:30:04 PDT
