-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unifying _single_frame() of AnalysisBase and ParallelAnalysisBase #131
Comments
This requires changes on the _single_frame function. It would break existing user code. Which makes this API change more complicated it will likely break downstream mdanalysis packages. Having it in pmda is fine. |
yeah..I realize it depends on results have to be saved inside analysis.parallel_run(n_jobs=cpu_count,
result_attr='timeseries') # or maybe a list of attr?
... so that users only need to fill in one extra thing for their code without touching their |
Generally speaking, we could break |
We did not break |
Note this only works after MDAnalysis/mdanalysis#2723 is merged to MDAnalysis
The key idea is not to break user's current codes and apply multiprocessing to AnalysisBase-based methods in MDAnalysis.
i.e. a deliverable like: AnalysisMethod.run(n_jobs=n_cpus).
As far as I am concerned, the key difference between
_single_frame()
ofAnalysisBase
andParallelAnalysisBase
is whether it modified the state, or it returns a value (as per discussion in #18). The workaround in the related PR is_single_frame
modifies the state (e.g. self._results), while_dask_helper
retrieves and returns the state value.As detailing in the PR #128 and the following showcase:
https://gist.github.com/yuxuanzhuang/937863d018621ad1fd9446c1f4a2bf3b
It is still quite preliminary, all suggestions are welcome.
The text was updated successfully, but these errors were encountered: