Expose Dask "lazy timeseries" from compatible readers for full parallelism in analysis

[ljwoods2]

Is your feature request related to a problem?

This idea follows up on @orbeckst's suggestion from a few months ago and a discussion with @hmacdope about making full use of dask in mda.

Current parallelism development allows splitting a trajectory into a number of parts and then combining intermediate results. However, allowing analysis classes to use dask arrays for positions, velocities, forces across the entire trajectory can cover cases that the split-apply-combine paradigm doesn't cover (like RMSF, AFAIK) and potentially lead to greater speedup.

Describe the solution you'd like

A DaskTimeSeriesAnalysisBase which accepts a dasktimeseries as an argument. A dask timeseries is exactly the same as a reader's timeseries except that it is a dask.array rather than a numpy.ndarray, so it is loaded lazily into memory and a dask task graph is created and optimized by dask automatically before .compute() is called.

Describe alternatives you've considered

Do nothing.

Additional context

I provide an extremely minimal example in PR #4714. Here, using dask to perform RMSF rather than in serial leads to a speedup of ~15x

Sample notebook available here: https://github.com/ljwoods2/mdanalysis/blob/dask-timeseries/tmp/lazyts.ipynb

[orbeckst]

Good idea (although RMSF (and anything that computes higher order moments) can be made to work with split-apply-combine, see PMDA RMSF and Nik's report referenced therein).

[ljwoods2]

Oh thank you, didn't know that existed, that would be a far better comparison

[RobertArbon]

Hi folks, I actually implemented trajectory analysis using Dask's dataframe class in a previous job. It was far from perfect but would be happy to work on this. I know you've added this as a project to GSOC (which I can't do) but would be happy to contribute or get something up an running.

[ljwoods2]

@RobertArbon Cool to see other people are interested in this, and thanks for reaching out. Why did you decide to go with dask dataframes instead of dask arrays? MDAnalysis analysis classes rely on the timestep's numpy array storage of the trajectory, so my initial thought was that dask arrays would be an easier conversion and potentially more natural, but it's totally possible I missed the mark.

Is the implementation open source in a fork somewhere? Would love to see your approach.

As far as GSoC, there is no guarantee that someone will actually be accepted for this particular project this year, but that will be decided by early-ish May

[RobertArbon]

Hi - I thought I replied to this.

the reason i wanted to use DataFrames was to mimic pandas for pieces of bespoke analysis and I (wrongly) thought that certain time-index subsetting might be easier this way. however, this turned out to be a dead end.

I will try and do a quick writeup/example of my approach to see if it inspires something, even it's to avoid certain ideas!

Alternatively, if there's something current with a specific issue I can submit a PR.