Gromacs
2019
|
This method doesn't currently work in all cases with multipoint data or with multiple data sets. In particular, if the added module requests storage and uses getDataFrame(), it will behave unpredictably (most likely asserts).
Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
module
requests storage (addModule() has the same problem if called after data is started). Make it such that reset() is not necessary to call in code that repeatedly assigns the result of AnalysisNeighborhood::initSearch() to the same variable (see sm_distance.cpp).
Consider removing minimumDistance(), as nearestPoint() already returns the distance.
commandline
module. search
item is set multiple times. Consider making a composite object that also handles on-demand compilation, managing lifetime of PME FFT kernel programs to avoid exhausting resources and/or recompiling kernels previously used. See Redmine #2535.
Consider implementing an appropriate flavor of the nifty counter idiom so that both static initialization and deinitialization can work in a fast, leak-free, and thread-safe way without imposing constraints on the calling code. See Redmine #2535.
Consider implementing an appropriate flavor of the nifty counter idiom so that both static initialization and deinitialization can work in a fast, leak-free, and thread-safe way without imposing constraints on the calling code. See Redmine #2535.
Consider implementing an appropriate flavor of the nifty counter idiom so that both static initialization and deinitialization can work in a fast, leak-free, and thread-safe way without imposing constraints on the calling code. See Redmine #2535.
Modules in mdrun should acquire proper option handling so that all of these declarations and defaults are local to the modules.
Contextual aspects, such as working directory, MPI environment, and environment variable handling are more properly the role of SimulationContext, and should be moved there
Most of the attributes should be declared by specific modules as command-line options. Accordingly, they do not conform to the naming scheme, because that would make for a lot of noise in the diff, only to have it change again when the options move to their modules.
Preparing logging and MPI contexts could probably be a higher-level responsibility, so that an Mdrunner would get made without needing to re-initialize these components (as currently happens always for the master rank, and differently for the spawned ranks with thread-MPI).
Support for specifying that an option accepts, e.g., two to four selections. Currently, only a fixed count or any number of selections is possible.
GpuManager
that holds gmx_device_info_t
* and PmeGpuProgramHandle
and perhaps other related things whose lifetime can/should exceed that of a task (or perhaps task manager). See Redmine #2522.