netCDF Utilities

Steve Emmerson <steve@xxxxxxxxxxxxxxxx> writes as follows in
>Message-Id: <199204291912.AA12751@xxxxxxxxxxxxxxxx>
dated Thu Apr 30 05:37:43 1992
>
>Both ncdelete(1) and nccopy(1) can be implemented in terms of
>ncextract(1), which is about to be released.
>
>>In my previous posting I proposed a syntax for specifying an 'array' defined
>>by netcdf filename, variable name & a vector of subscripts for each dimension.
>
>This is nice and elegant solution.  Unfortunately, it has the drawback
>of requiring that a layer be created which is capable of interpreting
>such netCDF specifications in the manner you suggest.  This would mean
>that no netCDF operators could be released until the interpreter was
>fully completed (or as near enough as makes no difference).  This is in
>contrast to the current proposal of implementing stand-alone netCDF
>programs and releasing them as they are completed.
>
>Personally, I'd be more than happy to work on such a netCDF
>specification interpreter (I've thought about one for some time).  I
>think it makes sense, especially as the first step towards a potential
>`netCDF data-server' and as an interface for converting between how
>data exists in a netCDF object and what an individual program wants to
>see.  I think, however, that it will take some hewing and crying from
>the netCDF user-community to convince the powers that be that they
>should set these wheels in motion.  Note that the preceding is just my
>opinion and not necessarily the UPC's (which I don't think has an
>opinion on this).

I have now implemented most of my 'array' syntax. It really was pretty easy.
I considered using lex and/or yacc, but ended up just doing it in c.

My procedure parse_nc_array does the required parsing & is complete.
However I have not yet written code to fully use the output from
parse_nc_array.

Some examples of array specifications parsed by parse_nc_array are:

"ocean.cdf;vec[6:7,2]"
This refers to elements 6 to 7 & 2 of variable 'vec'. Note that origin 1
is used so that c subscripts are 5, 6, 1. No coordinate variable name is
specified so the 1st is implied (i.e. the one corresponding to position in
specification)

"ocean.cdf;sst[year=6;latitude=1:56;longitude=~-90 degrees_east:]"
Here coordinate variable 'year' has c index 5, coordinate variable
'latitude' has c index from 0 to 55, coordinate variable 'longitude' starts
at nearest value to -90 degrees_east & goes to end.

"ocean.cdf; sst[ year=6,7,9; latitude=+1:+3; longitude=:3:2,9: ]"
Here coordinate variable 'year' has c index 5,6,8, coordinate variable
'latitude' has c index from 1 beyond current size of unlimited dimension to 
3 beyond current size of unlimited dimension, coordinate variable 'longitude'
has c index 0, 2 then 8 to end.

You can access code by anonymous ftp to atmos.dar.csiro.au
followed by "cd netcdf/hld". Procedure parse_nc_array is in file nc.h
& is called by program in file nc_put_var.c
followed by "cd netcdf/hld"

My main point is that it really is quite easy to implement this sort of 
syntax. If we can agree on some syntax, I would consider adapting my code, so
you can use it.

Would you please give further details about ncextract & other utiilites you are
planning?

Harvey Davies,
CSIRO Division of Atmospheric Research,    Voice: +61 3 586 7574
Private Bag No. 1, Mordialloc,               Fax: +61 3 586 7600
Victoria 3195,  Australia               Internet: hld@xxxxxxxxxxxx



  • 1992 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: