Skip to content

add ifs-forecast loader#12

Open
mpvginde wants to merge 16 commits into
mainfrom
feat/ifs-forecast-loader
Open

add ifs-forecast loader#12
mpvginde wants to merge 16 commits into
mainfrom
feat/ifs-forecast-loader

Conversation

@mpvginde

Copy link
Copy Markdown
Contributor

Adds

  • a loader for IFS deterministic and ensemble forecasts
  • tests for the new loader
  • optional dependency of cfgrib

@mpvginde mpvginde requested a review from leifdenby May 13, 2026 09:55
Comment thread tests/test_ifs_forecast_integration.py Outdated
@leifdenby leifdenby added this to the v0.1.0 milestone Jun 19, 2026
@mpvginde

Copy link
Copy Markdown
Contributor Author

Thanks @leifdenby! Linting is fixed and test have passed. I think we can merge this.

@leifdenby leifdenby left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good :) A few suggestions for changes

Comment thread src/mlwp_data_loaders/loaders/ifs/forecast.py
paths = [paths] if isinstance(paths, str) else paths

if chunks is None:
# open_mfdataset requires dask; open individually and concat when chunks=None

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this mean we should check if dask is installed here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or we could make dask a dependency of the package. In a way it make sense as one of the main functionalities of the relying on xarray is the dask functionality

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I'm not sure I see a situation where having dask installed would harm us. I guess we just should be quite lenient about what minimum version we require so that we don't mess things up for people.

I still don't quite understand the if-statement comment though. Currently it doesn't check for whether dask is installed. So do we expect an exception if chunks != None and dask isn't installed? Or shouldn't the xr.open_mfdataset(...) call just fail to use dask but continue anyway? I also don't quite understand why one of these calls uses cfgrib as the engine explicitly, but the second one doesn't. Are we hoping that cfgrib will be detected as the right engine and used implicitly?

Comment thread src/mlwp_data_loaders/loaders/ifs/forecast.py Outdated
Comment thread tests/test_ifs_forecast_integration.py Outdated
pytest.importorskip("cfgrib")

DET_FILES = [
"/scratch/cu0k/ifs-example/ifs_det_fcst_20260101.grib",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't these point to path in the EWC S3 now?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes you are right. Changed in f9e65e0

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since these are single files that must be downloaded what do you think about using pooch instead for fetching the files (like I did for the HARP obstables: https://github.com/mlwp-tools/mlwp-data-loaders/blob/main/tests/test_harp_obstable_integration.py)? That ensure that we get the right content (pooch uses a checksum for this) and it would easier to implementing caching of the test datasets in github CI down the line (since pooch has a single cache dir we can put in the ci action cache)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't know about pooch. Yes your solution for the obstable is much more elegant. Let's go for that one!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed in 9f82920

Comment thread pyproject.toml
@mpvginde mpvginde requested a review from leifdenby June 23, 2026 19:53
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.

2 participants