GROMACS

At https://gerrit.gromacs.org/#/c/6216/ we discussed some of the issues associated with how gmx_mtop objects are used, often in a not-very-const way that can invalidate the derived data that is stored alongside the raw topology information.

In writing and reviewing that patch, we did not remember that membed edits a topology, and so did not add the required call to the finalization routine, leading to #2364. Perhaps insert-molecules or genion is similarly broken? (check that for 2018, then re-target this task)

When we have API-driven simulations, we will need to have the ability to let the user do arbitrary operations on the topology, and for that to lead to correctly rebuilding whatever is required thereafter.

In the discussion at the above issue, I proposed that we construct an object from an mtop, and use that instead of a raw mtop in those parts of the code that use the derived information for efficient searching. As Teemu noted, that's potentially hundreds of callers, so we should decide carefully how to stage the work to make it manageable. (There are definitely alternative approaches, too)