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.
resultwill 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.