[gmx-developers] Verlet-Tables integration
hess at kth.se
Wed Nov 14 09:11:55 CET 2018
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.
On 13/11/2018 23.53, Mark Abraham wrote:
> 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.
> 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?
> 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
> * 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
> before posting!
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
> * For (un)subscribe requests visit
> or send a mail to gmx-developers-request at gromacs.org
> <mailto:gmx-developers-request at gromacs.org>.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the gromacs.org_gmx-developers