Fantastic work, how do I contribute?

[aidanheerdegen]

Thanks for making this. I hate the verbosity of the netcdf interface, so had always meant to write something like this. It is a welcome relief that someone else has beaten me to it.

I'm interested in creating an object-oriented interface, with a user defined netcdf type that can be automatically populated and queried.

Is the best approach to make a separate module (say ncio_oo) that uses the module as-is?

[alex-robinson]

Hi Aidan,

Thanks, I'm glad you find it useful. An oo-approach would be neat, I thought about it myself. I would indeed perhaps try to make an oo interface module separately that uses ncio. Later you may find it useful to replace the ncio calls with something else without affecting your interface. I would be glad to hear about your progress. Perhaps you can fork ncio and go from there?

Cheers, Alex

On Mon, Nov 23, 2015 at 8:11 AM, Aidan Heerdegen <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Thanks for making this. I hate the verbosity of the netcdf interface, so had always meant to write something like this. It is a welcome relief that someone else has beaten me to it.

I'm interested in creating an object-oriented interface, with a user defined netcdf type that can be automatically populated and queried.

Is the best approach to make a separate module (say ncio_oo) that uses the module as-is?

— Reply to this email directly or view it on GitHub https://github.com/alex-robinson/ncio/issues/4.

[aidanheerdegen]

Ok, sounds like a plan.

Thanks again for writing the code and making it publicly available.

[perrette]

That sounds good @aidanheerdegen ! Just out of curiosity, do you have any idea of where do you want to go? Thinking of the current interface, my guess is that an OO approach would not necessarily makes it simpler or less verbose than ncio (right now there is only one line to write a variable !), but probably give more flexibility and performance close to original library... This assumes it is built from scratch of course... My concern is that an OO approach as a wrapper to current ncio would be more verbose AND less efficient (necessarily, as wrapper, but hopefully minimally) than ncio

I only have experience in using python's netCDF4 package. It is very handy but lower level than current ncio.

ds = Dataset('filename.nc')
x = ds.createDimension('x', len)
x = ds.createVariable('x', float, 'x') # variable for the like-named dimension, a common case assumed standard in ncio
x[:] = my_x_data  
y = ds.createVariable('y', float, 'x')
y[:] = my_y_data
y.units = 'my units'
ds.close()

It is really nice to use, though more complex that just:

nc_create('filename.nc')
nc_write_dim('filename.nc', 'x', x=my_x_data)
nc_write_var('filename.nc', 'y', x=my_y_data, units='my units')

A fortran OO interface would probably be even more verbose than python... Do you have an idea of the kind of interface / functionality you would like to offer?

Further inspiration here:

• json-fortran
• fson

[perrette]

I guess a clean OO approach would involve building the Unidata data model as a fortran type, similarly to what xray or dimarray - but without the in-memory operations etc..., just the attributes and the "write" or "dump" statement once everything is defined in memory...

Anyway, ncio's ncvar internal is a step in that direction.... And using a wrapper around ncio sounds a good start, too. As far as performance is concerned, the main thing I was thinking about is to keep track of all these IDs when files and variables are created. Alex did some tests with file creation, and closing/opening a file repeatedly does provoke some slowdown. Note sure about the other IDs...

A few late-night thoughts, take them as a brainstorming more than a carefully-thought advice.

Looking forward to seeing what you come up with!

[aidanheerdegen]

Hey Mahé, thanks for the ideas.

Yes, the idea was to create a netcdf user defined type.

Having used the ncio library for a few days I have to say that you're right, it hits the right notes for simplicity, which the python netCDF4 library does not. Way too much boilerplate.

Yes I was thinking more like xray, which is nicely written, but maybe tries to be a bit too clever?

My thinking was that an encapsulated approach suits netcdf, that it is a "nice fit".

Advantages to OO:

• easy to clone/copy data. Just copy the object and write it to a new file.
• easy to compare data by comparing objects.
• potentially also have a nc_variable type, to further abstract data access. Removes need to pre-allocate data arrays, return a nc_variable type containing the data within.

Those are a few of the major advantages I can see. But as I say, the ncio library is very nice and easy to use, and is already enhancing my productivity, which is the main reason for writing libraries like these.