Re: String extension to netCDF

• To: pack@xxxxxxxxxxxx
• Subject: Re: String extension to netCDF
• From: davis
• Date: Mon, 24 Jun 1991 11:28:23 -0600

> Date: Mon, 24 Jun 1991 09:16:23 -0600
> From: pack@xxxxxxxxxxxx (Daniel Packman)
> To: davis@xxxxxxxxxxxxx
> Subject: String extension to netCDF
> Cc: bailey@xxxxxxxxxxxx, cacraig@xxxxxxxxxxxx, chucks@xxxxxxxxxxxx
> 
> The character primitive in netCDF seems to be more of a convenient
> string-*like* example of other internal primitives (eg, float or long)
> in that it has an intrinsic size (a byte) and a dimension.  A more direct
> analog of string would have an intrinsic size (a series of bytes) and a
> dimension.
> 
> I think it would be convenient to have a real string primitive that would
> be of great value particularly in dimensioned attributes.  Currently,
> the "dimension" of a character attribute is just its length.  This means
> that it is awkward to specify a series of strings.  One must either use
> separate attributes for each or have some pre-defined separator within
> the string.

There is a convention in the "history" global attribute to use the newline
character as a separator in this fashion. Russ may wish to speak further
about this.
 
> The internal storage of such an object could be driven by the c language,
> that is, a series of bytes terminated by a zero byte.  The mapping to
> a fortran character variable that responds properly to the len()
> intrinsic is clear.

The underlying system has a "NC_STRING" datatype, and the underlying
system support arrays of XXX, where XXX is NC_BYTE, NC_CHAR...
So, it would be quite straightforward to implement.
There would be a backward compatibility issue if it were implemented.

I think the rational for NOT including this at the user interface level
includes the following points:

        For simplicity: only include (some subset of) primitive types.
        (Symmetry would seem to ask us to handle arrays of arrays
        of other types than char as well.)

        Altho "C" has this notion of "string" type as a NULL terminated
        array of char, there is no cooresponding fortran structure.
        You suggest a string with "intrinsic size". This size would
        either need be hardwired into the netcdf code (undesirable)
        or available via the interface, further compilicating it.

-glenn

>From owner-netcdfgroup@xxxxxxxxxxxxxxxx    24 Thu, Oct
Date:    Thu, 24 Oct 1991 16:32:28 EDT
From: GUMLEY@xxxxxxxxxxxxxxxxxx (Liam E. Gumley)
To: netcdfgroup@xxxxxxxxxxxxxxxx
Subject: How to write/read netCDF files from VAX/VMS to/from magtape?
Received: by unidata.ucar.edu id AA16480
  (5.65c/IDA-1.4.4 for netcdfgroup-send); Thu, 24 Oct 1991 14:32:40 -0600
Received: from ltp2.gsfc.nasa.gov by unidata.ucar.edu with SMTP id AA16476
  (5.65c/IDA-1.4.4 for <netcdfgroup@xxxxxxxxxxxxxxxx>); Thu, 24 Oct 1991 
14:32:35 -0600
Message-Id: <911024163229.21c006e1@xxxxxxxxxxxxxxxxxx>
X-Vmsmail-To: SMTP%"netcdfgroup@xxxxxxxxxxxxxxxx"

The subject line pretty much says it all.

We are creating netCDF data files (of fairly large size) on a VAX/VMS
system, and we need to write them to magnetic tapes.  The important
point is, these magtapes *must* be readable by systems *other* than
VAX/VMS.  So that kind of forces us to use FOREIGN tapes, rather than
BACKUP tapes.  We could use ANSI labelled tapes, but I have found them to
be unreliable when read on different systems.

So, does anybody have, or know of, a utility which will write/read
netCDF files from VAX/VMS to FOREIGN magnetic tapes?

All replies are very welcome.

Cheers,
Liam.

BTW, a VMS FORTRAN INQUIRE on a netCDF file on the VAX tells me it has
variable length, Stream_LF delimited records.

--
Liam E. Gumley                                  
MODIS Science Data Support Team
Research and Data Systems Corporation              Disclaimer:
Greenbelt MD, USA                                  Opinions I express here are
gumley@xxxxxxxxxxxxxxxxx                           my own, not the company's.