To me, it's a sales trick until they demonstrate numerical stability to the
level Ross and I did with SPFP and SPDP. Have they? But even if it's not
that stable, at least customers can make an informed choice with such data,
no? Also, how often are they rebuilding the neighbor list? Is it a fixed
interval like GROMACS or is there a skin test?
I am rethinking all this currently and I have friends who think Neighbor
lists are obsolete if we move to higher timesteps and larger nonbond
cutoffs, but that brings us to how do we handle exclusions and that's a
rabbit hole. But... Coincidentally, SPFP's perfect force conservation can
let you add and subtract them if you cap their magnitudes or use some
variant of softcore to control dynamic range. But are they doing anything
like this? Details are everything!
On Thu, May 13, 2021 at 1:39 PM Michael R Shirts <
Michael.Shirts.colorado.edu> wrote:
> > and they skipped calculating the Ewald Sum every other iteration (thanks
> Adrian!).
>
> In their semi-defense, IIRC, their default on all DESMOND simulations for
> a while has been to do multiple timestepping of forces, including Ewald sum
> every other timestep. It's not entirely clear to me if this is sufficiently
> accurate, and they definitely should make that clearer that they are doing
> something different, but it's a valid approach (that more people should be
> investigating!) and it's not just a sales trick. Not that there aren't
> also sales tricks out there.
>
> Best,
> ~~~~~~~~~~~~~~~~
> Michael Shirts
> Associate Professor
> michael.shirts.colorado.edu
> http://www.colorado.edu/lab/shirtsgroup/
> Phone: (303) 735-7860
> Office: JSCBB C123
> Department of Chemical and Biological Engineering
> University of Colorado Boulder
>
>
> On 5/13/21, 1:27 PM, "Scott Le Grand" <varelse2005.gmail.com> wrote:
>
> So, we're all getting our knickers in a bunch over an Apples to Oranges
> Desmond to AMBER performance comparison.
>
> Please don't...
>
> They cheated, because that's what they do to keep their investors
> happy.
> They used a 32^3 grid, and they skipped calculating the Ewald Sum every
> other iteration (thanks Adrian!). Rather than get upset here, point and
> laugh at DE Shaw et al. that they are afraid to go head to head with
> AMBER,
> and if they do (and they won't because they're chicken bawk bawk
> bawk), we
> have the people to address that as well.
>
> At our end, there's a ~50% or so performance deficit in AMBER 20 we
> need to
> fix. I've already fixed 2/3 of that building PMEMD 2.0 (770 ns/day
> DHFR 2
> fs already). Let them prance about with their greasy kids stuff
> desperate
> approximations and cheats, SPFP remains performance and accuracy with
> compromise and if they want to pick a fight with SPFP, make them do the
> work to demonstrate equivalent numerical stability (spoilers: they
> won't
> because they can't but oh the bellyacheing and handwaving they are
> willing
> to do, just watch).
>
> Scott
> _______________________________________________
> 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 Thu May 13 2021 - 14:00:03 PDT
