Feature #2587

Updated by Eric Irrgang about 2 years ago

gmxapi milestone 5 as described in #2585


(gmx5 in #2585)
Instead of relying on a global variable for ProgramContext, explicitly require client code to pass a context object to library code. This allows a context to be configured differently depending on the use case of the client code, as well as to capture details of the computing environment that could be better abstracted.

This issue covers restructuring of GROMACS to support an expanded role of client-managed “context”. Specific enhancements are deferred to downstream issues to be linked from here.

Near term goals of the expanded role for the Context include
* Support run-time extensibility of MD code, such as by providing a source of factory functions from which MD module implementation code can be retrieved.
* ownership of highest level communicator(s) and source of simulation-level communicators
* Translation of ANSI C signals to GROMACS signalling facilities
* Handling of logging and status messaging

Longer term goals include
* Negotiating allocation of computing resources
* I/O abstractions and filesystem-decoupling
* Interfaces for workflow-level check-pointing


This issue requires that code like gmx::Mdrunner (and the call stack below) receive the context from the client code. A context implementation should not _require_ global variables, and as much as possible globals should be removed from the current ProgramContext.

Provisions for runtime extensibility:

* Library-facing Context interface provides factory functions for, e.g.
- MDModules
- Communications
- Logger
- Messenger
- Reference data
- I/O
* Simple C API allows registering resource providers named in simple hierarchical schema.