Jeff Whitaker

We don't handle the C library here - but this has been discussed for the libnetcdf conda package (see https://github.com/conda-forge/libnetcdf-feedstock/pull/166 and https://github.com/conda-forge/libnetcdf-feedstock/pull/160). Once that is available, we can build new...

probably better to use [xarray.mf_dataset](https://docs.xarray.dev/en/stable/generated/xarray.open_mfdataset.html) anyway

MFDataset really only requires the classic data model, so we could remove the check for the file format. The problem will be if NETCDF4 files are used that don't use...

I think we understood your meaning - xarray.mf_dataset has better functionality than netCDF4.MFDataset. xarray uses netCDF4 under the hood for netCDF file I/O.

If there is a workaround for this, it has to happen in the netcdf-c library. Can you file this as an issue at https://github.com/Unidata/netcdf-c?

wgrib2 is returning the data in fortran (column major) order, while pygrib is returning it in c order (row major). See https://en.wikipedia.org/wiki/Row-_and_column-major_order

You cannot write a grib file from scratch using pygrib - a template file is needed

@Marston I don't know the answer - you'll just have to try it and see what works and what doesn't. It would be great if you could report back on...

the `messages` attribute of the `open` instance is the number of messages in the file. It would be pretty straighforward to have `__len__` return this.

I don't see this on macos x or linux.