[gmx-developers] Verlet-Tables integration
David van der Spoel
spoel at xray.bmc.uu.se
Sat Nov 17 10:31:46 CET 2018
Den 2018-11-17 kl. 10:11, skrev Mark Abraham:
> Hi,
>
> Or do the search (and thus blocking) per table ie. per list?
Indeed, for water we would have 3 neighborlists, OW-OW, HW-OW, HW-HW (in
the previous century we had it like that too). Each neighborlist a
separate table.
>
> Mark
>
> On Sat, Nov 17, 2018 at 9:09 AM Berk Hess <hess at kth.se
> <mailto:hess at kth.se>> wrote:
>
> Hi,
>
> We need different tables in a list if we want to, like without
> tables, compute NXM interactions with blocked coordinate loads and
> force loads and stores. If we want one table per list, we need to
> compute (and mask) each NxM block as many times as we have different
> tables between those blocks.
>
> Cheers,
>
> Berk
>
> On Nov 17, 2018 09:56, Mark Abraham <mark.j.abraham at gmail.com
> <mailto:mark.j.abraham at gmail.com>> wrote:
>
> Hi,
>
> On Sat, Nov 17, 2018 at 8:21 AM David van der Spoel
> <spoel at xray.bmc.uu.se <mailto:spoel at xray.bmc.uu.se>> wrote:
>
> Den 2018-11-16 kl. 23:26, skrev Erik Lindahl:
> > I think that would kill performance. Tables are very
> sensitive to memory trashing (since they easily exhaust
> cache) so we want to keep the number as low as humanly
> possible. Similarly, for the verlet kernels it will likely
> be reasonably efficient to do 4x4 lookups for distances that
> are similar, but very bad to have to load 4x4 different tables.
> This is why I proposed to have one table per neighborlist,
> but have many
> neighborlists. This keeps the innerloops simpler.
>
>
> That would avoid thrashing between tables, but might use the
> coordinates less efficiently. Probably useful though, depending
> on the number of tables and how many interactions each has.
> > Also having one table for Van der Waals rather than two, and
> not having
>
> to look up the C6 and C12 should help a bit.
> >
> > Tables are simply not very compatible with SIMD, although
> it’s a bit better with GPUs. But, overall I think It might
> be worth more looking into dynamically compiled analytical
> functions - processors are getting so fast that flops are
> almost free, but memory access painful.
> It depends on the analytical function :) If using Slaters
> they may end
> up being a couple of thousand lines of code.
>
> Finally, if flops are almost free, what is the problem with
> using sqrt
> instead of invsqrt, in particular for table lookups?
>
>
> Use r-squared then :-D
>
> Mark
>
> >
> > Cheers,
> >
> > Erik
> >
> > --
> > Erik Lindahl <erik.lindahl at scilifelab.se
> <mailto:erik.lindahl at scilifelab.se>>
> > Professor of Biophysics
> > Science for Life Laboratory
> > Stockholm University & KTH
> > Office (SciLifeLab): +46 8 524 81567 <tel:08-524%20815%2067>
> > Cell (Sweden): +46 73 4618050 <tel:073-461%2080%2050>
> > Cell (US): 1 267 307 8746
> >
> >
> >> On Nov 16, 2018, at 11:10 PM, David van der Spoel
> <spoel at xray.bmc.uu.se <mailto:spoel at xray.bmc.uu.se>> wrote:
> >>
> >>> Den 2018-11-14 kl. 09:11, skrev Berk Hess:
> >>> Hi,
> >>> I don't really think we need a usecase, but more people
> motivated to work on it.
> >>> We have delayed the work also because we are waiting
> for a new non-bonded kernel structure. But we just as well
> start without that, since it will not take much work to port
> the additional tabulated kernels to a new framework.
> >>> What is a dependency is a selecting the table index
> based on atom type (pairs). We want to get rid of the
> (mis)use of energy groups for this purpose in the group scheme.
> >>
> >> We can even do some small optimizations: if we have
> tables based on atomtype pairs, we do not need separate
> dispersion and repulsion tables anymore and we can put the
> force constants in the table as well. Although the large
> amount of tables will make it memory inefficient, the inner
> loop will be simpler. One could also make one neighborlist
> per atomtype pair, such that only one table goes to the
> innerloop and no atomtypes have to be looked up either. Of
> course the neighborlists would be shorter.
> >>
> >>> Cheers,
> >>> Berk
> >>>> On 13/11/2018 23.53, Mark Abraham wrote:
> >>>> Hi,
> >>>>
> >>>> Not much has happened. I did some basic cleanup, and
> Erik has worked on some table classes in src/gromacs/tables.
> Alfredo has some old GPU kernels buried somewhere on Gerrit.
> >>>>
> >>>> It would be good to identify a use case that someone
> has interest in to e.g. contribute coding time, test cases,
> design idea sounding board. AFAIK none of the GROMACS core
> developers uses this feature, so their priorities tend to
> align elsewhere. However, we know it's useful to people, so
> we'd like to find a group that can work together to make it
> happen!
> >>>>
> >>>> Some of those dot points are a bit out of date, but
> the general list of things to do is about right.
> >>>>
> >>>> Mark
> >>>>
> >>>> On Tue, Nov 13, 2018 at 3:48 PM Adriaan Riet
> <adriaan.riet at case.edu <mailto:adriaan.riet at case.edu>
> <mailto:adriaan.riet at case.edu
> <mailto:adriaan.riet at case.edu>>> wrote:
> >>>>
> >>>> Hello everyone,
> >>>>
> >>>> I know that Feature #1347 talks about the
> necessary steps to get
> >>>> tables into Verlet (pasted below). I'm curious to
> know where this
> >>>> sits. I'm happy to contribute where (if) I can,
> but don't see
> >>>> clearly where to jump in. Have the points of the
> list been
> >>>> integrated into redmine feature requests? Have any
> of these been
> >>>> implemented yet?
> >>>>
> >>>> Thanks,
> >>>> Adriaan Riet
> >>>>
> >>>> Things to do (roughly in order):
> >>>>
> >>>> * support regressiontests being able to read
> tables from grompp
> >>>> or mdrun, so that new functionality in the
> code doesn't need
> >>>> matching changes to the other repo for valid
> testing in the
> >>>> few cases where they use tables (|*CSTab*| in
> group-scheme
> >>>> kernels)
> >>>> * add integration tests, e.g. a Martini-style(?)
> non-bonded, and
> >>>> several kinds of bonded interactions
> >>>> * extract code from mdlib (particularly
> init_forcerec) so that
> >>>> it is callable at grompp time, make sure
> grompp can issue all
> >>>> notes and warnings, permit mdrun to repeat any
> of those that
> >>>> it might need to. Keep code for making
> hardware-specific
> >>>> layout decisions in mdrun, because we won't
> know whether the
> >>>> kernels need tables for CPUs or GPUs until
> then. If we can do
> >>>> it without significant loss of accuracy,
> grompp should handle
> >>>> any regularization of the user input (e.g. by
> constructing and
> >>>> testing CPU and GPU tables, if necessary).
> >>>> * move e.g. dihedral-interaction table reading
> to grompp, bump
> >>>> .tpr version, write to .tpr, read in mdrun,
> add infrastructure
> >>>> to support gmx check and gmx dump on new .tpr
> contents
> >>>> * move angle- and bond-interaction table reading
> to grompp,
> >>>> probably another .tpr version bump
> >>>> * move short-range interaction tables to grompp
> for group scheme
> >>>> * extend |[pairs]| to permit atom-type pairs to
> use an
> >>>> interaction shape read from a table, e.g. from
> a file named on
> >>>> that line of the topology. Should we have a
> per-pair-type
> >>>> scaling parameter? Requirements for
> simulations that use only
> >>>> user tables, and those that mix user tables
> with normal
> >>>> short-ranged interaction types probably differ.
> >>>> * add Verlet-scheme table-support infrastructure
> >>>> * add CPU kernels (hopefully in new scheme)
> >>>> * add GPU kernels (recycle from Alfredo's patch
> in gerrit)
> >>>> * after some time passes and master branch
> rebases enough,
> >>>> remove workaround from regressiontests (which
> is anyway only
> >>>> needed for group-scheme kernel testing)
> >>>>
> >>>> -- Gromacs Developers mailing list
> >>>>
> >>>> * Please search the archive at
> >>>>
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
> >>>> before posting!
> >>>>
> >>>> * Can't post? Read
> http://www.gromacs.org/Support/Mailing_Lists
> >>>>
> >>>> * For (un)subscribe requests visit
> >>>>
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> >>>> or send a mail to
> gmx-developers-request at gromacs.org
> <mailto:gmx-developers-request at gromacs.org>
> >>>> <mailto:gmx-developers-request at gromacs.org
> <mailto:gmx-developers-request at gromacs.org>>.
> >>>>
> >>>>
> >>
> >>
> >> --
> >> David van der Spoel, Ph.D., Professor of Biology
> >> Head of Department, Cell & Molecular Biology, Uppsala
> University.
> >> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205
> <tel:018-471%2042%2005>.
> >> http://www.icm.uu.se
> >> --
> >> Gromacs Developers mailing list
> >>
> >> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
> before posting!
> >>
> >> * Can't post? Read
> http://www.gromacs.org/Support/Mailing_Lists
> >>
> >> * For (un)subscribe requests visit
> >>
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org
> <mailto:gmx-developers-request at gromacs.org>.
>
>
> --
> David van der Spoel, Ph.D., Professor of Biology
> Head of Department, Cell & Molecular Biology, Uppsala
> University.
> Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205
> <tel:018-471%2042%2005>.
> http://www.icm.uu.se
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
> before posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org
> <mailto:gmx-developers-request at gromacs.org>.
>
>
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
> before posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org
> <mailto:gmx-developers-request at gromacs.org>.
>
>
--
David van der Spoel, Ph.D., Professor of Biology
Head of Department, Cell & Molecular Biology, Uppsala University.
Box 596, SE-75124 Uppsala, Sweden. Phone: +46184714205.
http://www.icm.uu.se
More information about the gromacs.org_gmx-developers
mailing list