netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Hi Russ, > > Yes, local sequence numbers cut both ways sometimes... Since > > most (all?) current netCDF users should be used to a 'flat' file, > > putting all the objects in the root group of the file and using the > > creation order in that group seems like a reasonable default. Then, > > you could change the definition of the way the creation order > > information is used for netCDF 4 users so that the group structure > > was accounted for. > > BTW, I was looking through the netCDF 3 API for functions that > > take or return an 'index' in the file and I can't find one. Which > > function(s) applies to this situation? > > I think we haven't been clear enough in describing what we mean be > creation order. Actually, I do understand what you mean, HDF4 does things basically the same way. For the functions below, how do you get the ID/num of an object when you don't know the name? Do you pass in a NULL pointer for the name parameter? I think supporting creation order for attributes might be a bit more of a problem than for the other kinds of objects, but from reading your description of the attribute number below, it doesn't look like it's a real problem if the "creation order" of attributes changes. Is that so? Quincey > In netCDF, there is no global creation order stored > for all objects that tells whether a particular variable was created > before or after a particular global attribute, for example. The "ids" > for dimensions and variables, and the attribute numbers, record the > order in which they were defined, and that's all we need to preserve, > to make sure that we iterate over the netCDF variables in the same > order in which they were defined, for example. You're right that > there is no global index defined over all netCDF objects in a file, > but the C interface provides these functions to get the dimension ID, > variable ID, or attribute number, which gives the relative orders for > dimensions, variables, and attributes: > > Get a dimension ID from its name: > int nc_inq_dimid (int ncid, const char *name, int *dimidp) > Get a variable ID from its name: > int nc_inq_varid (int ncid, const char *name, int *varidp) > Get an attributes number from its variable id and name: > int nc_inq_attid (int ncid, int varid, const char *name, int *attnump) > > By the way, the attribute number is not called an ID intentionally. As > the Users Guide says: > > ... The number of an attribute is more volatile than the name, since > it can change when other attributes of the same variable are > deleted. This is why an attribute number is not called an attribute > ID. > > The IDs support iteration through the variables, dimensions, and > objects in a netCDF file if you don't know the names of anything, so > they are used by generic software. Users have gotten used to the fact > that ncdump, a generic netCDF program, outputs things in the order in > which they were defined, rather than alphabetical order by name, for > example. The same is true for menus and other GUI elements in > applications. Since we don't have Groups, grouping variables in a > conventional order keeps related variables close to each other in > these contexts. > > I hope this makes it clearer that what we need is not the absolute > time order of all objects in a netCDF file (that would be overkill but > would suffice), but rather just some way to determine the order > dimensions were defined relative to each other, the order variables > were defined relative to each other, and similarly for variable > attributes and global attributes. > > In the prototype, we are storing this information in separate HDF > Datasets. In an earlier version, we preserved this information by > encoding the IDs as part of the datasets name, but now we use the same > names as for the netCDF objects. > > --Russ > > >