Project

General

Profile

Feature #3179

Task #2045: API design and language bindings

Feature #2994: Data flow topology in gmxapi 2020

Clarify access to parallel data outputs

Added by Eric Irrgang about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
Category:
gmxapi
Target version:
-
Difficulty:
uncategorized
Close

Description

The gmxapi Future behavior originally tried to honor an optional "ensemble member" dimension for *result*s that might be associated with different members of a simulation trajectory ensemble. The original proposition was that a set of scalar results obtained in parallel could be converted to a local array with a gather function. Otherwise, the handle would serve as a view to the local subset of parallel data. result() was expected to reflect the static definition of an operation's behavior without requiring the user to consider the dimensionality of parallel data flow that might be implied by the actual work graph in which the operation occurs. This has been confusing and difficult to manage.

Proposal 1: Split result access to two modes.

  • result() can continue to try to provide the most intuitive conversion of a Future to process-local native data.
  • result[] will provide rich slicing behavior and always treat the full dimensionality of the data.

Internally, we can proceed quickly with implementing and using result[] for unambiguous behavior, while we consider the specified behavior of result() with more focus on user interface design and feedback.


Related issues

Related to GROMACS - Task #3139: gmxapi Futures should be subscribableNew

History

#1 Updated by Eric Irrgang about 1 month ago

  • Description updated (diff)

#2 Updated by Eric Irrgang about 1 month ago

  • Related to Task #3139: gmxapi Futures should be subscribable added

#3 Updated by Eric Irrgang about 1 month ago

  • Private changed from Yes to No

Also available in: Atom PDF