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

20050405: problem using UDUNITS with Fortran code

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: 20050405: problem using UDUNITS with Fortran code
  • Date: Wed, 06 Apr 2005 15:41:42 -0600
Yuanchong,

>Date: Wed, 6 Apr 2005 17:31:17 -0400 (EDT)
>From: Yuanchong Zhang <address@hidden>
>Organization: Columbia University/NASA GISS
>To: address@hidden (Steve Emmerson)
>Subject: Re: 20050405: problem using UDUNITS with Fortran code
> Keywords: 200504051922.j35JM9v2005883

The above message contained the following:

>       The option 3 doesn't work. I'm asking our system people to
> look at option 2.
>       Meanwhile, for option 1, besides those lines without C that I
> should declare in my Fortran program, I don't know how do deal with 
> 
> #ifndef PTR
> #   define PTR        integer
> #endif

The Fortran function UTMAKE returns a C pointer to a new unit
data-structure.  This value must be stored in a Fortran data-type that
is the same size as a C pointer.  Typically, this is an INTEGER*4 -- but
it will be an INTEGER*8 on 64-bit systems.

If you're not going to use the PTR definition in the "udunits.inc" file,
then you will have to determine the Fortran data-type appropriate for
your system.  You should consistently use this data-type in your Fortran
code wherever the UDUNITS API expects the return value from UTMAKE.

For example:

    integer*4   speedUnit
    ...
    utdec('furlongs/fortnight', speedUnit);
    ...

>       Please give me specifics about it. I'm attaching the
> udunits.inc file so you can give me back all the lines I should
> declare. Thank you. 
> 
> Yuanchong

Regards,
Steve Emmerson