Skip to content
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

Concurrency for 2.0. Based on ecl2df and no eclsum caching #206

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

berland
Copy link
Collaborator

@berland berland commented Mar 17, 2021

New attempt for concurrency, taking over from #106.

Based on #182 , where eclsum caching is irrelevant.

* realization.get_smry() has changed to always return a dummy index
* cache_eclsum is pruned from fmu-ensemble.
The argument column_keys is no longer accepted by get_smry_meta().
All smry metadata available to a realization/ensemble is now always
returned by this function.

This function is no longer the recommended practice for a client script
to obtain the relevant summary vector metadata, API users should use
the attrs["meta"] property of the returned summary dataframes instead.
ensemble.get_smr() will no longer ensure that the dates returned
are identical in all realization, realizations with shorter timespans
will not be extrapolated as they were before.

This also affects get_smry_stats(), for which realizations
which failed prematurely earlier had zero rates, affecting statistical
profiles. Now these realization with truncated time-series will only
affect the statistical profiles in the time-range they have data for.
* Batch processing after init on ensembles

* Functionality for turning off concurrency

* Concurrent apply()

* Parallelize add_from_runpathfile

* Allow running find_files at init of realizations

* Parallelize get_smry()
@berland berland added this to the 2.0 milestone Mar 18, 2021
@berland berland linked an issue Mar 18, 2021 that may be closed by this pull request
@pinkwah
Copy link
Collaborator

pinkwah commented Apr 20, 2022

@berland is this still active? Should we move it to TODO?

@berland
Copy link
Collaborator Author

berland commented Apr 20, 2022

No, this PR is not active, and it is not clear that this is implemented correctly, the speedup is limited.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Multiprocessing
2 participants