Intent related compilation errors

For context, I’m a complete newbie to fortran and only have limited experience with programming in general. I have mostly worked with python or matlab previously.

I’m trying to wrap some fortran code for solving delay differential equations with f2py. (The code was found here Fortran Codes). While trying to compile the code using gfortran on windows, I saw some errors. I assume I am doing something wrong, since the code itself is from a very reputable source.

I used the command:

gfortran radar5.f -o test

In addition to many errors about array dimensions being out of bounds, there was an error related to one variable’s intent attribute:

As far as I can tell, the variable in question has the attribute intent(inout) everywhere it’s being used. I’m sure the issue has to do with the fact that this code is pretty old, but I’m not sure what options I should be using.

Any help or relevant resources would be greatly appreciated

you can change

REAL(kind=DP), dimension(1), intent(inout) :: GRID 

to

REAL(kind=DP), dimension(1), intent(in) :: GRID 

at line 2821
,since the intent attribute is not conform.

I tried this with gfortran 11.3.0 under cygwin.

Variable GRID is declared as:

  • INTENT(IN) in SUBROUTINE RADCOR at line 913
  • INTENT(INOUT) in SUBROUTINE BPDTCT at line 2821

I think you can make it INTENT(IN) in SUBROUTINE BPDTCT. Neither the compiler nor I could find an assignment.

The many “Warning: Array reference at (1) is out of bounds” warnings are probably harmless. This is common in (very) old Fortran code. Hasn’t been necessary since Fortran77.

I then see several warnings about COMMON /POSITS

 2946 |         COMMON /POSITS/X0B,UROUND,HMAX,IACT,IRTRN,IDIF,MXST,FLAGS,FLAGN
      |                       1
Warning: Named COMMON block ‘posits’ at (1) shall be of the same size as elsewhere (56 vs 48 bytes)
radar5.f:500:21:

These are a problem. I suspect one of the variables has the wrong type - and therefore size - somewhere, but I don’t have time to look now. If so, then memory corruption is possible.

The warning about common block POSITS is due to an error in SUBROUTINE BPACC

The last two variables in COMMON /POSITS/ are declared as LOGICAL in the other subroutines but not declared, and therefore typed as IMPLICIT DOUBLE PRECISION, in BPACC. The variables aren’t used in this subroutine to no actual damage is done.

This shows the improvements in compiler diagnostics since this code was written.

I tried the example ENZYME in the tarball. There were a couple of issues with the driver routine dr-Enzyme.f Once fixed the results match those published in [1]

$ diff -c dr-Enzyme.f.0 dr-Enzyme.f
*** dr-Enzyme.f.0       Tue Dec 21 00:18:19 2004
--- dr-Enzyme.f Tue Mar 21 14:22:02 2023
***************
*** 236,246 ****
          INTEGER, dimension(1) :: IPAST
          REAL(kind=DP), dimension(1) :: RPAR
          INTEGER, dimension(1) :: IVE,IVC,IVL
!         EXTERNAL PHI

  C       FIRST DELAY
          CALL LAGR5(1,X,Y,ARGLAG,PAST,ALPHA1,IPOS1,RPAR,IPAR,
!      &             PHI,IPAT,NRDS)

          Y4L1=YLAGR5(4,ALPHA1,IPOS1,PHI,RPAR,IPAR,
       &              PAST,IPAST,NRDS)
--- 236,246 ----
          INTEGER, dimension(1) :: IPAST
          REAL(kind=DP), dimension(1) :: RPAR
          INTEGER, dimension(1) :: IVE,IVC,IVL
!         EXTERNAL PHI,ARGLAG

  C       FIRST DELAY
          CALL LAGR5(1,X,Y,ARGLAG,PAST,ALPHA1,IPOS1,RPAR,IPAR,
!      &             PHI,IPAST,NRDS)

          Y4L1=YLAGR5(4,ALPHA1,IPOS1,PHI,RPAR,IPAR,
       &              PAST,IPAST,NRDS)

Results from test case
sol

Published results from [1]

[1] Hairer, E, S. P. Norsett, and G. Wanner. *Solving Ordinary Differential Equations: Nonstiff Problems" Springer, 2009, page 349

Thanks for all the help. I’m glad the code is reliable despite its age. I was able to compile after applying the edits suggested. Now I just have to get f2py to work properly with it.