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

Re: Comments promted by the release of netCDF 3.6.0-beta6

>To: address@hidden
>From: address@hidden
>Subject: Re: 20041018: Comments promted by the release of netCDF 3.6.0-beta6
>Organization: CSIRO Atmospheric Research
>Keywords: 200410180535.i9I5ZZUE009566 udunits ia64 flex yacc cdl NO_NETCDF_2 
>NaN
Hi Harvey!

Sorry it's taken so long to respond to your netcdfgroup posting.

> 1. It is certainly good to see improved support for cygwin, linux and
> 64-bit platforms.  Similar support is needed for udunits, which has not
> been updated since June 2001!

You're right, we recognize that more effort is needed to support
udunits.  As usual, it's a question of resources and priorities.  I
may be writing a proposal to NSF soon that could help to address that.
There's some controversy about what needs to be done to udunits,
visad.units, and ucar.units (the latter two are Java packages we use
in IDV and other Unidata software).  Issues include how to handle
dimensionless quantities such as concentrations, whether to support
"quantities" separately from units, relationship to javax.units
standardization effort, possible extensions to handle dates and
calendars, user-defined units (or quantities), and relationship to
ontologies work and other standards.

> 2. I successfully compiled & tested 3.6.0-beta6 on our IA64 (Intel
> 64-bit) running SGI Linux 2.4.21-sgi301rp04092819_10108. I configured
> using:
> env FC='g77' F90='' CC='gcc' ./configure

Great.  We're hoping most platforms will be that simple, and often you
don't need to specify the compilers if you're willing to accept the
priority of preferring vendor compilers to free compilers, on the
assumption that if you've paid for it, you want to use that one.

> 3. The web page
> http://my.unidata.ucar.edu/content/software/netcdf/INSTALL-beta/Installation-Requirements.html#Installation%20Requirements
> 
> contains the following:
> 
> "flex and yacc 
> Used in ncgen directory to parse cdl files. Generates C files from .y
> and .l files. The makefile warns me that I can only use the yacc on
> OSF/1. Probably this is due to the curse of the headless scientist at
> Unidata. You only need to use this to modify ncgen's understanding of
> CDL grammer."
> 
> In fact my reading of the Makefile indicates that any yacc will be
> tried, but lex (not flex) must be run on SunOS5. (udunits does still use
> only the OSF/1 yacc.) This will only affect any user crazy enough to
> want to modify the grammars, but it would be nice to provide a more
> portable solution such as using GNU flex and bison. And if the
> installation notes are to mention lex and yacc at all then the
> information should be correct!

Thanks for pointing that out, I've fixed some of the documentation.
Actually if you look at the top of the Makefile, it has the horrible
macro definition:
 
  lex = flex

so it really is trying to use flex.  When I asked Steve about this, he
remembers that the portable lex/yacc stuff didn't work on one or more
of the platforms we tested on, and the only way we could get it to
work was to use the lex and yacc on particular platforms which
generated more portable C.  I guess we need to find out if portability
is still a problem and fix the problem in the grammar and parser
rather than in the generator we use.  I would rather not depend on
flex or bison, since many users don't have those and don't want to
deal with such dependencies when installing a new library.

> 4. I am such a crazy user! I suggest the CDL grammar be extended to
> provide a standard way of representing infinity and NaN in both 32 and
> 64 bits.  At the moment such values are printed by ncdump as in the
> following example:
> 
> netcdf t {
> variables:
>         float n ;
>                 n:_FillValue = -1.#IND00f ;
>         double i ;
>                 i:_FillValue = -1.#IND0000000000 ;
> data:
>  n = _ ;
>  i = 1.#INF ;
> }
> 
> This dump is rejected by ncgen.  Different platforms will print infinity
> and NaN in different ways.

Good suggestion.  I'll look at what is needed to implement it.

> 5. There is still some use of old netcdf2 C macros. For example ncdump
> uses MAX_VAR_DIMS rather than the equivalent netcdf3 NC_MAX_VAR_DIMS.
> There are many such cases in nctest & cxx code.  I keep encountering
> this problem when I compile with the macro NO_NETCDF_2 defined.  (This
> provides a good way of detecting such obsolete code.)

Yes, you had sent a patch that I though fixed all of that, but it
apparently only fixed the libsrc/ part of the problem.  I ran with
NO_NETCDF_2 as you suggested and fixed all the other problems except
for the C++ interface.  Since that was based on netCDF 2.4, it's
taking quite a bit more work.  I'm upgrading it to use the netcdf-3
interface, but I'm leery about testing it, since we've never developed
extensive tests for the C++ interface.  If I don't get the changes
made and tested so I have some confidence in them, it will have to
wait for a later release.

As usual, thanks for the feedback.  I hope things are going well for
you.

--Russ