This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>To: <address@hidden> >From: "Hernan G. Arango" <address@hidden> >Subject: Getting ID of an open NetCDF file by its file name >Organization: UCAR/Unidata >Keywords: 200305141830.h4EIUKLd024546 Hi Hernan, > Is there an easy and elegant way of getting the ID of an opened NetCDF > by specifying its file name? I am trying to avoid opening too many > files simultaneously for the same dataset. I am also trying to avoid > opening and closing the NetCDF every time that it is needed. I am using > this in the context of an ocean model which requires reading input > NetCDF dataset frequently. No, unfortunately there is nowhere in the netCDF library where the association between pathnames and file descriptors (ncids) is stored for all open files. For each open file there is an "ncio" structure that has both the file descriptor and a pointer to the pathname, but those structs reside in allocated space on the heap, not in an array or list where they could easily be searched. So I'm afraid the easiest way for you to do this is to store a table of ncids and associated pathnames when they are returned from nc_open or nc_create (or the corresponding F90 interfaces). One way to do this would be to write a wrapper for the open, create, and close calls which calls the appropriate netCDF function and passes back the return values but also populates a (pathname,ncid) table so you could access this with another function. The "close" call would call the netCDF close function but also delete the associated (pathname,ncid) association from the table. This seems like a useful functionality, and something we should add in the next version of netCDF. Keeping a data structure with file descriptors and pathnames would be relatively cheap, but useful in cases like this. I'll put it on the list. --Russ