> Hi Russ, > Thanks for the replies. The problem appears to be that the enumeration > type has been > defined with values 1,2,3,4 but no value was actually written to the > variable. > By default (I hadn't used a fill value) a zero appears to have been > assigned to the variable. > This is obviously out of range as it neither of the values 1,2,3 or 4. > I had assumed that enumeration types could handle "undefined" but it > appears that they cannot. Right, there are currently no default fill values for user-defined types. In most places where the current documentation mentions "default fill values", it should be corrected to "default fill values for primitive types". For a future update, we may try to define default fill values for the infinite number of user-defined types by using member-wise or base-type-wise defaults, but that's not currently implemented and may have issues we haven't considered. > So to get around this problem I have now extended the > enumeration types > with an additional value, "0", and label it "undefined". > Is this what you expect the user to do? If so can I suggest that you > make it explicit in the manual? Yes, that's a good suggestion. > Finally, I think that getting this value wrong shouldn't make ncdump > crash. It makes it very difficult > to work out what is inside the netCDF file. I agree. Ncdump didn't crash in my test, it just reported an "invalid argument", so that may already be fixed in the current snapshot, but we'll add a test for it anyway. I'll write up a Jira issue for this later this week. --Russ > On 01/18/2013 07:35 PM, Unidata netCDF Support wrote: > > I wrote: > >> It looks like ncdump is reporting that the value it's reading is not a > >> valid > >> value for the enum type. Specifically, the enum type is defined for values > >> 1, 2, 3, and 4 using a byte base type, but the actual value read from the > >> netCDF file > >> is 0. So ncdump tries to find 0 in the table of symbols for the enum, > >> doesn't find > >> it, and reports that with the error return corresponding to "Invalid > >> argument", as > >> there isn't a netCDF error code for invalid enum value. > >> > >> NC_ERANGE might have been a more appropriate error code to return, but > >> that ship > >> has sailed, because changing the error code might break backward > >> compatibility. > >> > >> There may be an error involved in how a 0 was written to the file for a > >> value of > >> that enum type. If you have a small example that defines data of that > >> type and > >> writes a zero value instead of a valid enum value without returning an > >> error, > >> that would be a bug we could fix. > > Thinking about it a little more, it might be more helpful if ncdump printed > > the invalid > > value as an integer rather than an enumeration symbol before stopping with > > an "Invalid > > argument" error. That would be a clearer indication of the error. I'll > > see if that's > > as easy to fix as I think it should be, and check it in to the next release. > > > > --Russ > > > > Russ Rew UCAR Unidata Program > > address@hidden http://www.unidata.ucar.edu > > > > > > > > Ticket Details > > =================== > > Ticket ID: QRL-229735 > > Department: Support netCDF > > Priority: Normal > > Status: Closed > > > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: QRL-229735 Department: Support netCDF Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.