[MITgcm-support] G95 build issue: f2c name mangling

[Mark Hadfield]

Ed Hill wrote:
> <rant>
>
> </rant>
>
>   
I love a good rant! I'm not sure that yours qualified, though, because 
it was too constructive.

I think the first rule for Fortran-C binding is "Don't (unless you 
really have to)". If the requirement is to estimate how long your code 
takes to execute, then I don't think you really have to (use C, that 
is). The Fortran 95 standard provides a CPU_TIME intrinsic and most 
Fortran compilers that don't support that provide something 
non-standard. The ROMS model has quite an elaborate scheme for timing 
its code and here is the routine that does the donkey work, in its entirety:

!
!-----------------------------------------------------------------------
      FUNCTION my_wtime (wtime)
!-----------------------------------------------------------------------
!
      USE mod_kinds

      implicit none

      real(r8), intent(out) :: wtime(2)
      real(r8) :: my_wtime
#ifdef CRAYX1
      integer :: count, count_rate, count_max
#endif

#ifdef CRAYX1
      CALL system_clock (count, count_rate, count_max)
      my_wtime=REAL(count,r8)/REAL(count_rate,r8)
#else
      CALL cpu_time (wtime(1))
      my_wtime=wtime(1)
#endif

      RETURN
      END FUNCTION my_wtime

Of course, ROMS does have the advantage that it's written in Fortran 90 
and virtually all Fortran 90 compilers these days support Fortran 95.

Now, this doesn't do everything that the MITgcm scheme does. The 
distinction between "system" and "user" time is lost. Wall clock time is 
not distinguished from CPU time, though ROMS does print out date & time 
at the beginning and the end of each run.

If people live with these simplifications, then a lot of messiness could 
be avoided.

-- 
Mark Hadfield          "Kei puwaha te tai nei, Hoea tahi tatou"
m.hadfield at niwa.co.nz
National Institute for Water and Atmospheric Research (NIWA)