segmentation fault: gasdf.c:3237, index out of bound

Jennifer Adams jma at COLA.IGES.ORG
Fri Feb 22 13:01:35 EST 2008


Ryo et al.,
The seg fault happens when you try to display the 3-dimensional
variable tr with the Z dimension set to something other than 1. That
is a bug in the sdfopen code in GrADS 1.9. That code is no longer in
version 2.0, and I am unlikely to spend any time debugging it since
the problem is readily fixed if you use a 'dtype netcdf' descriptor
file:

DSET    ^mom_clim46.nc
dtype netcdf
options zrev
TITLE   Ocean Only Model to Case 45
UNDEF   -2.56E33  missing_value
XDEF 362 LINEAR 115.0 0.5
YDEF 142 LINEAR -35.0 0.5
ZDEF 30  LEVELS
   5.0000   15.0000   25.0000   35.0000   45.0000   55.0000
65.0000   75.0000   85.0000   95.0000
   105.0000  115.9789  129.7985  148.0428  171.8625  201.8625
238.0428  279.7985  325.9789  375.0000
  425.0000  491.1513  604.1757  790.2066 1068.2310 1448.2310
1930.2066 2504.1757 3151.1513 3845.0000
TDEF 12 LINEAR 1JAN1998  1mo
VARS   5
u          30  t,z,y,x  U velocity
v          30  t,z,y,x  V velocity
temp       30  t,z,y,x  Temperature
s          30  t,z,y,x  Salinity(PSU)
tr          0  t,y,x    Transport(Sv)
ENDVARS

With this descriptor, the variable tr displays correctly no matter
what the Z dimension is set to.  If you continue to have problems,
please let me know.

Debugging this problem also revealed a little bug in the netcdf
handling code in version 2.0 for Z-reversed data, so thanks for
helping me uncover that.

More inline below on the Z index:

On Feb 21, 2008, at 4:50 AM, Ryo Furue wrote:

> Hi Jennifer,
>
> | You will have to provide all the ncdump -c
> | output from your file -- maybe this will help me to reproduce the
> | error.
>
> I've created a more complete "kit" to reproduce the error:
>
>   http://iprc.soest.hawaii.edu/~furue/tmp/grads-segfault.tar.gz
>
> Download this archive, expand it, descend into the directory,
> and run the GrADS script "segfault.gs" contained in it.
> The archive is about 370MB.
>
> | As for the positive:down attribute, GrADS was designed with the
> | atmosphere in mind, so z=1 is the bottom (close to the surface) and
> | z=zmax is at the top.  When your z axis is depth, this orientation
> | is maintained, so that the bottom (deepest) level is z=1 and the top
> | (shallowest) layer is z=30. That is somewhat opposite to the way
> | oceanographers think of the Z (depth) axis, where z=1 is usually at
> | or just below the surface.
>
> Does that mean "z" is NOT an index into the underlying array?
No it does not mean that. Z is the grid index for the vertical
dimension in GrADS.
>
> After opening my netCDF file (such as the ones contained
> in the kit above), this command
>
>   ga-> set lev 5
>   ga-> d temp
> correctly plots sea surface temperature, and
>   ga-> set lev 3845
>   ga-> d temp
> correctly plots bottom temperature.
these commands work because you're using world coordinates (set lev)
and not grid indices (set z).

> So, unless GrADS bothers to transpose the temperature array
GrADS bothers to do this when you have 'options zrev' in your
descriptor file or 'positive down' as a netcdf attribute.

> on memory, index 1 of the array's 3rd dimension must be
> correctly pointing to lev=5, and index 30 must be pointing
> to lev=3845, because that's how my array is stored in
> my netCDF file.  Therefore, "z" is not an index. . . .
>
> Is there a variable which is a true index into the
> underlying array? such as i, j, and k?
>
> Ryo

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jma at cola.iges.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gradsusr.org/pipermail/gradsusr/attachments/20080222/65de3527/attachment.html 


More information about the gradsusr mailing list