# netCDF compatibility trouble with HDF4.2r4 + possible fix **URL:** \ **Category:** Hdf-forum archives\ **Created:** [September 2, 2009, 5:21pm UTC](https://forum.hdfgroup.org/t/netcdf-compatibility-trouble-with-hdf4-2r4-possible-fix/1419 "2009-09-02T17:21:33Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Stuart\_Levy](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/s/c37758/32.png) [@Stuart\_Levy](https://forum.hdfgroup.org/u/Stuart_Levy)\ **Post date:** [September 2, 2009, 5:21pm UTC](https://forum.hdfgroup.org/t/netcdf-compatibility-trouble-with-hdf4-2r4-possible-fix/1419/1 "2009-09-02T17:21:33Z")
I have an application, linked with the HDF4 libraries, which sometimes is fed HDF and sometimes netCDF files. After building it recently with HDF4.2r4 (we had been using e.g. 4.2r0 before), it misbehaved when fed a netCDF file with a 3-D geographic grid and lat/lon/altitude scale variables. The app calls SDdiminfo() for each dimension, and was being given a non-useful response (datatype nt = NC\_UNSPECIFIED (0)) even though the corresponding dimension existed and had an associated set of double-precision (NC\_DOUBLE) scale values. The problem seems to be in mfhdf/libsrc/mfsd.c, in code like (in SDIgetcoordvar and elsewhere): 3208 if((\*dp)-\>assoc-\>count == 1) 3209 if( len == (\*dp)-\>name-\>len 3210 && HDstrncmp(name-\>values, (\*dp)-\>name-\>values, (size\_t)len) == 0) 3211 /\* only proceed if this variable is a coordinate var or when 3212 the status is unknown due to its being created prior to 3213 the fix of bugzilla 624 - BMR 05/14/2007 \*/ 3214 if ((\*dp)-\>var\_type == IS\_CRDVAR || (\*dp)-\>var\_type == UNKNOWN) 3215 { ... But the useful LAT/LON/altitude coordinate vars, from this netCDF file, had been tagged as var\_type == IS\_SDSVAR at this point, so the above test skipped them, and no coordinate var was detected. I don't understand exactly what this new IS\_CRDVAR / UNKNOWN test is supposed to do, but am guessing that it is needed for HDF files, but isn't for netCDF files. Sound right? It might be best to fix this at the point where the netcdf reader is looking through the variables, and choosing the proper var\_type there, but I wasn't sure how. Instead, I added a convenience function to mfsd.c to do what seems like the right test, based on the file type. The resulting library does allow my application to read these netCDF files, just as it could do with HDF4.2r0, so I'm submitting this patch (attached) as a possible fix.     Stuart Levy in sunny(!) Champaign, IL     slevy@ncsa.uiuc.edu [mfsd.patch](https://hdf-discourse-1.s3.amazonaws.com/original/1X/34cbb1879feafb7a9a65b67735e2e41989c43ddb.patch) (2.7 KB) ---
**Author:** ![epourmal](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/e/c67d28/32.png) [@epourmal](https://forum.hdfgroup.org/u/epourmal)\ **Post date:** [September 2, 2009, 8:43pm UTC](https://forum.hdfgroup.org/t/netcdf-compatibility-trouble-with-hdf4-2r4-possible-fix/1419/2 "2009-09-02T20:43:00Z")
Stuart, We will take a look. Could you please send me the NetCDF file? Thank you! Elena > **···** > > On Sep 2, 2009, at 12:21 PM, Stuart Levy wrote: > > > I have an application, linked with the HDF4 libraries, which sometimes is > > fed HDF and sometimes netCDF files. > > > > After building it recently with HDF4.2r4 (we had been using e.g. 4.2r0 before), > > it misbehaved when fed a netCDF file with a 3-D geographic grid and > > lat/lon/altitude scale variables. The app calls SDdiminfo() for each dimension, > > and was being given a non-useful response (datatype nt = NC\_UNSPECIFIED (0)) > > even though the corresponding dimension existed and had an associated > > set of double-precision (NC\_DOUBLE) scale values. > > > > The problem seems to be in mfhdf/libsrc/mfsd.c, in code like > > (in SDIgetcoordvar and elsewhere): > > > > 3208 if((\*dp)-\>assoc-\>count == 1) > > 3209 if( len == (\*dp)-\>name-\>len > > 3210 && HDstrncmp(name-\>values, (\*dp)-\>name-\>values, (size\_t)len) == 0) > > 3211 /\* only proceed if this variable is a coordinate var or when > > 3212 the status is unknown due to its being created prior to > > 3213 the fix of bugzilla 624 - BMR 05/14/2007 \*/ > > 3214 if ((\*dp)-\>var\_type == IS\_CRDVAR || (\*dp)-\>var\_type == UNKNOWN) > > 3215 { > > ... > > > > But the useful LAT/LON/altitude coordinate vars, from this netCDF file, > > had been tagged as var\_type == IS\_SDSVAR at this point, > > so the above test skipped them, and no coordinate var was detected. > > > > I don't understand exactly what this new IS\_CRDVAR / UNKNOWN test is > > supposed to do, but am guessing that it is needed for HDF files, > > but isn't for netCDF files. Sound right? > > > > It might be best to fix this at the point where the netcdf reader > > is looking through the variables, and choosing the proper var\_type there, > > but I wasn't sure how. Instead, I added a convenience function to mfsd.c > > to do what seems like the right test, based on the file type. > > > > The resulting library does allow my application to read these netCDF files, > > just as it could do with HDF4.2r0, so I'm submitting this patch (attached) > > as a possible fix. > > > >    Stuart Levy in sunny(!) Champaign, IL > >    slevy@ncsa.uiuc.edu > > \\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > Hdf-forum is for HDF software users discussion. > > Hdf-forum@hdfgroup.org > > [http://mail.hdfgroup.org/mailman/listinfo/hdf-forum\_hdfgroup.org](http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org) ---
**Author:** ![Stuart\_Levy](https://forum.hdfgroup.org/letter_avatar_proxy/v4/letter/s/c37758/32.png) [@Stuart\_Levy](https://forum.hdfgroup.org/u/Stuart_Levy)\ **Post date:** [September 2, 2009, 9:07pm UTC](https://forum.hdfgroup.org/t/netcdf-compatibility-trouble-with-hdf4-2r4-possible-fix/1419/3 "2009-09-02T21:07:09Z")
> Stuart, > > We will take a look. Could you please send me the NetCDF file? Thanks! Yes, you can find one at:     [http://virdir.ncsa.illinois.edu/stuffed/slevy/hdf/slice.0000.nc](http://virdir.ncsa.illinois.edu/stuffed/slevy/hdf/slice.0000.nc) > **···** > > On Wed, Sep 02, 2009 at 03:43:00PM -0500, Elena Pourmal wrote: > > > Thank you! > > > > Elena > > On Sep 2, 2009, at 12:21 PM, Stuart Levy wrote: > > > > > I have an application, linked with the HDF4 libraries, which sometimes is > > > fed HDF and sometimes netCDF files. > > > > > > After building it recently with HDF4.2r4 (we had been using e.g. 4.2r0 > > > before), > > > it misbehaved when fed a netCDF file with a 3-D geographic grid and > > > lat/lon/altitude scale variables. The app calls SDdiminfo() for each > > > dimension, > > > and was being given a non-useful response (datatype nt = NC\_UNSPECIFIED > > > (0)) > > > even though the corresponding dimension existed and had an associated > > > set of double-precision (NC\_DOUBLE) scale values. > > > > > > The problem seems to be in mfhdf/libsrc/mfsd.c, in code like > > > (in SDIgetcoordvar and elsewhere): > > > > > > 3208 if((\*dp)-\>assoc-\>count == 1) > > > 3209 if( len == (\*dp)-\>name-\>len > > > 3210 && HDstrncmp(name-\>values, (\*dp)-\>name-\>values, > > > (size\_t)len) == 0) > > > 3211 /\* only proceed if this variable is a coordinate var > > > or when > > > 3212 the status is unknown due to its being created > > > prior to > > > 3213 the fix of bugzilla 624 - BMR 05/14/2007 \*/ > > > 3214 if ((\*dp)-\>var\_type == IS\_CRDVAR || (\*dp)-\>var\_type > > > == UNKNOWN) > > > 3215 { > > > ... > > > > > > But the useful LAT/LON/altitude coordinate vars, from this netCDF file, > > > had been tagged as var\_type == IS\_SDSVAR at this point, > > > so the above test skipped them, and no coordinate var was detected. > > > > > > I don't understand exactly what this new IS\_CRDVAR / UNKNOWN test is > > > supposed to do, but am guessing that it is needed for HDF files, > > > but isn't for netCDF files. Sound right? > > > > > > It might be best to fix this at the point where the netcdf reader > > > is looking through the variables, and choosing the proper var\_type there, > > > but I wasn't sure how. Instead, I added a convenience function to mfsd.c > > > to do what seems like the right test, based on the file type. > > > > > > The resulting library does allow my application to read these netCDF > > > files, > > > just as it could do with HDF4.2r0, so I'm submitting this patch (attached) > > > as a possible fix. > > > > > >    Stuart Levy in sunny(!) Champaign, IL > > >    slevy@ncsa.uiuc.edu > > > \\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > Hdf-forum is for HDF software users discussion. > > > Hdf-forum@hdfgroup.org > > > [http://mail.hdfgroup.org/mailman/listinfo/hdf-forum\_hdfgroup.org](http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > Hdf-forum is for HDF software users discussion. > > Hdf-forum@hdfgroup.org > > [http://mail.hdfgroup.org/mailman/listinfo/hdf-forum\_hdfgroup.org](http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org)