Project

General

Profile

Feature #1347

future of tables

Added by Mark Abraham almost 6 years ago. Updated 5 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
mdrun
Target version:
Difficulty:
uncategorized
Close

Description

For 5.0, I will move the expected place for table input to be grompp, so that we write a .tpr that actually does contain all the physics. We'd have to retain table-reading code and command-line options in mdrun for backward compatibility, but deprecate that in 5.0.

We would also like table support for the Verlet kernels for 5.0, as part of the scheme to provide a version where group and Verlet kernels are notionally equivalently fully-featured, so that we can deprecate the group kernels at some point over the next year or two.

Also, the day of the cubic-spline potential table for MD is over. Erik has various plans for using only quadratic-spline force tables, so probably cubic spline table energy input will be deprecated in 5.0, unless we decide that we still want it for MC.


Related issues

Related to GROMACS - Feature #1192: Add support for Verlet scheme with BuckinghamAccepted
Related to GROMACS - Task #1852: Remove group schemeNew
Related to GROMACS - Bug #1913: tabulated bonded interaction files cannot be readClosed
Related to GROMACS - Feature #1666: new approach for Verlet-scheme kernel generationNew
Related to GROMACS - Task #2353: improve on relative tolerance for constructing tablesNew

History

#1 Updated by Mark Abraham almost 6 years ago

  • Description updated (diff)

#2 Updated by Berk Hess almost 6 years ago

One complication is that user supplied tables per energy group pair will be problematic (complex code and bad performance, since several tables will compete for cash).
For 5.0 I don't see a strong need for tables in the Verlet scheme, but we need to resolve this before the group scheme is retired.

#3 Updated by Mark Abraham almost 6 years ago

One point arising from the VIrginia workshop was that it would be good to provide a version that offers interoperability of old features with both Verlet and group kernels, so that a validation version exists before the group kernels are retired. Ideally, that version would be 5.0, but if need be, that would be a good reason for a 5.1 or something around June 2014.

#4 Updated by Mark Abraham over 5 years ago

  • Target version changed from 5.0 to 5.x

#5 Updated by Mark Abraham almost 4 years ago

  • Related to Feature #1192: Add support for Verlet scheme with Buckingham added

#6 Updated by Mark Abraham over 3 years ago

  • Related to Task #1852: Remove group scheme added

#7 Updated by Mark Abraham over 3 years ago

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)

#8 Updated by Gerrit Code Review Bot over 3 years ago

Gerrit received a related patchset '1' for Issue #1347.
Uploader: Mark Abraham ()
Change-Id: I96f2b7ea792fea983fc60ff6b9acf3d0edeca8e9
Gerrit URL: https://gerrit.gromacs.org/5681

#9 Updated by Mark Abraham over 3 years ago

  • Related to Bug #1913: tabulated bonded interaction files cannot be read added

#10 Updated by Mark Abraham about 3 years ago

  • Target version changed from 5.x to 2018

#11 Updated by Mark Abraham over 2 years ago

  • Related to Feature #1666: new approach for Verlet-scheme kernel generation added

#12 Updated by Mark Abraham about 2 years ago

  • Target version changed from 2018 to 2019

#13 Updated by Peter Kasson almost 2 years ago

Just a quick note here--Christoph reminded me that as far as we know, tabulated potentials are still not supported with the Verlet kernels. This should be a to-do item before we think about removing Verlet kernels, no?

#14 Updated by Mark Abraham almost 2 years ago

Peter Kasson wrote:

Just a quick note here--Christoph reminded me that as far as we know, tabulated potentials are still not supported with the Verlet kernels. This should be a to-do item before we think about removing Verlet kernels, no?

Yes, table support is a major blocker for removing the group scheme. We need also to consider whether we want to revamp Verlet scheme kernel infrastructure alongside or after my list in comment 7, because we have to implement Verlet scheme kernels some time.

#15 Updated by Mark Abraham over 1 year ago

  • Related to Task #2353: improve on relative tolerance for constructing tables added

#16 Updated by Mark Abraham 11 months ago

  • Target version changed from 2019 to future

#17 Updated by David van der Spoel 9 months ago

Is the TODO list in comment 7 still valid?

Has it been decided to move table generation/reading to grompp?

#18 Updated by Mark Abraham 5 months ago

David van der Spoel wrote:

Is the TODO list in comment 7 still valid?

No, will update

Has it been decided to move table generation/reading to grompp?

Yes

Also available in: Atom PDF