[gmx-developers] Verlet-Tables integration

[Mark Abraham]

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> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20181113/1d576572/attachment.html>