Arjen, > I found the problem. I defined the variable as an integer, but was writing > reals. The description of the error code was what put me on the wrong foot. Great, thanks for letting us know. It looks like you've also pointed out a place where our documentation needs improvement. > I have found a few curious things though: > > - nf90_put_var does not accept a scalar value (if I remember this one > correctly) Hmm, the documentation says you can write single values with nf90_put_var, where it describes the "values" argument: http://www.unidata.ucar.edu/netcdf/docs/netcdf-f90.html values The data value(s) to be written. The data may be of any type, and may be a scalar or an array of any rank. You cannot put CHARACTER data into a numeric variable or numeric data into a text variable. For numeric data, if the type of data differs from the netCDF variable type, type conversion will occur. See Type Conversion. Although the f90 tutorial examples all write arrays, there's a test case (nf_test/f90tst_vars2.f90) in the source distribution that writes a single value to a scalar variable successfully and later reads the file to check that the right value gets read in: call check(nf90_put_var(ncid, varid3, TOE_SAN_VALUE)) ... call check(nf90_get_var(ncid, varid3_in, toe_san_in)) if (toe_san_in .ne. TOE_SAN_VALUE) stop 14 If you came up with an example scalar write that fails, we'd like to use it to debug the problem. > - nf90_put_var with integer values wants the values argument to have > the same dimensionality as the start and count arguments are long (or so I > interpret the problem I had when I passed a one-dimensional array for a > two-dimensional NetCDF variable - error nf90_eedge). If I pass a > one-dimensional real array for a two-dimensional NetCDF variable, there is no > such error. Right, since there's only one write routine, nf90_put_var, that uses overloading to provide what requires about 30 different write functions in the C API, it has to get information about what's intended from the number, shapes, and types of the arguments. > Thanks anyway for the help so far. No problem, I'm glad you got it working! --Russ > From: Arjen Markus > Sent: Friday, February 06, 2015 2:24 PM > To: 'address@hidden' > Subject: RE: [netCDF #YJQ-627045]: Problem with return code NC_EBADTYPE > (NetCDF3) in Fortran program > > > Hi Russ, > > > > I have been able to reduce the program to a smaller size and to use a very > small NetCDF file as a template. I have attached it as a zipped tarball: the > program code, the template file to be used and the output I get with the > mysterious error code -49 for writing time. (The full program will produce a > -49 error code for writing the values of "salinity" as well, but here it is > -45, as a consequence of reducing the program.) > > > > Regards, > > > > Arjen > > > > -----Original Message----- > > From: Unidata netCDF Support [mailto:address@hidden > > Sent: Wednesday, February 04, 2015 8:49 PM > > To: Arjen Markus > > Cc: address@hidden<mailto:address@hidden> > > Subject: [netCDF #YJQ-627045]: Problem with return code NC_EBADTYPE > > (NetCDF3) in Fortran program > > > > Hi Arjen, > > > > > I am trying to write a single integer value to a NetCDF file and I get > > > the return code -45 (NC_EBADTYPE). Here are (hopefully useful) > > > fragments of the code: > > > > > > The variable is created using: > > > ierror = nf90_def_var( ncidout, name, nf90_int, (/ ntimeid /), timeid > > > ) > > > > > > where the ntimeid is a unlimited dimension. > > > > > > I use the following code to write a value: > > > > > > integer function dlwqnc_write_wqtime( ncidout, timeid, record, time ) > > > integer, intent(in) :: ncidout integer, intent(in) :: timeid integer, > > > intent(in) :: record integer, intent(in) :: time > > > > > > integer :: ierror > > > integer, dimension(1) :: values > > > integer, dimension(1) :: start > > > integer, dimension(1) :: count > > > > > > dlwqnc_write_wqtime = nf90_noerr > > > > > > values = time > > > start = record > > > count = 1 > > > ierror = nf90_put_var( ncidout, timeid, values, start, count ) if ( > > > ierror /= nf90_noerr ) then dlwqnc_write_wqtime = ierror return endif > > > > > > end function dlwqnc_write_wqtime > > > > > > The variable record has the value 1 and this is the first time the > > > program tries to write a value to the time variable. > > > ierror = nf90_put_var( ncidout, timeid, values, start, count ) What is > > > going wrong? I can send you the entire program, but it relies on a > > > large file. > > > > Though we can't reproduce the problem, here's two things to try. > > First, make sure you explicitly set record=0 before calling nf90_put_var, > > because if > > it's just unitialized, as in the fragment you sent, I'm not sure what kinds > > of behavior to > > expect. > > > > Secpnd, since strat and count are optional parameters to nf90_put_var, you > > ought to > > use the argument keyword to specify which is which, with: > > > > ierror = nf90_put_var( ncidout, timeid, values, start=start, count=count ) > > > > I would have thought your Fortran compiler would emit a warngin or error > > when you > > try to use optional parameters without identifying them ... > > > > > I came across a similar problem at > > > > > > https://bugtracking.unidata.ucar.edu/browse/NCF-172 > > > > > > but that seems to be a problem with NetCDF4, whereas I am using 3.6.1. > > > > First that's a pretty old version, from February 2006, and it's impractical > > for us to > > reproduce or fix bugs in 9-year old software. > > > > But if you could provide a small example that fails, I could try to > > reproduce it using > > netCDF-4 (which still supports all the > > netCDF-3 API and functionality) to see what's really going on. > > > > --Russ > > > > > Regards, > > > > > > Arjen > > > DISCLAIMER: This message is intended exclusively for the addressee(s) > > > and may contain confidential and privileged information. If you are > > > not the intended recipient please notify the sender immediately and > > > destroy this message. Unauthorized use, disclosure or copying of this > > > message is strictly prohibited. The foundation 'Stichting Deltares', > > > which has its seat at Delft, The Netherlands, Commercial Registration > > > Number 41146461, is not liable in any way whatsoever for consequences > > > and/or damages resulting from the improper, incomplete and untimely > > > dispatch, receipt and/or content of this e-mail . > > > > > > > > Russ Rew UCAR Unidata Program > > address@hidden<mailto:address@hidden> > > http://www.unidata.ucar.edu > > > > > > > > Ticket Details > > =================== > > Ticket ID: YJQ-627045 > > Department: Support netCDF > > Priority: Normal > > Status: Closed > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may > contain confidential and privileged information. If you are not the intended > recipient please notify the sender immediately and destroy this message. > Unauthorized use, disclosure or copying of this message is strictly > prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, > The Netherlands, Commercial Registration Number 41146461, is not liable in > any way whatsoever for consequences and/or damages resulting from the > improper, incomplete and untimely dispatch, receipt and/or content of this > e-mail . > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: YJQ-627045 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.