netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Hi Ed, > > > Quincey Koziol <koziol@xxxxxxxxxxxxx> writes: > > > > > > > Hi all, > > > > I've posted a short document describing the changes I think are > > > > necessary > > > > to accomodate supporting netCDF-3 datatype conversions here: > > > > http://hdf.ncsa.uiuc.edu/HDF5/planning/DP/Overflow.html > > > > > > > > Please comment and send suggestions to me. If there's enough > > > > interest, we > > > > can have a separate meeting to discuss the changes. > > > > > > > > Quincey > > > > > > Let me ask a question... > > > > > > I would first define a dataset and set it's fill value. > > Yes. > > > > > Then I would pass a pointer to my version of the conversion function? > > > What would it do? Just copy the fill_buf to dst_buf? > > You would then need to create a dataset transfer property list and set > > the conversion function to your callback routine. > > OK, that's cool. > > > > > > Then I would try to transfer data. > > Yes, using the dataset tranfer property list with your callback routine > > set > > as the conversion function. Then, during the transfer of the data, if any > > exceptions occur, your callback routine would be invoked and could handle > > substituting the fill value for the destination value as desired. > > OK, let me think about this tonight after my kids go to bed and I'll > see if I understand what is going on. > > > > > Would I know that the callback function has been called? > > It's an "event driven" architecture, so you wouldn't necessarily know it > > had been invoked, unless you put in code to track that. > > I need to give a range error when the fill value substitution takes > place. > > For example, if someone calls nc_put_var_float(), with a bunch of > doubles, and a fill value has to be used because some are out of > range, then nc_put_var_float needs to return NC_ERANGE instead of > NC_NOERR. > > So I have to be able to detect that one or more fill value > substitutions has taken place. I could set some kind of global > variable, but that's a bit cheesy, I'm sure you agree. > > It would be very handy indeed if I could somehow get back some > information about whether any overflows occured... Ah! You could use the "user data" field to pass in a pointer to whatever you'd like. Then, you can use that to track any overflows that occur, etc. Will that work? Quincey