NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Quincey, > 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. 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
netcdf-hdf archives: