external potential modules for refinement against experimental data - Redmine #1972
Forces, potential and virial contributions from external potentials.
Generalise the treatment of external potentials from external input data
to make it easier, cleaner and safer to implement refinement protocolls
in gromacs.
Create a modular infrastructure for external potentials similar to the
trajectoryanalysis framework that bundles code contributions for
external potentials in exactly one place.
Removing the need to
change code that reads mdp-filesread/write tpr datachange the inputrecordchange mdrun
The module will in one place
- Declare its required input and name
- provide the force per atom, its contribution to the potential energy and virial
Implementation challenges
Parameter relay
Adding single parameters
- New parameters (like force-constants and field strength) will have to be relayed to the external potential through mdp options or an additional external file
- How does grompp know which mdp parameters are expected, which are misspelled?
For a first suggestion see Teemu Murtolas comment on the gromacs-dev list:
“Just making the validated input string queryable for all seems to achieve the exact opposite: it makes a single, global instance of the whole configuration that everyone can read and parse as they see fit, which makes it possible for people to (mis)use data from other modules and even parse it differently in different places in the code. And the input string has even less compile-time checking or structure than the current t_inputrec.
To achieve proper isolation, we would need a pattern where the module can declare their mdp options, and then it gets access to exactly those values. Preferably without knowing anything about the underlying storage format being JSON or having to declare the options in more than one place. Everything else would need to be passed through explicit coding. One option would be to use the options/ module for declaring the options, but that would require some work to support structured data (in particular, arrays of JSON objects would need some non-trivial work). This has the disadvantage that it will be difficult to have the mdp file have structure that does not closely reflect the structure of the code, but for most cases, mdp options provided by different modules would probably fit within their own dedicated sections… And it will be strict in enforcing that isolation, for better or worse.
For reading data for analysis, or for pdb2gmx, the requirements are probably different, as the module(s) that read the data can have that as their main responsibility. So there it should be fine to just write classes to extract certain things from the parsed data and expose that as useful data structures (probably in a format where you can query it by atom/residue/whatever name).”
>
- ExternalPotential should have a check_input_consistency
Adding generic, force-field like parameters
- Parameters that are constant to an external potential, like scattering factors, should be read from one library file
- How to add properties not only to atom types, but also to single atoms?
- How to treat larger entities with the same property, e.g., the number of electrons of a coarse-grained bead?
External input files
Often experimental data comes in vanilla input file formats, like a scattering curve or a ccp4/mrc ma
- Dump everything in the tpr file, or keep only file name and a check sum in the tpr file?
- Where should tools for parsing these file formats reside - within the modules, within fileio of gromacs or a third “parse experimental data” place?
External Potential Group indexing
- Generate a Group class, that allows easy looping over indexed atoms
- Provide group class decorators that allow to make molecules whole - which will require domain decomposition updates to the groups
Efficient coordinate and property communication
No communication is required when external potential depends on atom coordinates only (e.g. pulling all atoms to 0,0,0 ). The other trivial, but inefficient solution is to communicate all external potential atom coordinates to the master node, perform the calculation there and report back forces.
However, most commonly we want a structure that calculates some intermediate result M_i from all local external potential atoms, then calculates some property from this intermediate.
M_1 <- x_1 .. x_n
M_2 <- x_n+1 .. x_m
—
M <- M_1 .. M_i
then calculate V (M,x_j), F (M,x_j), T_virial(M,x_j)
Hooks to the external potential
- in the mdp file read
- print ir routines
- runner
Logging / Output
What should appear in the md.log file, what goes to seperate output files?
Checkpointing
To ensure simulations with an external potential are correctly continued, write to checkpoint file what is needed for a continuation from the external potentials.
Parallelization / Tasking / Load balancing
Account for the time spent for the external potentials.
Implement some tasking scheme for external potentials.
(from redmine: issue id 1972, created on 2016-05-27 by cblau)
- Relations:
- relates #2017 (closed)
- relates #2585 (closed)
- relates #2623 (closed)
- Changesets:
- Revision 41e0f9cc by Teemu Murtola on 2016-06-27T17:41:26Z:
Factory for creating t_inputrec
Add gmx::MDModules that encapsulates initialization of t_inputrec in all
places where it gets created. This provides a single place that needs
to change with the introduction of a more modular approach for mdrun
modules. Child changes will demonstrate how this can be used for the
external electric field code. Split into a separate change to keep the
main change smaller and more focused.
For now, put the code in mdrunutility/, as it needs to be quite high in
the dependency stack, but a better home could be found in the future.
Related to #1972.
Change-Id: I0d86fe1a8bb8f8f872f5b37bc4e7931dceae9f09
- Revision 13e5b63a by David van der Spoel on 2016-10-07T10:54:57Z:
Modularize electric field handling
Move external electric field code to a C++ class where only a single
place in the code is responsible for initializing it, and everything
else operates only on relatively general interaces. Details of the
electric field stuff is encapsulated within the class.
Moved the files into new directory applied-forces.
Added manual section for electric fields.
The interfaces may need more generalization to support more complicated
modules like the pull code, but that is better done when actually moving
those parts to this approach. Various considerations are documented in
mdmodules.h and inputrect.h.
Part of #1972.
Change-Id: I513632c74a8fae28b5f1087a3b5781791a2627bd
- Revision 7075773c on 2018-07-16T18:28:30Z:
Add LocalAtomSet for handling atom indices.
Moves reading and updating indices for a set of atoms to a single place.
Pulling, IMD, rotation enforcement, essential dynamics etc. all use
their own methods triggered in domain
decompostion to handle atom indices in parallel simulations.
This class works towards removing the exposed hooks to all these modules
in domain decomposition.
Part of casting groupcoord routines to c++.
External potentials will use LocalAtomSet to access atom subsets to make
handling of atom indices not the task of individual
external potentials, but of an parallel-Atom API instead.
Related to #1972.
Change-Id: I69460963927249c7d713e76f166e6c87122c68de
- Revision cdbc0e9c on 2018-08-07T07:21:56Z:
Local atom sets in compEL / ion swapping code.
Local atom sets remove depency of domain decomposition on the
computational electrophysiology modules and handle atom index updates
outside of this module.
Additional refactoring, because swap_group has to be a C++ struct now.
Refers to #1972
Change-Id: Ic6ee2a71f5c5c11e161fa26aafbed2764e014daa
- Revision 9864b201 by Eric Irrgang on 2018-08-29T12:32:34Z:
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