[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 20050426:NetCDF 3.6.0_p1 on NEC SX
- Subject: Re: 20050426:NetCDF 3.6.0_p1 on NEC SX
- Date: Mon, 02 May 2005 09:21:30 -0600
Hi Rene,
> > That sound right. A similar problem was reported some time ago, for
> > which we recommended a workaround similar to what you found:
> >
> http://my.unidata.ucar.edu/cgi-bin/getfile?file=/content/support/help/MailArchives/netcdf/msg01440.html
>
> what about my attached solution? Doing it this way would avoid any
> hand tuning following the configure but everything should work then
> right out of the box. The README in the gzipped tar file describes
> what has been done.
I've just had a chance to look at your solution, and it looks like the
way we should do it. Thanks very much for working this out and
sending it to us. I'll see if I can incorporate this into our f90
sources for the next netcdf release.
> I have tested it with the Intel Fortran Compiler (which does not
> support int1 either). The f90 test case worked. Changing the kind
> value for the variable that is written to the nc file gave the
> expected results. Setting it to TwoByteInt worked, and OneByteInt
> resulted in a compilation error since the interface.
>
> Still this is not 100% waterproofed as one should also detect during
> the configure whether any two kind values have the same
> representation and set the F90FLAGS flags accordingly. If
> e.g. integer*2 has the same representation as integer*4 F90FLAGS
> should be set to "${F90FLAGS} -D__NO_INT2", and if integer*1 has the
> same representation as integer*2, -D__NO_INT1 should be set.
That sounds like a relatively simple addition to our configure script.
We'll put it on our list to add, but it may have to wait until after
our first release of netCDF-4, which is currently our top priority.
--Russ