Feature #2996
Task #2045: API design and language bindings
gmxapi execution model
Description
This issue documents and coordinates the development of the gmxapi execution model supporting the 2020 function requirements outlined in the roadmap document.
Key aspects include the following:
- Computational work and data transformations are defined as Operations, which are instantiated by client code as nodes of a directed acyclic work graph, connected by data flow edges.
- The factories used to get OperationHandles (work graph nodes) are context-dependent. In the basic use case, execution is deferred and the handle obtained provides a means of accessing Futures for the operation outputs.
- gmxapi is fully extensible, such that end users and third parties can write new operations or execution context implementations with well-defined API tools.
- Python base classes, meta classes, decorators / functionals, and dynamic type factories.
- C++ template headers and sample code.
Associated revisions
Separate out OperationDirector.
Develop abstractions for implementing operations with data flow.
Refs #2996
Change-Id: Ib0b899ea85a59c58ee33a5e3d8a28b33fb67047a
Separate out OperationDetailsBase.
Develop abstractions for implementing operations with data flow.
Refs #2996
Change-Id: Ie893039f2a73647ed254e0f4a68ed4e21de7a500
Separate out some abstract base classes.
Introduce SourceResource and AbstractOperation to improve consistency
and static type checking.
Refs #2996
Change-Id: If7a23ca66e21e55cd67a6242fd699507699423c0
History
#1 Updated by Eric Irrgang about 1 year ago
- Status changed from New to In Progress
- Target version changed from 2020 to 2021-infrastructure-stable
This task should include documentation, simplification, and updates, mostly to the Python framework for expressing and managing Contexts and Operation definitions, and will need to be addressed over the course of gmxapi development between 0.1 and 1.0.
Rearchitect gmxapi.operation
Includes many work-arounds for an incomplete data model,
illustrating what will need to be addressed in gmxapi
self-describing type system, data shaping, and Futures
implementation.
Introduced abstractions and refactoring to replace some
dynamic definitions in the function_wrapper closure with
composition or more tightly scoped closures. Provide
cleaner helpers for dynamically defined operation, input,
and output types.
accessors in standard interfaces, supporting similar
style of interaction with resources as in C++ extensions.
protocols.
Note that the execution dependency in FR2 has been superseded by the
data flow driven dependency in FR3. The syntax supported in FR2 is now
disabled to allow development towards FR4.
Refs #2993
Refs #2994
Refs #2996
Change-Id: I94a63d5801f97eb79962c693b48fa80a7c96c0ec