Feature #2229
Full Object Oriented Modularization of GROMACS MDRUN Codebase
Description
At CSCS, we aim to create a library out of GROMACS for the compute intensive non-bonded force computations. We envision an API consisting of a non-bonded computation back-end which developers could plug into their own custom MD simulation codes.
En route to accomplishing this, we would like to turn GROMACS's MDRUN program into a modular software where new and potentially exascale-friendly methods like FMM or Multigrid could be added by developers with little overhead. These would become new features for the GROMACS software package itself complementing the already efficient PME based methods.
This refactor would certainly beneficial for the GROMACS Development, but the library and API would allow developers/advanced users to write more complex programs consisting of ensembles, replica exchange, etc on their own MD code.
As a first step, we want to create a (global) Domain Decomposition Manager which amounts to aggregating the various functions that operate on the `gmx_domdec_t` struct and the struct itself into a single class object. Renaming functionalities with intuitive names would also be helpful. A flowchart providing a schematic of the planned refactor with the GROMACS workflow is attached for reference.
We are fully open for discussions and would look forward to your inputs.
Related issues
Associated revisions
History
#1 Updated by Vedran Miletic about 3 years ago
Prashanth Kanduri wrote:
At CSCS, we aim to create a library out of GROMACS for the compute intensive non-bonded force computations. We envision an API consisting of a non-bonded computation back-end which developers could plug into their own custom MD simulation codes.
En route to accomplishing this, we would like to turn GROMACS's MDRUN program into a modular software where new and potentially exascale-friendly methods like FMM or Multigrid could be added by developers with little overhead. These would become new features for the GROMACS software package itself complementing the already efficient PME based methods.
Are you aware of the modularization effort already in progress?
This refactor would certainly beneficial for the GROMACS Development, but the library and API would allow developers/advanced users to write more complex programs consisting of ensembles, replica exchange, etc on their own MD code.
As a first step, we want to create a (global) Domain Decomposition Manager which amounts to aggregating the various functions that operate on the `gmx_domdec_t` struct and the struct itself into a single class object. Renaming functionalities with intuitive names would also be helpful. A flowchart providing a schematic of the planned refactor with the GROMACS workflow is attached for reference.
We are fully open for discussions and would look forward to your inputs.
#2 Updated by Eric Irrgang about 2 years ago
- Related to Feature #2585: Infrastructure supporting external API added
#3 Updated by Eric Irrgang about 2 years ago
- Related to Feature #2605: Library access to MD runner added
#4 Updated by Gerrit Code Review Bot about 2 years ago
Gerrit received a related patchset '1' for Issue #2229.
Uploader: M. Eric Irrgang (ericirrgang@gmail.com)
Change-Id: gromacs~master~I1db1d34b07ec0f8ba5f246ab763c74ad9eafe8f3
Gerrit URL: https://gerrit.gromacs.org/8213
#5 Updated by Gerrit Code Review Bot about 2 years ago
Gerrit received a related patchset '1' for Issue #2229.
Uploader: M. Eric Irrgang (ericirrgang@gmail.com)
Change-Id: gromacs~master~Ibb16d1453003213a49622810ed8bad4ed4b06e2d
Gerrit URL: https://gerrit.gromacs.org/8219
#6 Updated by Eric Irrgang about 2 years ago
- Related to Task #2623: Allow extensible MDModules and forceProviders. added
Allow extensible MDModules and forceProviders.
supports gmxapi milestone 6, described at #2585.
MDModules::Impl gets a std::vector for (shared) ownership of objects
providing the IMDModule interface. An add() method is added to the
MDModules public member functions, but the binding protocols are
separated into separate issues to allow minimal changes and varying
dependencies on other pending changes.
Relates to #1972, #2229, #2492, #2574, #2590.
Refs #2623
Change-Id: Ibb16d1453003213a49622810ed8bad4ed4b06e2d