[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
20010130: Numeric conversion not representable?
- Subject: 20010130: Numeric conversion not representable?
- Date: Tue, 30 Jan 2001 15:49:04 -0700
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>