future of tables
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.
#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.
#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
[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)
#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.