NCAR / ParallelIO

A high-level Parallel I/O Library for structured grid applications
Apache License 2.0
134 stars 52 forks source link

Output file name for errors in check_netcdf2 #1979

Open billsacks opened 8 months ago

billsacks commented 8 months ago

Emerging from https://github.com/ESCOMP/CDEPS/issues/254 - we'd like for PIO to print the filename that leads to netcdf errors that are caught in the check_netcdf2 function. I'm happy to take this on (but I don't have permission to assign myself).

From a quick look through the code, it looks like most / all of the functions that call check_netcdf2 directly have a filename that they could pass in as an extra argument. Then I'm thinking that we'd modify the error message returned from netcdf to append the file name to the output message.

I'm not sure the best way to handle the call from check_netcdf to check_netcdf2. Options I see are:

  1. Don't handle calls to check_netcdf for now. (It looks like the above CDEPS issue would be handled via one of the direct calls to check_netcdf2.)
  2. Extend check_netcdf to also accept a filename argument. However, there are a lot of calls to check_netcdf, so this would be a pretty invasive change.
  3. check_netcdf has a file_desc_t object. (So does check_netcdf2, but the direct calls to check_netcdf2 appear to pass NULL in for that argument.) Currently file_desc_t doesn't contain the filename but I wonder if it makes sense to extend file_desc_t to store the associated filename. Then calls to check_netcdf2 via check_netcdf could get the file name from that file_desc_t object.

I like the idea of (3), but I haven't looked into what it would involve. @jedwards4b do you have thoughts on whether this would be a reasonable solution?

jedwards4b commented 8 months ago

It seems like we can do option 1 now and then reevaluate whether we need to extend to 2 or 3.

billsacks commented 8 months ago

Sounds good. I'm happy to do this. It's on my list for after I finish some ESMF work that may still take me another week or so.