ExodusII IO has variable ID bug which can prevent coordinates from being read-in from a file
EdwardPalmer99 opened this issue · 4 comments
Brief
- Version 5.22b of the exodusii library contains a bug in the ex_get_coord function. Note that this issue is not present in version v8.11.
What is the problem?
- NetCDF variable IDs are numbered starting from 0 in C (from 1 in Fortran) https://docs.unidata.ucar.edu/netcdf-c/current/tutorial_ncids.html
- Version 5.22b contains a bug in the file ex_get_coord.c on line 238 where if the variable ID of a coordinate is 0 (which is a valid variable ID!) then the coordinate data will not be read from the file. This will result in one of the coordinates being an array of zeros. This was a problem that I encountered when reading in certain ExodusII files.
- This bug has been addressed in more recent versions of the ExodusII library by comparing against a value of (-1) which is not a valid variable ID. I recommend updating the exodusii reader or changing this line in the source code.
Links
-
Link to problematic file (v5.22b): https://github.com/libMesh/libmesh/blob/7dbd90ade88cb16a5e855a4c345454c9c146ebec/contrib/exodusii/5.22b/exodus/cbind/src/ex_get_coord.c
-
Link to updated file in seacas repository with fix: https://github.com/sandialabs/seacas/blob/master/packages/seacas/libraries/exodus/src/ex_get_coord.c
Code
if (coor != NULL && coordid != 0)
Hi @EdwardPalmer99,
Thanks for the info. For quite a while now, I believe we default to using Exodus v8.11 in libMesh, so hopefully this bug does not affect many of our users. I'm curious, if you are actually using libmesh and still getting Exodus 5.22b, what version of libmesh are you using and how is it configured?
We could try and patch the 5.22 sources that we bundle with libmesh, but at this point it might be more productive to actually remove them from master and make sure that everyone is using v8.11.
Hi, the libmesh commit hash is 7dbd90a (2nd April 2024). This is the version currently in use by the master branch of Moose. Libmesh was built without the optional HDF5 library which may be why the older 5.22 Exodus version was used.
We default to v8.11 when we have HDF5 available, but I think it's important to keep v5.22 around for users without HDF5.
The diff is much larger, but it looks like a fix would be a half dozen lines of it. I wouldn't want to futz around forking old Exodus without better test coverage of the issue too, though. Can you come up with a short Exodus file that triggers the bug?
Yes, this is a simple ExodusII file. It can be read-in successfully using Coreform Cubit. Please note that I have changed the extension to 'txt' in order to upload it to Github.