This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Edwin, > From: "Edwin R Wolfe Jr." <address@hidden> > Subject: Numeric conversion not representable? > Organization: University of Michigan > Keywords: 200101302121.f0ULLNX24572 netCDF The above message contained the following: > I'm new to using netCDF, but I think I've run into a bug. My program > issues the message <Numeric conversion not representable> and exits on > a call to nf_put_vara_int(). From what I was able to search in > the support archives, I don't think that should happen: it looks like > the function is supposed to be capable of automatic conversion. > > I used ncgen -f on a .cdl file to generate a .f file. I modified that > to be 2 subroutines, the first to create a cdf file, define variables, > and write any non-unlimited dimensioned variables, and the second to > permit writing successive records of the unlimited dimensioned variables. > I think I did this correctly, as ncdump gives back what I expect, as far > as the number of records is concerned. > > But, the first thing I noticed was that a character*2 with a value of 0 is reported by ncdump to be 8242. If I change the value to 1 or -1 > (or anything else), I get the conversion error above. > > If I may, I'll describe what seems to be going on -- limiting things > to just one variable in my questions: > > The cdl code looks like this: > > dimensions: > nvec = unlimited; > variables: > short ms_time(nvec); > data: > ms_time = -1 ; > > The fortran code for the definition subroutine shows: > > integer ms_time_id > integer ms_time_rank > parameter (ms_time_rank = 1) > integer ms_time_dims(ms_time_rank) > ms_time_dims(1) = nvec_dim > iret = nf_def_var(ncid, 'ms_time', NF_INT2, ms_time_rank, ms_time_ > 1dims, ms_time_id) > > The fortran code for the writerec subroutine shows: > (I moved all the var_id names in the calling parameter list to a common > block in an include file, and instead pass a structure containing all the > defined variables) > > integer ms_time_id > integer ms_time_rank > parameter (ms_time_rank = 1) > integer ms_time_start(ms_time_rank), ms_time_count(ms_time_rank) > integer ms_time_nr > parameter (ms_time_nr = 1) > integer ms_time(ms_time_nr) !this is unused > > integer recnum > parameter recnum / 0 / > > recnum = recnum + 1 > > * store ms_time > ms_time_start(1) = recnum > ms_time_count(1) = ms_time_nr > iret = nf_put_vara_int(ncid, ms_time_id, ms_time_start, > $ ms_time_count, vec_rec.ms_time) > > I then find that setting vec_rec.ms_time = anything other than 0 begets > the error. Leaving it 0 causes 8242 to appear in the output file. It is > defined as <integer*2 ms_time> in the structure vec_rec. There's the problem. The routine <nf_put_vara_int(...)> is for writing an array of Fortran integers -- not integer*2-s. The routine is *not* a generic one. > (I tried using > ms_time(1), but that didn't work. It will not work to specify > <integer ms_time> as other code relies on the current definition. I > also tried <integer*2 jnk(ms_time_nr) / -1 / to see if using a structure > variable was really the cause -- it also failed). > > If, instead, I set the < integer ms_time > to -1 and pass _that_ to > nf_put_vara_int(), ncdump shows a -1 for every time I called writerec, > as expected. > Apparantly, it successfully converts an int*4 to an int*2 but doesn't > know what to do when trying to put an int*2 into an int*2?? > > On the other hand, if I use nf_put_vara_int2() instead of > nf_put_vara_int(), vec_rec.ms_time is again written correctly. This is the correct way to do what you want: use the routine <nf_put_vara_int2(...)>. > Am I wrong in assuming that nf_put_vara_int() is supposed to be a generic > routine (since that's what ncgen wrote)? If the "ncgen" utility generated code that used the routine <nf_put_vara_int(...)> to write an integer*2 array into a netCDF NF_INT2 variable, then that's a bug in the ncgen utility. However, I just ran "ncgen" on your CDL and the code it generated had "ms_time" as an integer and used <nf_put_vara_int(...)> to write it. This is correct behavior. You might rerun ncgen on your CDL to verify. > If not, is there a workaround, > other than checking every variable and using the specific nf_put_vara_type > routine? > > Perhaps this has already been discussed somewhere? If so, perhaps > you'd be able to let me know how to use the archived support emails > better, as I didn't find any that said this was a problem. > > we are using netCDF: 3.4 of Mar 9 1998 10:28:59 $ > > Any insight appreciated -- thanks ... Regards, Steve Emmerson <http://www.unidata.ucar.edu>