Catch need for t_graph in modular simulator more gracefully - Redmine #3389

t_graph is currently disabled in modular simulator, but input requesting it is not always caught and redirected to the legacy code path. If t_graph is requested in modular simulator, the simulation will crash with a non-descriptive error (“We use a graph with PBC (no periodic mols) and without DD”). No wrong results are computed (as the run fails during setup phase).

Proposed solution

As the reintroduction of t_graph might be a bit complex for a patch release, I suggest to catch the cases requesting t_graph and redirect them to the legacy code path. Also, as an added security, I’d suggest to add a more graceful exit in case that modular simulator is requested to use t_graph.

Which combinations of input require the use of t_graph?

The graph object is used if

• no DD is used, and
• PBC are used (i.e. inputrec->ePBC != epbcNONE), and
• molecules are never distributed over PBC boundaries (forcerec->bMolPBC == false).

While the first two conditions are true for most single rank simulations, the last one is not generally true, as we prefer not to guarantee whole molecules (performance!). In non-DD cases, we guarantee whole molecules if

• shake is used (shake also forbids periodic (self-interacting) molecules, and discourages intermolecular bonded interactions), or
• orientation restraints are used, or
• Ewald surface corrections are used.

Finally, the use of graph (and hence whole molecules) can be forced by setting the environment variable GMX_USE_GRAPH.

(from redmine: issue id 3389, created on 2020-02-21 by ptmerz, closed on 2020-02-28)

• Changesets:
  • Revision dad5f857 on 2020-02-27T11:55:01Z:

Use legacy code path for t_graph (modular simulator)

This change redirects simulations which will require a t_graph object
to the legacy code path. It also adds an assert to catch cases in which
the redirection would fail in a more graceful way.

Fixes #3389

Change-Id: I17a70e504c206b2798cd2439c0c0ff5d5cd112e3