NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.

To learn about what's going on, see About the Archive Site.

Re: [netcdfgroup] defining dimensions in groups

Russ, Dennis

I'll take a look at those pointers, thanks


John Caron's blog:
this is a very good article about Dimension Scales, I remember those issues coming up when I was writing the DS code 

http://www.unidata.ucar.edu/blogs/developer/en/entry/dimensions_scales
The rule is implemented in the ncgen parsing code. I can tell you specifically 
where if you really want to know.
yes, please, we can keep the discussion off mailing list maybe @ pedro.vicente@xxxxxxxxxxxxxxxxxx
I am interested in developing a structure and function that deals with keeping track of all the available dimensions for a particular variable. 

The netCDF API has this function

nc_inq_dimids
Find all dimids for a location. This finds all dimensions in a group, or any of its parents. 
Usage
int nc_inq_dimids(int ncid, int *ndims, int *dimids, int include_parents); 

http://www.unidata.ucar.edu/software/netcdf/docs/netcdf-c/nc_005finq_005fdimids.html#nc_005finq_005fdimids

but it returns IDs, but we can have duplicated IDs in the returned array;

in my example

/lon
and
/g1/lon
could have the same ID (probably both will have the ID =0 , since both are the first and only dimensions for that group) 

so, I need a structure that uniquely identifies the "right" dimension;
I think I simple track of the full path of the dimension as a string would do 

the function would return an array of strings instead

"/lon", and "/g1/lon"

I did this recently for a function

use case is

/g5/g5g1/rz = variable
with
/g5/rlev = dimension

so

rz(rlev) in the CDL definition

and I need to extract only the variable
/g5/g5g1/rz

but the dimension is one level below at

/g5/rlev
so, one way to do it was to try to build all possible possible valid dimension paths 

starting at the variable location

/g5/g5g1/rlev = does not exist
/g5/rlev = ok
/rlev = does not exist
and then comparing with a full list of all paths in the file to see if the build dimension path exists 


/* Brute-force approach to find valid "dmn_nm_fll":
 Start at grp_nm_fll/var_nm and build all possible paths with var_nm.
 Use case is /g5/g5g1/rz variable with /g5/rlev coordinate var. Phew. */

     /* Find last occurence of '/' */
     pch=strrchr((char*)dmn_nm_fll,'/');
     psn=pch-dmn_nm_fll;
     while(pch!=NULL){
       /* If variable is on list, mark it for extraction */
       if(trv_tbl_fnd_var_nm_fll(dmn_nm_fll,trv_tbl)){
if(dbg_lvl_get() >= nco_dbg_dev) (void)fprintf(stdout,"%s: INFO Found Coordinate variable %s\n",prg_nm_get(),dmn_nm_fll); 
         (void)trv_tbl_mrk_xtr(dmn_nm_fll,trv_tbl);
       } /* endif */
       dmn_nm_fll[psn]='\0';
       pch=strrchr((char*)dmn_nm_fll,'/');
       if(pch){
         psn=pch-dmn_nm_fll;
         dmn_nm_fll[psn]='\0';
         /* Re-add variable name to shortened path */
         if(strcmp(grp_nm_fll,"/")) strcat(dmn_nm_fll,"/");
         strcat(dmn_nm_fll,dmn_nm);
         pch=strrchr((char*)dmn_nm_fll,'/');
         psn=pch-dmn_nm_fll;
       } /* !pch */
     } /* end while */



thanks

Pedro
----- Original Message ----- From: "Dennis Heimbigner" <dmh@xxxxxxxxxxxxxxxx> 
To: "Pedro Vicente" <pedro.vicente@xxxxxxxxxxxxxxxxxx>
Cc: <netcdfgroup@xxxxxxxxxxxxxxxx>
Sent: Friday, January 18, 2013 1:59 PM
Subject: Re: [netcdfgroup] defining dimensions in groups



1. The inner dimension is used. The rule is to look up the group tree
   from innermost to root and choose the first one that is found
   with a matchng name.
2. The fact that it is a dimension for a coordinate variable is not relevant for the 
   choice.
However, note that this rule is only used by ncgen when disambiguating a reference 
in the CDL.  The issue does not come up in the netcdf API because
you have to specifically supply the dimension id when defining the dimension 
for a variable.
The rule is implemented in the ncgen parsing code. I can tell you specifically 
where if you really want to know.

=Dennis Heimbigner
 Unidata


Pedro Vicente wrote:

Hello everyone
I have a couple questions regarding the definition of dimensions in groups; 

Consider the following CDL definition

netcdf in_grp {
dimensions:
 lon=3;
variables:
 //coordinate variable
 float lon(lon);
data:
 lon=1,2,3;
group: g1 { dimensions:
 lon=2;
 variables:
 float lon(lon);
 float data(lon)
 data:
 lon=1,2; } // 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?
2) What is the algorithm that the netCDF library uses to distinguish between both dimensions in scope for the variable /g1/data? 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?
Can someone from Unidata please point me to the location in the source code where this is handled? 
   thanks Pedro

----------------------
Pedro Vicente
http://www.space-research.org/





------------------------------------------------------------------------

_______________________________________________
netcdfgroup mailing list
netcdfgroup@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
  • 2013 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: