Re: Bug report: PyNIO sets incorrect length for attributes

From: David Brown <dbrown_at_nyahnyahspammersnyahnyah>
Date: Wed, 31 Dec 2008 18:47:29 -0700

Hi Carl,
I have checked in a fix for this problem.
If you want a new version email Mary Haley.
  -dave

On Dec 31, 2008, at 9:48 AM, pyngl-talk-bounces_at_ucar.edu wrote:

> The attached message has been automatically discarded.
> From: Carl Drews <drews_at_ucar.edu>
> Date: December 31, 2008 9:48:53 AM MST
> To: pyngl-talk_at_ucar.edu
> Subject: Bug report: PyNIO sets incorrect length for attributes
>
>
> PyNIO version: 1.2.0
>
> System: Linux 2.6.18-92.1.10.el5.centos.plus #1 SMP Thu Aug 7
> 12:19:36 EDT 2008 i686 i686 i386 GNU/Linux
>
> I am creating a new NetCDF forcing file with certain variables, as
> shown below. Note that ocean_time is a dimension AND a variable.
>
> file = Nio.open_file(filename, 'c')
>
> # create dimensions for the grid variables
> file.create_dimension('eta_u', yPoints + 1)
> file.create_dimension('xi_u', xPoints)
> file.create_dimension('eta_v', yPoints)
> file.create_dimension('xi_v', xPoints + 1)
> file.create_dimension('ocean_time', None)
>
> # create the simulation time
> newVar = file.create_variable('ocean_time', 'd', ('ocean_time',))
> newVar.long_name = 'time since initialization'
> newVar.units = 'seconds since 0001-01-01 00:00:00'
> newVar.calendar = "julian"
> newVar.field = 'time, scalar, series'
> newVar[0] = 0
> newVar[1] = 3600
> newVar[2] = 7200
>
> # create variables for wind stress
> newVar = file.create_variable('sustr', 'f', ('ocean_time',
> 'eta_u', 'xi_u'))
> newVar.long_name = 'surface u-momentum stress'
> newVar.units = 'newton meter-2'
> newVar.time = 'ocean_time'
> newVar.coordinates = 'x_u y_u ocean_time'
> newVar.field = 'surface u-momentum stress, scalar, series'
> #newVar._FillValue = 1.0e37
> newVar[0,:,:] = 1.23
> newVar[1,:,:] = 2.34
> newVar[2,:,:] = 3.45
> ...
> file.close()
>
> Everything looks fine with ncdump -h winds.nc | less :
>
> variables:
> double ocean_time(ocean_time) ;
> ocean_time:long_name = "time since initialization" ;
> ocean_time:units = "seconds since 0001-01-01
> 00:00:00" ;
> ocean_time:calendar = "julian" ;
> ocean_time:field = "time, scalar, series" ;
> float sustr(ocean_time, eta_u, xi_u) ;
> sustr:long_name = "surface u-momentum stress" ;
> sustr:units = "newton meter-2" ;
> sustr:time = "ocean_time" ;
> sustr:coordinates = "x_u y_u ocean_time" ;
> sustr:field = "surface u-momentum stress, scalar,
> series" ;
>
> But when I run the ROMS ocean model (written in Fortran), it thinks
> that there is an extra null character at the end of "ocean_time":
>
> GET_2DFLD - unable to find requested variable: ocean_time^@
> in input NetCDF file: winds.nc
>
> Here ROMS is looking for the 'time' attribute of sustr, which is
> 'ocean_time'. But of course 'ocean_time^@' is not a recognized
> variable.
>
> I did a hexdump of winds.nc to see what are the exact bits:
>
> hexdump -C winds.nc | less
>
> 00000170 00 00 00 09 6c 6f 6e 67 5f 6e 61 6d 65 00 00 00
> |....long_name...|
> 00000180 00 00 00 02 00 00 00 1a 73 75 72 66 61 63 65 20
> |........surface |
> 00000190 75 2d 6d 6f 6d 65 6e 74 75 6d 20 73 74 72 65 73 |u-
> momentum stres|
> 000001a0 73 00 00 00 00 00 00 05 75 6e 69 74 73 00 00 00 |
> s.......units...|
> 000001b0 00 00 00 02 00 00 00 0f 6e 65 77 74 6f 6e 20 6d
> |........newton m|
> 000001c0 65 74 65 72 2d 32 00 00 00 00 00 04 74 69 6d 65 |
> eter-2......time|
> 000001d0 00 00 00 02 00 00 00 0b 6f 63 65 61 6e 5f 74 69
> |........ocean_ti|
> 000001e0 6d 65 00 00 00 00 00 0b 63 6f 6f 72 64 69 6e 61 |
> me......coordina|
> 000001f0 74 65 73 00 00 00 00 02 00 00 00 13 78 5f 75 20 |
> tes.........x_u |
> 00000200 79 5f 75 20 6f 63 65 61 6e 5f 74 69 6d 65 00 00 |y_u
> ocean_time..|
> 00000210 00 00 00 05 66 69 65 6c 64 00 00 00 00 00 00 02
> |....field.......|
>
> Apparently NetCDF stores strings with a leading length byte that
> represents the number of characters. On line 1c0 we see that the
> attribute name 'time' has 04 characters. This is correct.
>
> But on line 1d0 the attribute value 'ocean_time' is supposed to
> have 0b characters, or 11 letters. The string 'ocean_time' has
> only 10 letters. The length byte on line 1d0 should be 0a, not 0b.
>
> I can see that this problem would not show up in languages like C++
> that use a string terminating character of null (\0). But since
> ROMS is written in Fortran, ROMS reads an extra character there.
>
> Has this problem been fixed in PyNIO 1.3?
>
> Carl
> Atmospheric Chemistry Division
>
>

_______________________________________________
pyngl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/pyngl-talk
Received on Wed Dec 31 2008 - 18:47:29 MST

This archive was generated by hypermail 2.2.0 : Thu Jan 01 2009 - 08:39:20 MST