Bug #3389

Catch need for t_graph in modular simulator more gracefully

Added by Pascal Merz 6 months ago. Updated 6 months ago.

Target version:
Affected version - extra info:
Affected version:


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.

Associated revisions

Revision dad5f857 (diff)
Added by Pascal Merz 6 months ago

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


#1 Updated by Pascal Merz 6 months ago

  • Description updated (diff)

#2 Updated by Pascal Merz 6 months ago

  • Status changed from New to Fix uploaded
  • Private changed from Yes to No

#3 Updated by Mark Abraham 6 months ago

The analysis is consistent with my understanding of this

#4 Updated by Anonymous 6 months ago

  • Status changed from Fix uploaded to Resolved

#5 Updated by Paul Bauer 6 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF