[gmx-developers] Verlet-Tables integration

Mark Abraham mark.j.abraham at gmail.com
Sat Nov 17 09:56:29 CET 2018 

Hi,

On Sat, Nov 17, 2018 at 8:21 AM David van der Spoel <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>
> > Professor of Biophysics
> > Science for Life Laboratory
> > Stockholm University & KTH
> > Office (SciLifeLab): +46 8 524 81567 <08-524%20815%2067>
> > Cell (Sweden): +46 73 4618050 <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>
> 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>> 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>.
> >>>>
> >>>>
> >>
> >>
> >> --
> >> 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
> <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.
>
>
> --
> 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 <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20181117/e3d9f4aa/attachment-0002.html>

More information about the gromacs.org_gmx-developers mailing list