Search code examples
fortranfortran90f2py

f2py complication due parameter array dimensions being defined in modules / common blocks


I have the following subroutine in Fortran 90:

subroutine foo(bar)

  use spam ! dimension n is defined in the module spam

  implicit none

  real*8 bar(n)
  ....
end subroutine foo

Since the array dimension n is defined in module spam, I am getting errors during the compilation of the C wrapper functions (generated by f2py), like

error: ‘n’ undeclared (first use in this function)

Because the C wrapper function does not have any reference to spam or n.

What should be the solution to this?

I am currently preparing the bindings for ginormous Fortran program, a program which I have not authored. I now think that it is bad practice to pass information regarding parameters in common blocks/modules, just because it can lead to problems like this.

Is there any workaround, or do I have to refactor the whole code to add array dimensions as parameters?

Also, there is no chance of modifying the C source, because it is auto generated by f2py.


Solution

  • mod.f90

    module m
      integer :: n = 1
    end module
    

    main.f90

    subroutine s
      use m
      real :: a(n)
      print *,n
    end subroutine
    

    python:

    f2py -c -m main mod.f90 main.f90
    
    
    ipython
    
    In [1]: import main
    
    In [2]: main.s()
           1
    
    In [3]: main.m.n=5
    
    In [4]: main.s()
               5
    

    I don't see any problem in using module variables.

    ---Edit---

    I can confirm the problem with explicit size array dummy arguments, when the size depends on a module variable (not a named constant), i.e.:

    subroutine s(a)
      use m, only: n
      real :: a(n)
    end subroutine
    

    One way of avoid the explicit bounds is using assumed shape arrays (a(:)). The assumed size arrays require an explicit interface, so they must be placed in a module which the calling code uses, or an interface block has to be supplied. Modules are generally preferred.