Hi Pedro,
> I have a couple questions regarding the definition of dimensions in
> groups;
>
> Consider the following CDL definition
>
> netcdf in_grp {
> dimensions:
> lon=3D3;
> variables:
> //coordinate variable
> float lon(lon);
> data:
> lon=3D1,2,3;
> group: g1 {=20
> dimensions:
> lon=3D2;
> variables:
> float lon(lon);
> float data(lon)
> data:
> lon=3D1,2;=20
> } // end g1
> } // end
>
> There is a "lon" dimension/coordinate variable both at root and in group
> /g1 and they have different dimensions, so variable named "data" has 2
> dimensions with the same name in scope,
> and somehow has to choose one
>
> Just wanted to confirm
>
> 1) Is this definition legal?
Yes, except that the line
float data(lon)
needs to be terminated with a ';'.
> 2) What is the algorithm that the netCDF library uses to distinguish
> between both dimensions in scope for the variable /g1/data?
The innermost dimension is used, so
lon=2;
is the dimension of the 'data' variable.
> 3) Defining "lon" as a coordinate variable instead of just a dimension
> name, does this definition has any consequence for the way this is
> handled by the library for this case?
No, I don't think so. NetCDF shared dimensions and inherited dimensions
aren't directly representable in the HDF5 data model, so there are a few
artifacts created in the HDF5 representation to make things mostly work
by using HDF5 dimension scales and some hidden attributes. More details
are in John Caron's blog:
http://www.unidata.ucar.edu/blogs/developer/en/entry/dimensions_scales
> Can someone from Unidata please point me to the location in the source
> code where this is handled?
The ncgen utility parses the CDL and selects the innermost dimension for
each variable. You can use the ncgen and ncdump utilities
ncgen -b in_grp.cdl; ncdump in_grp.nc
to verify that data has two values
data = _, _ ;
which in this case are _FillValue for floats, denoted as '_'.
The source code for ncgen is mostly in the yacc (or bison) grammar
ncgen/ncgen.y.
--Russ
