I can only add the reminder that our main workaround has been to increase the size of the water box. That is, it disproportionately seems to affect smaller systems. The locals who run simulations of really large systems never seem to see this. Sure, they can't run as long, but there are many more interactions in each step. I suspect most lipid simulations are also much larger than some of the systems we run. I can't promise that this information is useful, but there it is.
FWIW, we're going to re-run some simulations that failed, but with our HO vdW terms on the HW, just to see what happens.
We haven't seen it in CPU. I realize that doesn't mean it couldn't happen there.
:-) 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: Ross Walker [ross.rosswalker.co.uk]
Sent: Friday, August 16, 2013 10:02 PM
To: AMBER Developers Mailing List
Subject: Re: [AMBER-Developers] Zero VDW radii causing havoc.
Scott, I'm still not sure I am convinced on this being the issue. We have
many many simulations done with TIP3P water - probably hundreds of
milliseconds in aggregate, a lot with boosted potentials and other types
of enhanced sampling and haven't seen this issue. Sure we've seen problems
with zero VDW hydroxyl hydrogens before - but those are always when they
are constrained to be close to each other or with massive attraction such
as in some sugars and phosphates. I don't think I've ever seen problems
with TIP3P before since the bonds are rigid and the H's are, I believe,
inside the VDW sphere of the oxygen. Hence I would never expect to see
this for two waters, for a water and a strained hydroxyl perhaps but even
then unlikely.
Are you certain this is a real problem and not a strange artifact, and or
subtle bug? - Do we have any repro's for the CPU code?
The only place I'd expect there could be problems with TIP3P is if it is
run without shake. So something must be unique about the examples here
that are showing the repro that doesn't normally occur in protein and/or
dna simulations.
Ps. we've never seen a problem with the lipid12 force field as far as I
know and we have over 100 microsecs of simulation on these systems.
Hence I am still a little suspicious...
All the best
Ross
On 8/16/13 6:20 PM, "Scott Le Grand" <varelse2005.gmail.com> wrote:
>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
_______________________________________________
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 - 20:00:02 PDT
