netCDF character variables in GMT grd files

In a mail message to netcdfgroup <9209060450.AA03786@xxxxxxxxxxxxxxxxxxxxxxx>,
  Mark <collier@xxxxxxxxxxxxxxxxxxxxxxx> writes:

>I have tinkered around with libraries and utilities from both
>packages and am unsure why ncgen and ncdump (from netCDF)
>are not compatable with the "2-D binary netCDF grd-file in the
>GMT-SYSTEM"?

I also found the problem. I made "grd" files (to be used with GMT) using
the Fortran interface of netCDF library. When I tried to view them with
"grdinfo" of the GMT package, some character strings were not displayed
properly, though it apparently does not make problems in graphic
applications of GMT.

In the netCDF library, character strings are fixed-length, as in
the Fortran 77 standard (though netCDF is impremented primarily with C).
The strings are not "null-terminated".

GMT uses, in some places of the code of "gmt_grdio.c",
standard C string-manipulating functions (strcpy, strncpy, strcat, etc.), 
in which character strings are, as I guess --I am not so familiar to C
as to be confident--, assumed to be terminated with NULLs (0x00).
In the present code (GMT ver. 2.1.1), such usage is limited to the task
of separating one netCDF variable "source" into two variables "command" and
"remark" of GMT, or vice versa.

According to my personal memory (I have already deleted the code), 
an older version (2.0.2) of GMT used standard C functions more extensively,
and incompatibility between netCDF "ncdump" and GMT "grdinfo" happened
about all character strings. When "grd" files made by GMT is viewed by
"ncdump", there appear garbage characters after each NULL; when those
made just by netCDF library is viewed by "grdinfo", other strings were
appended to each string value (until NULL is encountered).

I guess that this incompatibility now happens only about variables "command"
and "remark", when GMT 2.1.1 is used.  But the "grd" files contained in
the examples of GMT 2.1 have null-terminated strings for other character
variables. I am not sure whether these files are made by an older version
of GMT, or the present version can still make such strings.

I don't think this incompatibility so serious, as long as
graphic application of GMT does not retrieve these string variables.

--
Let's have a macroscope!               Kooiti MASUDA
                                       Dept. of Earth & Planetary Physics
                                       Univ. of Tokyo
                             internet: masuda@xxxxxxxxxxxxxxxxxxxxx


  • 1992 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: