[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20010130: Numeric conversion not representable?

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>