I've never seen this in 20 years, except in free energy calculations where
the oxygen is being made smaller. In my opinion its probably a symptom, not
the problem, unless the simulations are really different from anything I've
ever done.
On Aug 16, 2013 10:39 PM, "Ross Walker" <ross.rosswalker.co.uk> wrote:
> So that suggests to me that this could indeed be a bug related to having a
> small water box - has anyone seen this happen with the CPU code? A repro
> there would be very telling.
>
> Also, this is NPT yes? As in it is not some NVT water box at some
> artificially high compression?
>
> All the best
> Ross
>
>
>
>
> On 8/16/13 7:33 PM, "B. Lachele Foley" <lfoley.ccrc.uga.edu> wrote:
>
> >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
>
>
>
> _______________________________________________
> 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 Sat Aug 17 2013 - 09:30:03 PDT
