Clarify access to parallel data outputs
The gmxapi Future
behavior originally tried to honor an optional
“ensemble member” dimension for results 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.
Proposal 2: Allow for the validity of data shape ()
(scalar), distinct from shape (1,)
. Let mdrun(input)
and mdrun([input])
have distinct shapes, and let the user keep track of how they structured their input. Distinguish scalar and n-dimensional Future interfaces to determine whether the result
attribute supports result()
or result[]
.