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.
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.
Hi Ed,
If the file was opened via any netCDF user open then netCDF could retain and provide that specified file/path named. That would be the intent of the user/developer and help the user. Never mind rename. Just help the user as best you can. This isn't hard.But the calling application already has the path - it had to have the path to open/create the file. The concern is not about how hard it is - we do really hard programming here every day. Yesterday Russ re-coded the Unix "ls" command from scratch, in assembly language. And to make it more of a challenge, he entered his op codes by whistling into an old-fashioned acoustic modem at 9600 baud. (This was on his lunch hour of course. It's his hobby.) The concern is increasing the complexity of the API. We would like to keep it as simple as possible.
Actually, the request is a good one. I asked for this many years ago and I was told by Unidata then that it was a good idea and probably will be available in future releases. I always look for it in new major releases, but I cannot find any new function in the library that give us this capability. I have been using NetCDF since 1990, many versions ago. I have seen the library change a lot through the years, so I don't buy your concerns about the complexity of the API. I had check deep in the debugger tracking the efficiency of the parallel interface. I know how complex the NetCDF API is. I can give you numerous scenarios where having the ncid and file/path is extremely useful for us who develop I/O APIs on top of the NetCDF library. * Generalized serial and parallel (MPI, OpenMP) I/O API's. There are many ways to do parallelism and sometimes one file is associated with each parallel partition. * Searching for a variable or record in countless NetCDF files. We don't want to store unnecessary information about all those files. * Issuing meaningful error messages that indicate on which file a generic API routine failed. * And so on ... The are many ways to overcome this issue, but all are cumbersome. We can store the ncid and associated file/path in a structure and pass it as argument instead. The problem here is that we have pointersfor ncid and file/path and is not the same as NetCDF API. Also in some languages we need the dimension of array structures before it is allocated (say Fortran). Sometimes we don't know how many files we are going to create or open. We can pass the ncid and the file/path as arguments in each function of the API. Then, the API needs to have different arguments than the original NetCDF API. It is painful...
Writing APIs on top of NetCDF give us a lot of functionality. The library is too verbose and it is nice to hide all that from more complex coding. It is easy to debug and update. I really hope that Unidata reconsider and change their mind about this one. Keep the good work! Thank you, Hernan ----------------------------------------------------------------------- Hernan G. Arango Institute of Marine and Coastal Sciences arango@xxxxxxxxxxxxxxxxxx Rutgers University off: (732) 932-6555 x266 71 Dudley Road FAX: (732) 932-6520 New Brunswick, NJ 08901-8521, USA http://marine.rutgers.edu/po/arango http://marine.rutgers.edu/po/arango/rocco http://marine.rutgers.edu/roms http://www.myroms.org http://www.ocean-modeling.org
netcdfgroup archives: