List view
Issues / tasks / discussions for branches prepared for submission upstream for inclusion in GROMACS 2019. This can be migrated to a Redmine issue at gromacs.org after some initial planning.
No due dateIssues related to porting gmxapi implementation details (gromacs-gmxapi) to the GROMACS master branch and GROMACS 2019 release.
No due date•5/7 issues closedWe can add a lot of handy little features to the Python interface to avoid resort to the command line and just generally make the gmx module more useful. Similarly, we should add some helper widgets to insert elements to grab data in flight and such things, but that is a separate set of issues.
No due date•2/5 issues closedSeveral tasks seem necessary to improve the Context abstraction. It seems like we should have some sort of Context associated with all workspec objects in the API to manage API interaction with the WorkSpec object. We can let the gmxapi environment have a default Context. When work is launched, The local default context might appropriately proxy API operations through a hierarchy of contexts, such as to the C++ library or to remote resources. The local context then becomes our avenue for keeping track of the state of execution and data and for proxying operations on local object handles to the executing context. This is also how we will hide interrupted connections, restarted sessions, etc. This also clarifies our middleware layer as a Context-to-Context API.
No due date•5/13 issues closedThe state of the workflow execution needs to be checkpoints, identifiable, and restorable. Possibly the trickiest part of this is interacting with the GROMACS checkpointing mechanism. This shouldn't be too hard, but there are several tasks. - [ ] Provide data structures as Session resources that the Context implementation can checkpoint. External code can use these data structures to maintain state. - [ ] Allow Context to inspect GROMACS checkpoint files to determine timestep. - [ ] Allow Context to automatically manipulate simulation input files to restore MD operation to a known state. - [ ] Allow a configurable interval of number of data events between checkpoints of data objects. This will probably only make sense to manage from the Session code, which will interact with GROMACS. - [ ] Presumably with some sort of checkpoint-participant interface in GROMACS, get a signal from GROMACS when a checkpoint is made and don't allow the workflow to proceed until a consistent set of checkpoints are made throughout. We may prefer something more abstract, but I don't know what that is right now. - [ ] Initialize nodes and replay the required data events. This is probably connected to discussions on the nature of the execution graph and edges. I think the entire state of the graph consists of the edge state and the initialization values of source nodes. Some of this can be clarified through discussions on refining the semantics of data graph execution, data events, and data state.
No due date•0/7 issues closedTargeted features require several updates to the workspec schema as well as to the semantics implied by the version.
No due date•7/29 issues closedMigrate the boiler plate out of the sample repository and develop more C++ templating to make for easy, flexible restraint forces and Python interface. Simplifying the interfaces warrants some additional tasks, so we can include in this milestone tasks related to registering operations with the context and generalizing or expanding the message passing and binding protocols. This is also a good place to deal with separation of Python and C++ domains and to decide what code belongs in the sample restraint versus gromacs-gmxapi versus gmxapi.
No due date•0/8 issues closed