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 pointers
for 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
