@mikebelanger: Oh, I thought you were sure grib2 was based on HDF5, since you asked about it in reference to the nimhdf5 repo.
If it's a completely different file type then of course loading those files with the library does not work. In that case either wrap a specific library for grib2 files: it seems there's g2clib by the NECP: [https://www.nco.ncep.noaa.gov/pmb/codes/GRIB2](https://www.nco.ncep.noaa.gov/pmb/codes/GRIB2)/ and the readme: [https://www.nco.ncep.noaa.gov/pmb/docs/grib2/download/g2clib.readme](https://www.nco.ncep.noaa.gov/pmb/docs/grib2/download/g2clib.readme) You'd have to look at the library and see how complex it is. If you only require a limited subset of the functionality, maybe there are a few functions, which are enough to wrap. A nice interface will be a lot of work of course. Or continue the work you quoted above wrapping GDAL. In either case I can try to help (although I don't know how much help I'd be :) ). If you don't mind me asking, for what do you have to read grib2 files? @mratsim: Yes, we talked about this before. The basic reading and writing of HDF5 files is already implemented in arraymancer, as you know of course. Writing higher level procs to provide "store to HDF5" and "load from HDF5" for a complex network layout is fine. I looked into Keras loading back when I implemented HDF5 io if you remember. The reason I stopped for the time being was two fold: 1. understanding the Keras used HDF5 layout was a little hard. Looking at a bunch of different models it looked a little arbitrary. I didn't understand if it was a Keras version thing (old models etc.) or if the rules to store models were just quite complicated. This would just be a matter of looking at the Keras documentation and code in detail to figure it out. I hope there's some spec around, which describes how the models are stored. 2. the above would be ok, but mapping the Keras models to Arraymancer models was problematic. Regarding 2: The main reason just being that a runtime based model creation in Arraymancer wasn't really possible. Since the network DSL creates most of the code at compile time I had a clash with the fact that I can only read the HDF5 Keras files, which describe the layout, at run time. Not sure if it's even possible to generate performant code at run time only or if there's some optimization happening in the network DSL (if not writing a run time interface should be fine?). On the other hand of course one could require that the user writes out the network DSL code that describes the model stored in a Keras HDF5 file and provide the resulting context (or type, ...) to the Keras loading procedure. Then we can raise an exception if the model of the file does not match at run time. In any case, whenever you want to tackle this (or I finally get far enough with my work to need NNs again _sigh_ ) we can discuss it and I can (at least) do the IO related implementation.
