[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 970214: documentation for NetCDF 3.3

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 970214: documentation for NetCDF 3.3
  • Date: Tue, 18 Feb 1997 08:46:00 -0700
> > >To: address@hidden
> > >From: "Peter Q. Olsson" <address@hidden>
> > >Subject: documentation for NetCDF 3.3
> > >Organization: Geophysical Institute, University of Alaska Fairbanks
> > >Keywords: 199702141827.LAA15755

Hi,

> > Currently these manuals are in draft form, but they are close to being
> > complete, and will be included in the first general release of netCDF-3.
> > We still have to redo the indices and table of contents.  It would be
> > possible to generate versions of the new manuals now, but they would
> > have only crude indexes and tables of contents.
> 
> ANy release date?

I'm hoping we will finally release netCDF 3 in the next month, unless we
encounter any unanticipated problems.

> > Please let us know if you have any more questions about the new version
> > that are not answered in the prerelease notes.  If you're interested in
> > future plans for netCDF... 
> 
> A few comments.  THe build of 3.3 was kind of rough for my
> configuration, Sun ultra-2, solaris 2.5.1, Sun f77 and gcc.
> 
> Fortran problems: no such thing as an INTEGER*1.  In fact I could not
> get this to work on several other f77 compilers on otherv platforms.
> However, BYTE did work.

The prerelease you used did not yet contain the new version of the
Fortran interface, which has just been finished.  It builds cleanly on
all the platforms we have access to, but we haven't tried the (Sun f77,
gcc) combination, which is often a source of problems.

> C problems: Though configure did figure out that I was using gcc, it
> did not look for libraries in the default gcc location but in the
> paths used by cc instead. Not sure what was going on here. Also, some
> of the subordinate Makefiles do not use $(link.C) macros (at least as
> _I_ expected them to be used :^) )

Thanks for reporting this problem.  We'll look into it ...

> > P.S.:  The mail address in your message,
> > "address@hidden", doesn't work, so a previous reply
> > bounced.  I had to guess at this email address.  Please let me know if
> > you don't get this :-).
> 
> This IS wierd "address@hidden" is valid and so is
> "address@hidden" but not the hybrid listed above. I
> cannot seem to reproduce it ... Was this what your mailer tried to
> respond to with a simple "reply to" operation? Thanx for alerting me
> to a potential problem!

Yes, the automatic reply tried to send to the invalid address in the
header of your message.  I notice this message has

   From: address@hidden (Peter Q. Olsson)
 
so I'm assuming this reply will work.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu