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

Re: 20041130: NetCDF 3.6.0 Bugs

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: 20041130: NetCDF 3.6.0 Bugs
  • Date: 01 Dec 2004 13:42:37 -0700
Unidata Support <address@hidden> writes:

> ------- Forwarded Message
> 
> >To: address@hidden
> >From: "Kevin W. Thomas" <address@hidden>
> >Subject: NetCDF 3.6.0 Bugs
> >Organization: OU
> >Keywords: 200412010015.iB10F6lI010328 netCDF 3.6.0
> 
> Hi...
> 
> I have a couple of netCDF 3.6.0_beta6 bugs to report.
> 
> (1)  Scenerio...
> 
>      I'm trying to run WRFSI 2.0.1 on an SGI with 64-bit binaries.  My goal
>      is to process a huge grid.  The problem is that I start getting a lot
>      of netCDF errors due to functions returning NC_EVARSIZE, even though
>      I modified the code to call "NF_OPEN" correctly.
> 
>      I've isolated the problem to a "NF_ENDDEF" call.  The call eventually
>      ends up in "NC_begins".  ncp->flags is zero, so "sizeof_off_t" is always
>      set to 4.  The problem is that earlier on when the "ncp" pointer is
>      first set, the value of "flags" is never set.
> 
>      My workaround is to hardwire "sizeof_off_t" to 8 in "NC_begins", as I
>      require this option.

It seems very unlikely that this is a good idea. Can you send me the
code that creates the file in question? 

> 
> (2)  Scenerio...
> 
>      As released, it is not possible to build netCDF 3.6.0 for ifort/ifc
>      compilers.  My workaround is to hardware a
> 
>               #define pgiFortran
> 
>      into "cfortran.h".

It's equally possible to set this by setting environment var CPPFLAGS
to "-DpgiFortran".

> 
>      With the same compiler, I get numerous failures with "make test" on the
>      "nf_put_*_real" tests where "*" is "var1", "var", "vara", "vars", "varm",
>      and "att".
> 
>      The code obviously works, as I've been using it for daily WRF forecasts
>      for over a year.
> 
>      This is not a new bug.  The same problem exists in 3.5.1.

Is this the free fortran compiler from Intel?