Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output file name for errors in check_netcdf2 #1979

Open
billsacks opened this issue Dec 9, 2023 · 2 comments
Open

Output file name for errors in check_netcdf2 #1979

billsacks opened this issue Dec 9, 2023 · 2 comments

Comments

@billsacks
Copy link
Member

Emerging from ESCOMP/CDEPS#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
Copy link
Contributor

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

@billsacks
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants