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

Re: 20050426:NetCDF 3.6.0_p1 on NEC SX

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: 20050426:NetCDF 3.6.0_p1 on NEC SX
  • Date: Wed, 27 Apr 2005 12:53:18 -0600
Hi Rene,

> The problem I was addressing is more related to a design issue of
> the NetCDF F90 interface rather than to anything particular for the
> NEC SX system, I think.
>
> The configure script checks whether support for different integer
> representations is available or not which is fine. Since on the SX
> e.g. integer*1 is not available no interfaces should be built
> neither for f77 nor f90.
> 
> Since the selected_int_kind intrinsic will return the smallest kind
> value available to represent the requested range it will return the
> same value for OneByteInt and TwoByteInt I hope on any system that
> does not support e.g. integer*1 or integer(kind=1). At least this is
> what I would expect from a proper implementation of the
> selected_int_kind on a given system.
> 
> In this case this will lead to identical f90 interface descriptions
> for two subroutines of the same nf-family, say nf_put_var_int1 and
> nf_put_var_int2: After assigning OneByteInt and TwoByteInt to the
> same value (e.g. 2) declarations of the parameters for the two
> subroutines are identical. The SX compiler will return with an error
> in such cases, which I think is acceptable. Since I don't have the
> NetCDF sources in front of me while typing this response I may have
> overlooked something. So please correct me if I am wrong or if I
> have a wrong view of these things.

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

> My question is now, whether an updated how-to for a installation of
> the NetCDF_3.6.1 should be provided on your site (I could provide a
> summary) or whether you accept my request as a general design issue
> of the f90 interface and fix it in some forthcoming release.

The f90 interface was developed as a volunteer effort so supporting
the way it's currently implemented is difficult for us.  If you could
provide us a summary, that would be great.  Thanks!

Eventually, I'd like to see the f90 interface rewritten to directly
call the C library instead of going through the f77 interface, but
that won't be done for 3.6.1.  Since the next Fortran standard is
supposed to specify a standard way to call C from Fortran, there is
some hope that we could use that to simplify our implementation.

--Russ

_____________________________________________________________________

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