Ensemble summary provider

[sigurdp]

Implements data providers for accessing ensemble summary data through a unified interface. Supports optional lazy resampling/interpolation depending on data input format .

Access to summary data for an ensemble is made available through the EnsembleSummaryProvider interface, implemented as an abstract class in Python.

Behind the scenes there is two different concrete implementations of the EnsembleSummaryProvider interface:

• ProviderImplArrowLazy - supports lazy/on demand resampling (only used when input data format in .arrow files)
• ProviderImplArrowPresampled - works similar to our current scheme where smry data is either used directly or is sampled at provider creation time.

Currently, all instances of EnsembleSummaryProvider should be created using the EnsembleSummaryProviderFactory singleton factory class, obtainable through EnsembleSummaryProviderFactory.instance(). There is currently four factory methods available for creating EnsembleSummaryProvider instances:

EnsembleSummaryProviderFactory.create_from_ensemble_csv_file()
EnsembleSummaryProviderFactory.create_from_per_realization_csv_file()
EnsembleSummaryProviderFactory.create_from_arrow_unsmry_lazy()
EnsembleSummaryProviderFactory.create_from_arrow_unsmry_presampled()

The factory methods mentioned above will create concrete data provider instances based on the input parameters specified. The two latter methods accept the same raw data input, but will create and return different concrete implementations of the EnsembleSummaryProvider interface.

---

Contributor checklist

• 🤖 I have added tests, or extended existing tests, to cover any new features or bugs fixed in this PR.
• 📖 I have considered adding a new entry in CHANGELOG.md, and added it if should be communicated there.

[anders-kiaer]

Impressive work @sigurdp! 👏🚀

This is very much worth a changelog entry (add that before merge?) 🍾 Other than that I don't have much to comment on from my point of view (there are some dev_*.py files and commented out code sections you want to keep since they are in the last commit?).

[sigurdp]

Impressive work @sigurdp! 👏🚀

This is very much worth a changelog entry (add that before merge?) 🍾 Other than that I don't have much to comment on from my point of view (there are some dev_*.py files and commented out code sections you want to keep since they are in the last commit?).

Changelog - check.

The dev_* files were intentionally left in place since they provide a valuable test harness for assessing performance and for investigating any discrepancies in the interpolation functionality. Could't quite fit this into the unit test category, and really want to have them handy for a while, but they are certainly not needed for normal operation. I suggest we leave them in there for now, at least until we get some more real-world traction with the data provider.