Re: Auto-discard notification

From: David Brown <dbrown_at_nyahnyahspammersnyahnyah>
Date: Wed, 31 Dec 2008 14:58:28 -0700

Hi Carl,

Yes you are correct that the NULL terminator is being counted and
that it is not really our intention to include it as part of the
attribute value in NetCDF files. Curiously I have discovered that the
behavior is different when assigning to an existing attribute, as
opposed to creating an attribute for the first time.

So as a temporary workaround, you can simply repeat the attribute
assignment:

newVar.time = 'ocean_time'
newVar.time = 'ocean_time'

The second statement will cause the correct string length (decimal
10) to be written to the file.

This inconsistent behavior will be fixed in version 1.3.
  -dave

> 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 - 14:58:28 MST

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