osolmaz
osolmaz

Reputation: 1923

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.

Upvotes: 2

Views: 950

Answers (1)

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.

Upvotes: 1

Related Questions