gmxapi milestone 5 as described in \#2585 Proposal: 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 Completion: 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. *(from redmine: issue id 2587, created on 2018-07-24 by eirrgang)* * Relations: * blocks #2605 * parent #2585 * Changesets: * Revision f3ff9147ca51a69671d1b6e2141aa637b3c29c59 by Eric Irrgang on 2018-10-03T11:33:15Z: ``` Move mdrun mainFunction to client code. supports gmxapi milestone 4, described at #2605 API clients need to be able to initialize and run MD simulations with calls from separate code blocks or even translation units. Also, we need clear distinctions between a pre-launch master Mdrunner and the non-master Mdrunner threads. In this change: * Insert a Builder on which to develop the distinction between user interface and implementation code. User interface is handled in Director code, while the Builder and code further down the mdrun call stack should be user interface agnostic (i.e. not CLI-centric). * Introduces a Context object to hold some resources. (see milestone 5 and issue #2587) * Prepare for more stateful Mdrunner objects, documenting resources in need of clearer management, describing future use cases and possible implementation details. * Make Mdrunner non-copyable and not constructable by clients. Worker threads can initialize a new Mdrunner from the master instance with cloneOnSpawnedThread. * Clarify parameter setting for spawned Mdrunner threads. * Begin to encapsulate filename options available to client code from the actual client code. * Remove extraneous variables `nfile` and `fnm`. Later changes will: * Separate Mdrunner into Launcher and Worker at mdrunner() call so that tMPI runner does not look reentrant. * Hide data and clarify ownership / modernize memory management / clarify the subjects of the Builder `add` operations. * Clarify separation of user interface from API parameters. * Flesh out SimulationContext and related classes. Refs #2605 Change-Id: I1db1d34b07ec0f8ba5f246ab763c74ad9eafe8f3 ``` * Revision 7a90bcdbbcd77c94a2834b91d831e5ab49c8a07d by Eric Irrgang on 2018-10-03T15:27:37Z: ``` Add gmxapi::Context. The Context holds the details necessary to launch work in a given environment. A runtime session is launched using the configured details of a Context implementation and the object bindings configured by the user (managed by the Context). Part of a sequence of changes introducing gmxapi classes System, Context, Session, and Workflow. Supports gmxapi milestone 5 Refs: #2587 Change-Id: I75baed9b5c856f284bc2c2370ef284319e95f13e ``` * Revision e39949c724b1eab099e81212951e05b082d67243 by Mark Abraham on 2019-10-01T05:24:02Z: ``` Removed dependency on commrec of mdrun setup Changes no functionality. Setup is now parameterized directly on MPI_COMM_WORLD, which we will want later for letting library-based callers pass in an MPI_Communicator. This permits commrec to be initialized later, once the threads have been spawned for the thread-MPI ranks. The initialization of multi-simulations moves from LegacyMdrunOptions to SimulationContext, which is more appropriate for ensemble-parallelism established directly by the user. Before the decision about the duty of a rank, there is no difference between MASTER(cr) and SIMMASTER(cr), so several calls to macros taking a t_commrec pointer are replaced by booleans. Introduced findIsSimulationMasterRank to compute that value. This eliminates early use of t_commrec that has necessitated other hacks and workarounds. Removed redundant check for replica exchange when the number of multi simulations is less than two, because gmx_multisim_t constructor already prohibits that. Resolves several TODO items and improves modularity, too. Refs #2587, #2605, #3081 Change-Id: I48bd3b713bc181b5c1e4cbcd648706a9f00eab96 ```