You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provide data structures as Session resources that the Context implementation can checkpoint. External code can use these data structures to maintain state.
We can discuss whether and how we could use the TensorFlow concept of variables in addition to graph edges, but right now we should clarify that our check-pointable data is as edges. Then, we have data source nodes that initiate data flow on a stream and implicitly (magically) receive the data at the end of a pass through the graph to provide the updated stream on the next iteration. What we could do is to let edges essentially push data events, while "variables" are accessible in a token-passing sort of way, where the graph director for an operation just has to make sure that there are nodes in the right topology for the object code to have the token at the right time. The token is in the form of the Session Resources object that is available to a node when it is its turn to run.
This would all be so much easier if we could tell GROMACS to run to a specified step and then surrender control to the API. The alternative, I think we have to say that any cluster of nodes associated with a simulation is deferred to the libgromacs Context for handling. We've already inserted an object into do_md to manage the stop condition, so we can use it to synchronize the gmxapi Session by adding an additional hook that calls out to the Session each time the timestep is incremented, preferably after the PP coordinates data is in place...
The text was updated successfully, but these errors were encountered:
Provide data structures as Session resources that the Context implementation can checkpoint. External code can use these data structures to maintain state.
We can discuss whether and how we could use the TensorFlow concept of variables in addition to graph edges, but right now we should clarify that our check-pointable data is as edges. Then, we have data source nodes that initiate data flow on a stream and implicitly (magically) receive the data at the end of a pass through the graph to provide the updated stream on the next iteration. What we could do is to let edges essentially push data events, while "variables" are accessible in a token-passing sort of way, where the graph director for an operation just has to make sure that there are nodes in the right topology for the object code to have the token at the right time. The token is in the form of the Session Resources object that is available to a node when it is its turn to run.
This would all be so much easier if we could tell GROMACS to run to a specified step and then surrender control to the API. The alternative, I think we have to say that any cluster of nodes associated with a simulation is deferred to the libgromacs Context for handling. We've already inserted an object into do_md to manage the stop condition, so we can use it to synchronize the gmxapi Session by adding an additional hook that calls out to the Session each time the timestep is incremented, preferably after the PP coordinates data is in place...
The text was updated successfully, but these errors were encountered: