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/
