Generalize this method to multiple data sets (e.g., for adding modules that only process a single data set).
│ │ │ │ -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).
│ │ │ │ +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).
│ │ │ │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.
│ │ │ │ +Consider removing minimumDistance(), as nearestPoint() already returns the distance.
│ │ │ │ +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 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 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.
│ │ │ │Later we might need the concept of computeTasksOnThisRank, from which we construct gpuTasksOnThisRank.
│ │ │ │ -Later, this might become a loop over all registered modules relevant to the mdp inputs, to find those that have such tasks.
│ │ │ │ +Later, this might become a loop over all registered modules relevant to the mdp inputs, to find those that have such tasks.
│ │ │ │ +Later we might need the concept of computeTasksOnThisRank, from which we construct gpuTasksOnThisRank.
│ │ │ │search item is set multiple times. Modules in mdrun should acquire proper option handling so that all of these declarations and defaults are local to the 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).
│ │ │ │ -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.
│ │ │ │ +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).
│ │ │ │docs/doxygen/lib/modularsimulator.md? 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. docs/doxygen/lib/modularsimulator.md? 1.9.1
│ │ │ │
│ │ │ │ ├── html2text {}
│ │ │ │ │ @@ -3,29 +3,14 @@
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ Gromacs 2020.6-Debian-2020.6-2
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │ Todo List
│ │ │ │ │ - Member AtomProperties::atomNumberFromElement (const char *element)
│ │ │ │ │ - This should be made const once the lazy implementation is done properly
│ │ │ │ │ - for the class.
│ │ │ │ │ - Member AtomProperties::elementFromAtomNumber (int atomNumber)
│ │ │ │ │ - This should be made const once the lazy implementation is done properly
│ │ │ │ │ - for the class.
│ │ │ │ │ - Class BondedInteractionList
│ │ │ │ │ - This should be merged with BondedInteraction.
│ │ │ │ │ - Member buildSupportsNonbondedOnGpu (std::string *error)
│ │ │ │ │ - Move this to NB module once it exists.
│ │ │ │ │ - Member clearModificationBlock (MoleculePatchDatabase *globalPatches)
│ │ │ │ │ - Remove once constructor/destructor takes care of all of this.
│ │ │ │ │ - Member copyPreprocessResidues (const PreprocessResidue &s, PreprocessResidue
│ │ │ │ │ - *d, t_symtab *symtab)
│ │ │ │ │ - Remove once copy can be done directly.
│ │ │ │ │ Member ddSendrecv (const gmx_domdec_t *dd, int ddDimensionIndex, int
│ │ │ │ │ direction, T *sendBuffer, int numElementsToSend, T *receiveBuffer, int
│ │ │ │ │ numElementsToReceive)
│ │ │ │ │ This function template is deprecated, new calls should be made to the
│ │ │ │ │ version taking ArrayRef parameters and this function template removed
│ │ │ │ │ when unused.
│ │ │ │ │ Member df_history_t
│ │ │ │ │ @@ -33,34 +18,49 @@
│ │ │ │ │ Member DIR_SEPARATOR
│ │ │ │ │ Get rid of this (Redmine #950). It is not necessary for constructing
│ │ │ │ │ paths on the systems that it currently supports, and is not reliable in
│ │ │ │ │ parsing input paths either, since Windows needs to accept both instead of
│ │ │ │ │ only DIR_SEPARATOR. At the very least, we should refactor the clients of
│ │ │ │ │ this header so that they operate upon path objects rather than raw path
│ │ │ │ │ strings.
│ │ │ │ │ - File domdec_network.h
│ │ │ │ │ - Wrap the raw dd_bcast in md.cpp into a higher-level function in the
│ │ │ │ │ - domdec module, then this file can be module-internal.
│ │ │ │ │ Member fit_acf (int ncorr, int fitfn, const gmx_output_env_t *oenv, gmx_bool
│ │ │ │ │ bVerbose, real tbeginfit, real tendfit, real dt, real c1[], real *fit)
│ │ │ │ │ check parameters
│ │ │ │ │ + Member AtomProperties::atomNumberFromElement (const char *element)
│ │ │ │ │ + This should be made const once the lazy implementation is done properly
│ │ │ │ │ + for the class.
│ │ │ │ │ + Member AtomProperties::elementFromAtomNumber (int atomNumber)
│ │ │ │ │ + This should be made const once the lazy implementation is done properly
│ │ │ │ │ + for the class.
│ │ │ │ │ + Class BondedInteractionList
│ │ │ │ │ + This should be merged with BondedInteraction.
│ │ │ │ │ + Member buildSupportsNonbondedOnGpu (std::string *error)
│ │ │ │ │ + Move this to NB module once it exists.
│ │ │ │ │ + Member clearModificationBlock (MoleculePatchDatabase *globalPatches)
│ │ │ │ │ + Remove once constructor/destructor takes care of all of this.
│ │ │ │ │ + Member copyPreprocessResidues (const PreprocessResidue &s, PreprocessResidue
│ │ │ │ │ + *d, t_symtab *symtab)
│ │ │ │ │ + Remove once copy can be done directly.
│ │ │ │ │ + File domdec_network.h
│ │ │ │ │ + Wrap the raw dd_bcast in md.cpp into a higher-level function in the
│ │ │ │ │ + domdec module, then this file can be module-internal.
│ │ │ │ │ Class gmx::AbstractAnalysisArrayData
│ │ │ │ │ Add support for multiple data sets.
│ │ │ │ │ Class gmx::AbstractAnalysisData
│ │ │ │ │ Improve the exception-handling semantics. In most cases, it doesn't make
│ │ │ │ │ much sense to continue data processing after one module fails, but having
│ │ │ │ │ the alternative would not hurt.
│ │ │ │ │ Member gmx::AbstractAnalysisData::addColumnModule (int col, int span, const
│ │ │ │ │ AnalysisDataModulePointer &module)
│ │ │ │ │ - Generalize this method to multiple data sets (e.g., for adding modules
│ │ │ │ │ - that only process a single data set).
│ │ │ │ │ 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).
│ │ │ │ │ Member gmx::AbstractAnalysisData::applyModule (IAnalysisDataModule *module)
│ │ │ │ │ Currently, this method may not work correctly if module requests storage
│ │ │ │ │ (addModule() has the same problem if called after data is started).
│ │ │ │ │ Member gmx::AbstractOptionStorage::processSet ()=0
│ │ │ │ │ Improve the call semantics.
│ │ │ │ │ Class gmx::AnalysisData
│ │ │ │ │ Parallel implementation is not complete.
│ │ │ │ │ @@ -68,19 +68,19 @@
│ │ │ │ │ Use a proper enum.
│ │ │ │ │ Class gmx::AnalysisDataStorage
│ │ │ │ │ Proper multi-threaded implementation.
│ │ │ │ │ Class gmx::AnalysisNeighborhood
│ │ │ │ │ Generalize the exclusion machinery to make it easier to use for other
│ │ │ │ │ cases than atom-atom exclusions from the topology.
│ │ │ │ │ Class gmx::AnalysisNeighborhoodSearch
│ │ │ │ │ + Consider removing minimumDistance(), as nearestPoint() already returns
│ │ │ │ │ + the distance.
│ │ │ │ │ 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.
│ │ │ │ │ Class gmx::ArrayRef<_T_>
│ │ │ │ │ This class is not complete. There are likely also methods missing (not
│ │ │ │ │ required for current usage).
│ │ │ │ │ Class gmx::Awh
│ │ │ │ │ Update parameter reading and checkpointing, when general C++ framework is
│ │ │ │ │ ready.
│ │ │ │ │ Member gmx::BoxMatrix
│ │ │ │ │ @@ -97,22 +97,22 @@
│ │ │ │ │ compatible GPUs can be different on each node, so this routine ought to
│ │ │ │ │ do communication to determine whether all ranks are able to proceed.
│ │ │ │ │ Currently this relies on the MPI runtime to kill the other processes
│ │ │ │ │ because GROMACS lacks the appropriate infrastructure to do a good job of
│ │ │ │ │ coordinating error messages and behaviour across MPMD ranks and multiple
│ │ │ │ │ simulations.
│ │ │ │ │ Class gmx::ClfftInitializer
│ │ │ │ │ - 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 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.
│ │ │ │ │ Class gmx::compat::not_null<_T_>
│ │ │ │ │ Eliminate this when we require a version of C++ that supports std::
│ │ │ │ │ not_null.
│ │ │ │ │ Member gmx::Constraints::setConstraints (const gmx_localtop_t &top, const
│ │ │ │ │ t_mdatoms &md)
│ │ │ │ │ Make this a callback that is called automatically once a new domain has
│ │ │ │ │ been made.
│ │ │ │ │ @@ -169,18 +169,18 @@
│ │ │ │ │ responsbility should move elsewhere.
│ │ │ │ │ Member gmx::GpuTaskAssignments::reportGpuUsage (const MDLogger &mdlog, bool
│ │ │ │ │ printHostName, bool useGpuForBonded, PmeRunMode pmeRunMode, bool
│ │ │ │ │ useGpuForUpdate)
│ │ │ │ │ It could be useful to report also whether any nodes differed, and in what
│ │ │ │ │ way.
│ │ │ │ │ Class gmx::GpuTaskAssignmentsBuilder
│ │ │ │ │ - Later we might need the concept of computeTasksOnThisRank, from which we
│ │ │ │ │ - construct gpuTasksOnThisRank.
│ │ │ │ │ Later, this might become a loop over all registered modules relevant to
│ │ │ │ │ the mdp inputs, to find those that have such tasks.
│ │ │ │ │ + Later we might need the concept of computeTasksOnThisRank, from which we
│ │ │ │ │ + construct gpuTasksOnThisRank.
│ │ │ │ │ Member gmx::GromacsException::prependContext (const std::string &context)
│ │ │ │ │ The added information is currently not accessible through what(), nor
│ │ │ │ │ through any other means except for calling printFatalErrorMessage(),
│ │ │ │ │ formatExceptionMessageToString() or formatExceptionMessageToFile(). See
│ │ │ │ │ ExceptionInitializer for more discussion.
│ │ │ │ │ Member gmx::HelpWriterContext::setReplacement (const std::string &search,
│ │ │ │ │ const std::string &replace)
│ │ │ │ │ @@ -211,22 +211,22 @@
│ │ │ │ │ Member gmx::LegacyMdrunOptions::oenv
│ │ │ │ │ Clarify initialization, ownership, and lifetime.
│ │ │ │ │ Class gmx::MDAtoms
│ │ │ │ │ The group-scheme kernels needed a plain C-style t_mdatoms, so this type
│ │ │ │ │ combines that with the memory management needed for efficient PME on GPU
│ │ │ │ │ transfers. The mdatoms_ member should be removed.
│ │ │ │ │ Class gmx::Mdrunner
│ │ │ │ │ - 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).
│ │ │ │ │ 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).
│ │ │ │ │ Member gmx::Mdrunner::addPotential (std::shared_ptr< IRestraintPotential >
│ │ │ │ │ restraint, const std::string &name)
│ │ │ │ │ Mdrunner should fetch such resources from the SimulationContext rather
│ │ │ │ │ than offering this public interface.
│ │ │ │ │ Member gmx::openTNG (const std::string &name, const Selection &sel, const
│ │ │ │ │ gmx_mtop_t *mtop)
│ │ │ │ │ Those should be methods in a replacement for t_trxstatus instead.
│ │ │ │ │ @@ -282,81 +282,50 @@
│ │ │ │ │ Wrapping is not currently implemented for code that writes partial lines
│ │ │ │ │ with writeString().
│ │ │ │ │ Member gmx::TopologyInformation::fillFromInputFile (const std::string
│ │ │ │ │ &filename)
│ │ │ │ │ This should throw upon error but currently does not.
│ │ │ │ │ Class gmx::TrajectoryAnalysisSettings
│ │ │ │ │ Remove plain flags from the public interface.
│ │ │ │ │ - Member GMX_UNUSED_VALUE (value)
│ │ │ │ │ - Deprecated - use gmx_unused
│ │ │ │ │ - Member init_bonded_threading (FILE *fplog, int nenergrp)
│ │ │ │ │ - Avoid explicit pointers by using Impl
│ │ │ │ │ - Module module_modularsimulator
│ │ │ │ │ - Can we link to docs/doxygen/lib/modularsimulator.md?
│ │ │ │ │ - Member pme_gpu_reinit_computation (const gmx_pme_t *pme, gmx_wallcycle
│ │ │ │ │ - *wcycle)
│ │ │ │ │ - Rename this function to clear – it clearly only does output resetting and
│ │ │ │ │ - we should be clear about what the function does..
│ │ │ │ │ - Member pme_gpu_task_enabled (const gmx_pme_t *pme)
│ │ │ │ │ - This is a rather static data that should be managed by the hardware
│ │ │ │ │ - assignment manager. For now, it is synonymous with the active PME
│ │ │ │ │ - codepath (in the absence of dynamic switching).
│ │ │ │ │ - File pme_gpu_types_host.h
│ │ │ │ │ - Some renaming/refactoring, which does not impair the performance: –
│ │ │ │ │ - bringing the function names up to guidelines – PmeGpuSettings -
│ │ │ │ │ - > PmeGpuTasks – refining GPU notation application (#2053) – renaming
│ │ │ │ │ - coefficients to charges (?)
│ │ │ │ │ - Member PreprocessingAtomTypes::atomTypeFromName (const std::string &str)
│ │ │ │ │ - const
│ │ │ │ │ - The code should be changed to instead use a gmx::compat version of std::
│ │ │ │ │ - optional to return an iterator to the element being searched, or an empty
│ │ │ │ │ - optional construct if the entry has not been found.
│ │ │ │ │ - Member PreprocessingBondAtomType::bondAtomTypeFromName (const std::string
│ │ │ │ │ - &str) const
│ │ │ │ │ - The code should be changed to instead use a gmx::compat version of std::
│ │ │ │ │ - optional to return a handle to the element being searched, or an empty
│ │ │ │ │ - optional construct if the entry has not been found.
│ │ │ │ │ - Member set_over_alloc_dd (gmx_bool set)
│ │ │ │ │ - This is mdrun-specific, so it might be better to put this and
│ │ │ │ │ - over_alloc_dd() much higher up.
│ │ │ │ │ - File simulationsignal.h
│ │ │ │ │ - Move this to mdrunutility module alongside gathering multi-simulation
│ │ │ │ │ - communication infrastructure there.
│ │ │ │ │ - File update_constrain_cuda.h
│ │ │ │ │ - Change "cuda" suffix to "gpu"
│ │ │ │ │ Class gmx_gpu_info_t
│ │ │ │ │ Use a std::vector
│ │ │ │ │ Class gmx_multisim_t
│ │ │ │ │ Change this to class
│ │ │ │ │ Member gmx_pme_init (const t_commrec *cr, const NumPmeDomains &numPmeDomains,
│ │ │ │ │ const t_inputrec *ir, gmx_bool bFreeEnergy_q, gmx_bool bFreeEnergy_lj,
│ │ │ │ │ gmx_bool bReproducible, real ewaldcoeff_q, real ewaldcoeff_lj, int nthread,
│ │ │ │ │ PmeRunMode runMode, PmeGpu *pmeGpu, const gmx_device_info_t *gpuInfo,
│ │ │ │ │ PmeGpuProgramHandle pmeGpuProgram, const gmx::MDLogger &mdlog)
│ │ │ │ │ We should evolve something like a 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.
│ │ │ │ │ + Member GMX_UNUSED_VALUE (value)
│ │ │ │ │ + Deprecated - use gmx_unused
│ │ │ │ │ File gpu_testutils.h
│ │ │ │ │ This should eventually go to src/testutils
│ │ │ │ │ File handlerestart.h
│ │ │ │ │ There may be other code in runner.cpp etc. that can usefully live here
│ │ │ │ │ Class history_t
│ │ │ │ │ Rename this with a more descriptive name.
│ │ │ │ │ File hostallocator.h
│ │ │ │ │ This should not be in the public API, but it needs to be for the moment
│ │ │ │ │ because state.h is in that API.
│ │ │ │ │ + Member init_bonded_threading (FILE *fplog, int nenergrp)
│ │ │ │ │ + Avoid explicit pointers by using Impl
│ │ │ │ │ File iserializer.h
│ │ │ │ │ Generalize and transfer serialization functionality used in mrc density
│ │ │ │ │ file header serialization to here.
│ │ │ │ │ Module module_domdec
│ │ │ │ │ Get domdec stuff out of mdtypes/commrec.h
│ │ │ │ │ Module module_imd
│ │ │ │ │ Rename the directory, source and test files to interactive_md, and prefer
│ │ │ │ │ type names like InteractiveMDSession. Avoid ambiguity with IMDModule.
│ │ │ │ │ + Module module_modularsimulator
│ │ │ │ │ + Can we link to docs/doxygen/lib/modularsimulator.md?
│ │ │ │ │ File optional.h
│ │ │ │ │ Remove when requiring C++17, which has a standardized version of std::
│ │ │ │ │ optional.
│ │ │ │ │ File pbc_aiuc.h
│ │ │ │ │ CPU, GPU and SIMD routines essentially do the same operations on
│ │ │ │ │ different data-types. Currently this leads to code duplication, which has
│ │ │ │ │ to be resolved. For details, see Redmine task #2863 https://
│ │ │ │ │ @@ -366,27 +335,58 @@
│ │ │ │ │ This routine operates on rvec types and uses PbcAiuc to define periodic
│ │ │ │ │ box, but essentially does the same thing as SIMD and GPU version. These
│ │ │ │ │ will have to be unified in future to avoid code duplication. See Redmine
│ │ │ │ │ task #2863: https://redmine.gromacs.org/issues/2863
│ │ │ │ │ Member pmalloc (void **h_ptr, size_t nbytes)
│ │ │ │ │ This function should allocate page-locked memory to help reduce D2H and
│ │ │ │ │ H2D transfer times, similar with pmalloc from pmalloc_cuda.cu.
│ │ │ │ │ + Member pme_gpu_reinit_computation (const gmx_pme_t *pme, gmx_wallcycle
│ │ │ │ │ + *wcycle)
│ │ │ │ │ + Rename this function to clear – it clearly only does output resetting and
│ │ │ │ │ + we should be clear about what the function does..
│ │ │ │ │ + Member pme_gpu_task_enabled (const gmx_pme_t *pme)
│ │ │ │ │ + This is a rather static data that should be managed by the hardware
│ │ │ │ │ + assignment manager. For now, it is synonymous with the active PME
│ │ │ │ │ + codepath (in the absence of dynamic switching).
│ │ │ │ │ + File pme_gpu_types_host.h
│ │ │ │ │ + Some renaming/refactoring, which does not impair the performance: –
│ │ │ │ │ + bringing the function names up to guidelines – PmeGpuSettings -
│ │ │ │ │ + > PmeGpuTasks – refining GPU notation application (#2053) – renaming
│ │ │ │ │ + coefficients to charges (?)
│ │ │ │ │ Member pme_run_mode (const gmx_pme_t *pme)
│ │ │ │ │ This is a rather static data that should be managed by the higher level
│ │ │ │ │ task scheduler.
│ │ │ │ │ Member PmeRunMode
│ │ │ │ │ : make this enum class with gmx_pme_t C++ refactoring
│ │ │ │ │ + Member PreprocessingAtomTypes::atomTypeFromName (const std::string &str)
│ │ │ │ │ + const
│ │ │ │ │ + The code should be changed to instead use a gmx::compat version of std::
│ │ │ │ │ + optional to return an iterator to the element being searched, or an empty
│ │ │ │ │ + optional construct if the entry has not been found.
│ │ │ │ │ + Member PreprocessingBondAtomType::bondAtomTypeFromName (const std::string
│ │ │ │ │ + &str) const
│ │ │ │ │ + The code should be changed to instead use a gmx::compat version of std::
│ │ │ │ │ + optional to return a handle to the element being searched, or an empty
│ │ │ │ │ + optional construct if the entry has not been found.
│ │ │ │ │ + Member set_over_alloc_dd (gmx_bool set)
│ │ │ │ │ + This is mdrun-specific, so it might be better to put this and
│ │ │ │ │ + over_alloc_dd() much higher up.
│ │ │ │ │ + File simulationsignal.h
│ │ │ │ │ + Move this to mdrunutility module alongside gathering multi-simulation
│ │ │ │ │ + communication infrastructure there.
│ │ │ │ │ File snprintf.h
│ │ │ │ │ When all callers of snprintf compile as C++, perhaps use gmx::
│ │ │ │ │ formatString() everywhere instead of snprintf.
│ │ │ │ │ File string_view.h
│ │ │ │ │ Remove when requiring C++17, which has a standardized version of std::
│ │ │ │ │ string_view.
│ │ │ │ │ Class t_matrix
│ │ │ │ │ nx and ny should probably be replaced by operations on the extent of
│ │ │ │ │ matrix, but currently there is only limited ability to iterate over
│ │ │ │ │ contents of matrix.
│ │ │ │ │ Class t_state
│ │ │ │ │ Move pure observables history to ObservablesHistory.
│ │ │ │ │ + File update_constrain_cuda.h
│ │ │ │ │ + Change "cuda" suffix to "gpu"
│ │ │ │ │
│ │ │ │ │ ===============================================================================
│ │ │ │ │ Generated by [doxygen] 1.9.1
│ │ │ ├── ./usr/share/doc/gromacs/html/doxygen/html-user/todo.xhtml
│ │ │ │┄ Ordering differences only
│ │ │ │ @@ -71,16 +71,14 @@
│ │ │ │ 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).
│ │ │ │ @@ -95,22 +93,18 @@ │ │ │ │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.
│ │ │ │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.
│ │ │ │ │ │ │ │docs/doxygen/lib/modularsimulator.md? docs/doxygen/lib/modularsimulator.md? Mark Abraham, Berk Hess, David van der Spoel, and Erik Lindahl.
│ │ │ │© 1991 – 2000:
│ │ │ ││ │ │ ││ │ │ │ -Department of Biophysical Chemistry, University of Groningen. │ │ │ │ Nijenborgh 4, 9747 AG Groningen, The Netherlands.
│ │ │ │
© 2001 – 2025:
│ │ │ │ +© 2001 – 2024:
│ │ │ ││ │ │ ││ │ │ │The GROMACS development teams at the Royal Institute of Technology and │ │ │ │ Uppsala University, Sweden.
│ │ │ │
This manual is not complete and has no pretension to be so due │ │ │ │ to lack of time of the contributors – our first priority is to improve │ │ │ │ the software. It is worked on continuously, │ │ │ │ ├── html2text {} │ │ │ │ │ @@ -25,15 +25,15 @@ │ │ │ │ │ Meulenhoff, Teemu Murtola, Szilárd Páll, Sander Pronk, Roland Schulz, Michael │ │ │ │ │ Shirts, Alexey Shvetsov, Alfons Sijbers, Peter Tieleman, Teemu Virolainen, │ │ │ │ │ Christian Wennberg, Maarten Wolf, and Artem Zhmurov. │ │ │ │ │ Mark Abraham, Berk Hess, David van der Spoel, and Erik Lindahl. │ │ │ │ │ © 1991 â 2000: │ │ │ │ │ Department of Biophysical Chemistry, University of Groningen. │ │ │ │ │ Nijenborgh 4, 9747 AG Groningen, The Netherlands. │ │ │ │ │ -© 2001 â 2025: │ │ │ │ │ +© 2001 â 2024: │ │ │ │ │ The GROMACS development teams at the Royal Institute of Technology │ │ │ │ │ and Uppsala University, Sweden. │ │ │ │ │ This manual is not complete and has no pretension to be so due to lack of time │ │ │ │ │ of the contributors â our first priority is to improve the software. It is │ │ │ │ │ worked on continuously, which in some cases might mean the information is not │ │ │ │ │ entirely correct. │ │ │ │ │ Comments on form and content are welcome, please send them to one of the │ │ │ ├── ./usr/share/doc/gromacs/html/searchindex.js │ │ │ │ ├── js-beautify {} │ │ │ │ │ @@ -909,16 +909,16 @@ │ │ │ │ │ "2015": [144, 145], │ │ │ │ │ "2016": [1, 145, 160, 161, 167, 168, 169, 170, 171, 178, 182], │ │ │ │ │ "2017": [36, 145, 157, 158, 160, 182, 194], │ │ │ │ │ "2018": [1, 25, 159, 176, 182, 183, 184, 185, 186, 187, 189, 191, 193, 201, 226], │ │ │ │ │ "2019": [2, 4, 28, 145, 171, 172, 173, 174, 191, 197, 198, 199, 200, 201, 226], │ │ │ │ │ "2020": [2, 24, 26, 36, 144, 187, 206], │ │ │ │ │ "2021": [198, 201, 202, 212], │ │ │ │ │ - "2024": 174, │ │ │ │ │ - "2025": [144, 155], │ │ │ │ │ + "2024": [144, 174], │ │ │ │ │ + "2025": 155, │ │ │ │ │ "2026": 181, │ │ │ │ │ "2027": 181, │ │ │ │ │ "2028": 181, │ │ │ │ │ "2029": 155, │ │ │ │ │ "2031": 174, │ │ │ │ │ "2032": [45, 145, 174], │ │ │ │ │ "2033": 155, ├── libgromacs-dev_2020.6-2_amd64.deb │ ├── control.tar.xz │ │ ├── control.tar │ │ │ ├── ./md5sums │ │ │ │ ├── ./md5sums │ │ │ │ │┄ Files differ │ ├── data.tar.xz │ │ ├── data.tar │ │ │ ├── file list │ │ │ │ @@ -134,19 +134,19 @@ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1722 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gmxapi/gmxapi-config-version.cmake │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1181 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gmxapi/gmxapi-config.cmake │ │ │ │ -rw-r--r-- 0 root (0) root (0) 940 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gmxapi/gmxapi-release.cmake │ │ │ │ -rw-r--r-- 0 root (0) root (0) 3281 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gmxapi/gmxapi.cmake │ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs/ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 2025 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs/gromacs-config-version.cmake │ │ │ │ -rw-r--r-- 0 root (0) root (0) 6217 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs/gromacs-config.cmake │ │ │ │ --rw-r--r-- 0 root (0) root (0) 2319 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs/gromacs-toolchain.cmake │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 2312 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs/gromacs-toolchain.cmake │ │ │ │ -rw-r--r-- 0 root (0) root (0) 855 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs/libgromacs-release.cmake │ │ │ │ -rw-r--r-- 0 root (0) root (0) 3592 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs/libgromacs.cmake │ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs_d/ │ │ │ │ --rw-r--r-- 0 root (0) root (0) 2319 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs_d/gromacs-toolchain_d.cmake │ │ │ │ +-rw-r--r-- 0 root (0) root (0) 2312 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs_d/gromacs-toolchain_d.cmake │ │ │ │ -rw-r--r-- 0 root (0) root (0) 2025 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs_d/gromacs_d-config-version.cmake │ │ │ │ -rw-r--r-- 0 root (0) root (0) 6222 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs_d/gromacs_d-config.cmake │ │ │ │ -rw-r--r-- 0 root (0) root (0) 861 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs_d/libgromacs-release.cmake │ │ │ │ -rw-r--r-- 0 root (0) root (0) 3592 2021-03-29 04:45:03.000000 ./usr/share/gromacs/cmake/gromacs_d/libgromacs.cmake │ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2021-03-29 04:45:03.000000 ./usr/share/gromacs/template/ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1851 2021-03-04 14:49:48.000000 ./usr/share/gromacs/template/CMakeLists.txt │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1196 2021-03-04 14:49:48.000000 ./usr/share/gromacs/template/Makefile.pkg │ │ │ ├── ./usr/share/gromacs/cmake/gromacs/gromacs-toolchain.cmake │ │ │ │ @@ -30,15 +30,15 @@ │ │ │ │ # official version at http://www.gromacs.org. │ │ │ │ # │ │ │ │ # To help us fund GROMACS development, we humbly ask that you cite │ │ │ │ # the research papers on the package. Check out http://www.gromacs.org. │ │ │ │ │ │ │ │ # Setting CMAKE_SYSTEM_NAME tells CMake we are cross compiling. │ │ │ │ SET(CMAKE_SYSTEM_NAME "Linux") │ │ │ │ -SET(CMAKE_SYSTEM_VERSION "6.5.0-0.deb12.4-amd64") │ │ │ │ +SET(CMAKE_SYSTEM_VERSION "6.1.0-17-amd64") │ │ │ │ SET(CMAKE_C_COMPILER "/usr/bin/cc") │ │ │ │ SET(CMAKE_CXX_COMPILER "/usr/bin/c++") │ │ │ │ SET(CMAKE_LINKER "/usr/bin/ld") │ │ │ │ # The following are only relevant in Mac OS X environments. │ │ │ │ SET(CMAKE_OSX_DEPLOYMENT_TARGET "" CACHE STRING "OS X Deployment target" FORCE) │ │ │ │ SET(CMAKE_OSX_ARCHITECTURES "") │ │ │ │ # Ref: https://stackoverflow.com/questions/32414112/setting-sdk-on-cross-compilation-to-osx-in-cmake │ │ │ ├── ./usr/share/gromacs/cmake/gromacs_d/gromacs-toolchain_d.cmake │ │ │ │ @@ -30,15 +30,15 @@ │ │ │ │ # official version at http://www.gromacs.org. │ │ │ │ # │ │ │ │ # To help us fund GROMACS development, we humbly ask that you cite │ │ │ │ # the research papers on the package. Check out http://www.gromacs.org. │ │ │ │ │ │ │ │ # Setting CMAKE_SYSTEM_NAME tells CMake we are cross compiling. │ │ │ │ SET(CMAKE_SYSTEM_NAME "Linux") │ │ │ │ -SET(CMAKE_SYSTEM_VERSION "6.5.0-0.deb12.4-amd64") │ │ │ │ +SET(CMAKE_SYSTEM_VERSION "6.1.0-17-amd64") │ │ │ │ SET(CMAKE_C_COMPILER "/usr/bin/cc") │ │ │ │ SET(CMAKE_CXX_COMPILER "/usr/bin/c++") │ │ │ │ SET(CMAKE_LINKER "/usr/bin/ld") │ │ │ │ # The following are only relevant in Mac OS X environments. │ │ │ │ SET(CMAKE_OSX_DEPLOYMENT_TARGET "" CACHE STRING "OS X Deployment target" FORCE) │ │ │ │ SET(CMAKE_OSX_ARCHITECTURES "") │ │ │ │ # Ref: https://stackoverflow.com/questions/32414112/setting-sdk-on-cross-compilation-to-osx-in-cmake