FFTW and ifort

Could you help me with solving the following problem: I'm trying to
call FFTW v.3.0.1 from ifort Intel compiler (v.8.1). Unfortunately I
get the following error messsage:

Thread received signal SEGV
stopped at [void m1_32_0(const R*, const R*, R*, R*, stride,
stride):62 0x0807048e]
62 		    T2 = ri[WS(is, 16)];
(idb) where
>0  0x0807048e in m1_32_0(ri=0xbffffba0, ii=0xbffffba8, ro=0xbffffbd0,
io=0xbffffbd8, is=0x8184500, os=0x8184588) "m1_32.c":62
#1  0x08072c9f in m1_32(ri=0xbffffba0, ii=0xbffffba8, ro=0xbffffbd0,
io=0xbffffbd8, is=0x8184500, os=0x8184588, v=8, ivs=2, ovs=64)
"m1_32.c":673
#2  0x08111ed5 in apply(ego_=0x81844a8, ri=0xbffffba0, ii=0xbffffba8,
ro=0xbffffbd0, io=0xbffffbd8) "direct.c":47
#3  0x08110e55 in apply(ego_=0x8184610, ri=0xbffffba0, ii=0xbffffba8,
ro=0xbffffbd0, io=0xbffffbd8) "ct-dit.c":34
#4  0x08056cbc in apply(ego_=0x81848c8, ri=0xbfffdba0, ii=0xbfffdba8,
ro=0xbfffdbd0, io=0xbfffdbd8) "vrank-geq1.c":63
#5  0x0805628e in apply(ego_=0x8182be8, ri=0xbfffdba0, ii=0xbfffdba8,
ro=0xbfffdbd0, io=0xbfffdbd8) "rank-geq2.c":49
#6  0x08056c2c in fftw_dft_solve(ego_=0x8182be8, p_=0x8180978)
"solve.c":30
#7  0x0804cd32 in dfftw_execute_(p=0xbfffdc00) "f77funcs.h":27
#8  0x0804ae0f in CONVOLUTION::get_potential(distro=(...), nn=(...),
size=<no value> ) "m_pot_2dim.f90":98
#9  0xb7741866
(idb)

Subroutine which calls FFTW is named get_potential(). What am I doing
wrong?
The weird thing is that exactly the same code runs well when pgf90
compiler is used.

Thanks a lot.
Jacek

> Subroutine which calls FFTW is named get_potential(). What am I doing
> wrong?
> The weird thing is that exactly the same code runs well when pgf90
> compiler is used.
>

It might be a wise idea to post the minimalized version of the code
which mimicks this behaviour. That way others will have a chance to look
at the code and determine if it really is a fftw bug.

thanks
raju

Kamaraju Kusumanchi  wrote in message
> It might be a wise idea to post the minimalized version of the code
> which mimicks this behaviour. That way others will have a chance to look
> at the code and determine if it really is a fftw bug.
>
> thanks
> raju


Here is the minimalized version of my program (main and module). It
raises the same error message as the whole one (error message comes at
the very end).

Thanks a lot,
Jacek


MAIN:
------------------------------------
program po
use con
implicit none
real(DP), allocatable :: den(:,:)
integer(8) :: nn(1:2)
integer(8) :: i,j
integer(8) :: allocate_status
nn(1:2) = 128
allocate(den(1:2*nn(1),1:2*nn(2)), STAT = allocate_status)
print*, allocate_status
do i=1, 2*nn(1)
do j=1, 2*nn(2)
den(i,j) = 0.0
if (sqrt((i-64.0)**2 + (j-64.0)**2) < 4) den(i,j) = 1.0
end do
end do
! code seems to fail at the following subroutine:
call get(den, nn)
end program po
--------------------------------

MODULE:
------------------------------------
module con
implicit none
integer, parameter :: DP = kind(1.0d0)
integer(8), parameter :: FFT_ESTIMATE = 64
contains
subroutine get(distro, nn)
implicit none
interface
subroutine  dfftw_plan_dft_2d(plan,nx,ny,in,out,dir,
FFT_ESTIMATE)
integer(8), intent(in) :: plan
integer(8), intent(in) :: nx, ny
complex(kind(1d0)), intent(inout) :: in(:,:), out(:,:)
integer(8), intent(in) :: dir, FFT_ESTIMATE
end subroutine dfftw_plan_dft_2d
subroutine dfftw_execute(plan)
integer(8), intent(in) :: plan
end subroutine dfftw_execute
subroutine dfftw_destroy_plan(plan)
integer(8), intent(in) :: plan
end subroutine dfftw_destroy_plan
end interface
integer(8), intent(in) :: nn(1:2)
real(DP), intent(inout) :: distro(1:2*nn(1),1:2*nn(2))
complex(DP) :: kdistro(1:2*nn(1),1:2*nn(2))
integer(8) :: plan
integer(8) :: direction
integer(8) :: nx, ny
nx = 2*nn(1)
ny = 2*nn(2)
kdistro(1:nx,1:ny) = cmplx(distro(1:nx,1:ny))
direction = -1
call dfftw_plan_dft_2d(plan, nx, ny, kdistro, kdistro,direction,
FFT_ESTIMATE)
call dfftw_execute(plan)
call dfftw_destroy_plan(plan)
end subroutine get
end module con
--------------------------------------------------

ERROR MESSAGE:
--------------------------------------------------
(idb) run
0
Thread received signal SEGV
stopped at [void m1_32_0(const R*, const R*, R*, R*, stride,
stride):73 0x0806e2d4]
73 		    T5 = ri[WS(is, 24)];
(idb) where
>0  0x0806e2d4 in m1_32_0(ri=0xbffff4a0, ii=0xbffff4a8, ro=0xbffff4d0,
io=0xbffff4d8, is=0x8179af8, os=0x8179b80) "m1_32.c":73
#1  0x08070a17 in m1_32(ri=0xbffff4a0, ii=0xbffff4a8, ro=0xbffff4d0,
io=0xbffff4d8, is=0x8179af8, os=0x8179b80, v=8, ivs=2, ovs=64)
"m1_32.c":673
#2  0x0810fc4d in apply(ego_=0x8179aa0, ri=0xbffff4a0, ii=0xbffff4a8,
ro=0xbffff4d0, io=0xbffff4d8) "direct.c":47
#3  0x0810ebcd in apply(ego_=0x8179c08, ri=0xbffff4a0, ii=0xbffff4a8,
ro=0xbffff4d0, io=0xbffff4d8) "ct-dit.c":34
#4  0x08054a34 in apply(ego_=0x8179ec0, ri=0xbfffe4a0, ii=0xbfffe4a8,
ro=0xbfffe4d0, io=0xbfffe4d8) "vrank-geq1.c":63
#5  0x08054006 in apply(ego_=0x81781e0, ri=0xbfffe4a0, ii=0xbfffe4a8,
ro=0xbfffe4d0, io=0xbfffe4d8) "rank-geq2.c":49
#6  0x080549a4 in fftw_dft_solve(ego_=0x81781e0, p_=0x8175f70)
"solve.c":30
#7  0x0804aaaa in dfftw_execute_(p=0xbfffe500) "f77funcs.h":27
#8  0x0804a427 in CON::get(distro=(...), nn=(...)) "m_tmp.f90":36
#9  0xc07f5967
(idb)

Jacek:  Noticed three possible things:
1) The name CON can and does cause problems on the Windows platform
(I know you're using Linux). Suggest you rename it anyway.
2) Put the Module before the main program.
3) Double check that the specifications for FFTW that gets resolved
during linking calls for DP and Integer(8).

Skip Knoble

On 11 Oct 2004 05:42:40 -0700, uoguzik@cyf-kr.edu.pl (Jacek) wrote:

-|Kamaraju Kusumanchi  wrote in message
-|> It might be a wise idea to post the minimalized version of the code
-|> which mimicks this behaviour. That way others will have a chance to look
-|> at the code and determine if it really is a fftw bug.
-|>
-|> thanks
-|> raju
-|
-|
-|Here is the minimalized version of my program (main and module). It
-|raises the same error message as the whole one (error message comes at
-|the very end).
-|
-|Thanks a lot,
-|Jacek
-|
-|
-|MAIN:
-|------------------------------------
-|   program po
-|   use con
-|   implicit none
-|   real(DP), allocatable :: den(:,:)
-|   integer(8) :: nn(1:2)
-|   integer(8) :: i,j
-|   integer(8) :: allocate_status
-|   nn(1:2) = 128
-|   allocate(den(1:2*nn(1),1:2*nn(2)), STAT = allocate_status)
-|   print*, allocate_status
-|   do i=1, 2*nn(1)
-|      do j=1, 2*nn(2)
-|         den(i,j) = 0.0
-|         if (sqrt((i-64.0)**2 + (j-64.0)**2) < 4) den(i,j) = 1.0
-|      end do
-|   end do
-|   ! code seems to fail at the following subroutine:
-|   call get(den, nn)
-|end program po
-|--------------------------------
-|
-|MODULE:
-|------------------------------------
-|module con
-|   implicit none
-|   integer, parameter :: DP = kind(1.0d0)
-|   integer(8), parameter :: FFT_ESTIMATE = 64
-|contains
-|   subroutine get(distro, nn)
-|      implicit none
-|      interface
-|         subroutine  dfftw_plan_dft_2d(plan,nx,ny,in,out,dir,
FFT_ESTIMATE)
-|            integer(8), intent(in) :: plan
-|            integer(8), intent(in) :: nx, ny
-|            complex(kind(1d0)), intent(inout) :: in(:,:), out(:,:)
-|            integer(8), intent(in) :: dir, FFT_ESTIMATE
-|         end subroutine dfftw_plan_dft_2d
-|         subroutine dfftw_execute(plan)
-|            integer(8), intent(in) :: plan
-|         end subroutine dfftw_execute
-|         subroutine dfftw_destroy_plan(plan)
-|            integer(8), intent(in) :: plan
-|         end subroutine dfftw_destroy_plan
-|      end interface
-|      integer(8), intent(in) :: nn(1:2)
-|      real(DP), intent(inout) :: distro(1:2*nn(1),1:2*nn(2))
-|      complex(DP) :: kdistro(1:2*nn(1),1:2*nn(2))
-|      integer(8) :: plan
-|      integer(8) :: direction
-|      integer(8) :: nx, ny
-|      nx = 2*nn(1)
-|      ny = 2*nn(2)
-|      kdistro(1:nx,1:ny) = cmplx(distro(1:nx,1:ny))
-|      direction = -1
-|      call dfftw_plan_dft_2d(plan, nx, ny, kdistro, kdistro,direction,
-|FFT_ESTIMATE)
-|      call dfftw_execute(plan)
-|      call dfftw_destroy_plan(plan)
-|   end subroutine get
-|end module con
-|--------------------------------------------------
-|
-|ERROR MESSAGE:
-|--------------------------------------------------
-|(idb) run
-|                     0
-|Thread received signal SEGV
-|stopped at [void m1_32_0(const R*, const R*, R*, R*, stride,
-|stride):73 0x0806e2d4]
-|     73 		    T5 = ri[WS(is, 24)];
-|(idb) where
-|>0  0x0806e2d4 in m1_32_0(ri=0xbffff4a0, ii=0xbffff4a8, ro=0xbffff4d0,
-|io=0xbffff4d8, is=0x8179af8, os=0x8179b80) "m1_32.c":73
-|#1  0x08070a17 in m1_32(ri=0xbffff4a0, ii=0xbffff4a8, ro=0xbffff4d0,
-|io=0xbffff4d8, is=0x8179af8, os=0x8179b80, v=8, ivs=2, ovs=64)
-|"m1_32.c":673
-|#2  0x0810fc4d in apply(ego_=0x8179aa0, ri=0xbffff4a0, ii=0xbffff4a8,
-|ro=0xbffff4d0, io=0xbffff4d8) "direct.c":47
-|#3  0x0810ebcd in apply(ego_=0x8179c08, ri=0xbffff4a0, ii=0xbffff4a8,
-|ro=0xbffff4d0, io=0xbffff4d8) "ct-dit.c":34
-|#4  0x08054a34 in apply(ego_=0x8179ec0, ri=0xbfffe4a0, ii=0xbfffe4a8,
-|ro=0xbfffe4d0, io=0xbfffe4d8) "vrank-geq1.c":63
-|#5  0x08054006 in apply(ego_=0x81781e0, ri=0xbfffe4a0, ii=0xbfffe4a8,
-|ro=0xbfffe4d0, io=0xbfffe4d8) "rank-geq2.c":49
-|#6  0x080549a4 in fftw_dft_solve(ego_=0x81781e0, p_=0x8175f70)
-|"solve.c":30
-|#7  0x0804aaaa in dfftw_execute_(p=0xbfffe500) "f77funcs.h":27
-|#8  0x0804a427 in CON::get(distro=(...), nn=(...)) "m_tmp.f90":36
-|#9  0xc07f5967
-|(idb)


Herman D. (Skip) Knoble, Research Associate
(a computing professional for 38 years)
Email: SkipKnobleLESS at SPAMpsu dot edu
Web: http://www.personal.psu.edu/hdk
Penn State Information Technology Services
Academic Services and Emerging Technologies
Graduate Education and Research Services
Penn State University
214C Computer Building
University Park, PA 16802-21013
Phone:+1 814 865-0818   Fax:+1 814 863-7049

Two thoughts.

First, put a "print *, 'we are here'" before and after the
calls to the three dfftw_* routines, then you'll know
which subroutine is the culprit.

Second, I'd worry about passing kdistro to both the
"in" and "out" arguments of dfftw_plan_dft_2d.  The
rules of Fortran don't allow aliased arguments like
these to be changed in the subroutine.  I'd guess
that the "out" argument gets changed.  That's just
against the rules.  I think you need a separate
array for the out argument.

HTH

Dick Hendrickson

Jacek wrote:
> Kamaraju Kusumanchi  wrote in message
> 
>
>
>
> Here is the minimalized version of my program (main and module). It
> raises the same error message as the whole one (error message comes at
> the very end).
>
> Thanks a lot,
> Jacek
>
>
> MAIN:
> ------------------------------------
>    program po
>    use con
>    implicit none
>    real(DP), allocatable :: den(:,:)
>    integer(8) :: nn(1:2)
>    integer(8) :: i,j
>    integer(8) :: allocate_status
>    nn(1:2) = 128
>    allocate(den(1:2*nn(1),1:2*nn(2)), STAT = allocate_status)
>    print*, allocate_status
>    do i=1, 2*nn(1)
>       do j=1, 2*nn(2)
>          den(i,j) = 0.0
>          if (sqrt((i-64.0)**2 + (j-64.0)**2) < 4) den(i,j) = 1.0
>       end do
>    end do
>    ! code seems to fail at the following subroutine:
>    call get(den, nn)
> end program po
> --------------------------------
>
> MODULE:
> ------------------------------------
> module con
>    implicit none
>    integer, parameter :: DP = kind(1.0d0)
>    integer(8), parameter :: FFT_ESTIMATE = 64
> contains
>    subroutine get(distro, nn)
>       implicit none
>       interface
>          subroutine  dfftw_plan_dft_2d(plan,nx,ny,in,out,dir,
FFT_ESTIMATE)
>             integer(8), intent(in) :: plan
>             integer(8), intent(in) :: nx, ny
>             complex(kind(1d0)), intent(inout) :: in(:,:), out(:,:)
>             integer(8), intent(in) :: dir, FFT_ESTIMATE
>          end subroutine dfftw_plan_dft_2d
>          subroutine dfftw_execute(plan)
>             integer(8), intent(in) :: plan
>          end subroutine dfftw_execute
>          subroutine dfftw_destroy_plan(plan)
>             integer(8), intent(in) :: plan
>          end subroutine dfftw_destroy_plan
>       end interface
>       integer(8), intent(in) :: nn(1:2)
>       real(DP), intent(inout) :: distro(1:2*nn(1),1:2*nn(2))
>       complex(DP) :: kdistro(1:2*nn(1),1:2*nn(2))
>       integer(8) :: plan
>       integer(8) :: direction
>       integer(8) :: nx, ny
>       nx = 2*nn(1)
>       ny = 2*nn(2)
>       kdistro(1:nx,1:ny) = cmplx(distro(1:nx,1:ny))
>       direction = -1
>       call dfftw_plan_dft_2d(plan, nx, ny, kdistro, kdistro,direction,
> FFT_ESTIMATE)
>       call dfftw_execute(plan)
>       call dfftw_destroy_plan(plan)
>    end subroutine get
> end module con
> --------------------------------------------------
>
> ERROR MESSAGE:
> --------------------------------------------------
> (idb) run
>                      0
> Thread received signal SEGV
> stopped at [void m1_32_0(const R*, const R*, R*, R*, stride,
> stride):73 0x0806e2d4]
>      73 		    T5 = ri[WS(is, 24)];
> (idb) where
> 
>
> io=0xbffff4d8, is=0x8179af8, os=0x8179b80) "m1_32.c":73
> #1  0x08070a17 in m1_32(ri=0xbffff4a0, ii=0xbffff4a8, ro=0xbffff4d0,
> io=0xbffff4d8, is=0x8179af8, os=0x8179b80, v=8, ivs=2, ovs=64)
> "m1_32.c":673
> #2  0x0810fc4d in apply(ego_=0x8179aa0, ri=0xbffff4a0, ii=0xbffff4a8,
> ro=0xbffff4d0, io=0xbffff4d8) "direct.c":47
> #3  0x0810ebcd in apply(ego_=0x8179c08, ri=0xbffff4a0, ii=0xbffff4a8,
> ro=0xbffff4d0, io=0xbffff4d8) "ct-dit.c":34
> #4  0x08054a34 in apply(ego_=0x8179ec0, ri=0xbfffe4a0, ii=0xbfffe4a8,
> ro=0xbfffe4d0, io=0xbfffe4d8) "vrank-geq1.c":63
> #5  0x08054006 in apply(ego_=0x81781e0, ri=0xbfffe4a0, ii=0xbfffe4a8,
> ro=0xbfffe4d0, io=0xbfffe4d8) "rank-geq2.c":49
> #6  0x080549a4 in fftw_dft_solve(ego_=0x81781e0, p_=0x8175f70)
> "solve.c":30
> #7  0x0804aaaa in dfftw_execute_(p=0xbfffe500) "f77funcs.h":27
> #8  0x0804a427 in CON::get(distro=(...), nn=(...)) "m_tmp.f90":36
> #9  0xc07f5967
> (idb)

Jacek wrote:
> Kamaraju Kusumanchi  wrote in message
>
>
> Here is the minimalized version of my program (main and module). It
> raises the same error message as the whole one (error message comes at
> the very end).
>
> Thanks a lot,
> Jacek
>

I see couple of points which can be improved upon in the code. I have
not tested the new code though...

>
> MAIN:
> ------------------------------------
>    program po
>    use con
>    implicit none
>    real(DP), allocatable :: den(:,:)
>    integer(8) :: nn(1:2)
>    integer(8) :: i,j
>    integer(8) :: allocate_status
>    nn(1:2) = 128
>    allocate(den(1:2*nn(1),1:2*nn(2)), STAT = allocate_status)
>    print*, allocate_status
>    do i=1, 2*nn(1)
>       do j=1, 2*nn(2)
>          den(i,j) = 0.0
>          if (sqrt((i-64.0)**2 + (j-64.0)**2) < 4) den(i,j) = 1.0
>       end do
>    end do
>    ! code seems to fail at the following subroutine:
>    call get(den, nn)
> end program po
> --------------------------------
>
> MODULE:
> ------------------------------------
> module con
>    implicit none
>    integer, parameter :: DP = kind(1.0d0)
>    integer(8), parameter :: FFT_ESTIMATE = 64

Why are you initializing this flag? See pg-25 of fftw manual where it
says to use any one of FFTW_ESTIMATE, FFTW_MEASURE, FFTW_PATIENT,
FFTW_EXHAUSTIVE, FFTW_EXHAUSTIVE

> contains
>    subroutine get(distro, nn)
>       implicit none
>       interface
>          subroutine  dfftw_plan_dft_2d(plan,nx,ny,in,out,dir,
FFT_ESTIMATE)
>             integer(8), intent(in) :: plan
>             integer(8), intent(in) :: nx, ny
>             complex(kind(1d0)), intent(inout) :: in(:,:), out(:,:)
>             integer(8), intent(in) :: dir, FFT_ESTIMATE
>          end subroutine dfftw_plan_dft_2d
>          subroutine dfftw_execute(plan)
>             integer(8), intent(in) :: plan
>          end subroutine dfftw_execute
>          subroutine dfftw_destroy_plan(plan)
>             integer(8), intent(in) :: plan
>          end subroutine dfftw_destroy_plan
>       end interface
>       integer(8), intent(in) :: nn(1:2)
>       real(DP), intent(inout) :: distro(1:2*nn(1),1:2*nn(2))
>       complex(DP) :: kdistro(1:2*nn(1),1:2*nn(2))
>       integer(8) :: plan
>       integer(8) :: direction
>       integer(8) :: nx, ny
>       nx = 2*nn(1)
>       ny = 2*nn(2)
>       kdistro(1:nx,1:ny) = cmplx(distro(1:nx,1:ny))
>       direction = -1

Although this is correct, I prefer to use FFTW_FORWARD and FFTW_BACKWARD
instead -1 or +1 as it makes the code more readable. But that is a
personal preference anyway.



>       call dfftw_plan_dft_2d(plan, nx, ny, kdistro, kdistro,direction,
> FFT_ESTIMATE)
>       call dfftw_execute(plan)

Just a caveat. Creating plan destroys the original data in the
variables. So fftw might not be doing what you intend to do. I
frequently run into this problem and is very tough to realize that it is
the cause of the problem.

>       call dfftw_destroy_plan(plan)
>    end subroutine get
> end module con

Please let us know if you make any progress.

hth
raju

Dick Hendrickson wrote:
> Two thoughts.
>
> First, put a "print *, 'we are here'" before and after the
> calls to the three dfftw_* routines, then you'll know
> which subroutine is the culprit.

From the traceback it seems to be dfftw_execute

> Second, I'd worry about passing kdistro to both the
> "in" and "out" arguments of dfftw_plan_dft_2d.  The
> rules of Fortran don't allow aliased arguments like
> these to be changed in the subroutine.  I'd guess
> that the "out" argument gets changed.  That's just
> against the rules.  I think you need a separate
> array for the out argument.

That would be true if it was a Fortran subroutine, but
it seems to be a C routine.  Also interesting is that
plan is an intent(in) argument to all, and isn't set before
the first one.

It looks like it has some memory of the arguments passed
to the first one, and actually does the FFT on the
dfftw_execute call.  The plan variable is used to keep track
of which one it is doing.  I would expect the first call
to set plan, possibly as a C pointer, and the rest to
use it, but it shouldn't be intent(in) in that case.

glen herrmannsfeldt wrote:
> Dick Hendrickson wrote:
> 
>
>
>  From the traceback it seems to be dfftw_execute
> 
>
>
> That would be true if it was a Fortran subroutine, but
> it seems to be a C routine.
I don't think that matters.  I think the rule is that
aliased arguments can't be changed period, and it doesn't
matter how they are changed.  That allows the
compiler to do a copy IN/OUT, for example, for arrays.
That might be what's happening here, since the dimensions
and the subscripts aren't completely simple.  My rule of
thumb is to usually fix the bugs I know about and hope that
fixes everything.

Dick Hendrickson


Also interesting is that
> plan is an intent(in) argument to all, and isn't set before
> the first one.
>
> It looks like it has some memory of the arguments passed
> to the first one, and actually does the FFT on the
> dfftw_execute call.  The plan variable is used to keep track
> of which one it is doing.  I would expect the first call
> to set plan, possibly as a C pointer, and the rest to
> use it, but it shouldn't be intent(in) in that case.
>

Dick Hendrickson wrote:

> glen herrmannsfeldt wrote:
> 

(snip)
 
 

> I don't think that matters.  I think the rule is that
> aliased arguments can't be changed period, and it doesn't
> matter how they are changed.  That allows the
> compiler to do a copy IN/OUT, for example, for arrays.

In the case of mixing Fortran and C there are many things
that can happen if you don't really know what both are doing.

C doesn't allow copy IN/OUT.  Note, though, that in this
case all the arrays are passed to one routine but the
transform is actually done by the second routine.  I don't
know if that is legal at all in Fortran, but I believe it
is in C.  A C subroutine can keep a pointer to data passed
in a previous call, (or to a call to another routine) and
use it later.   My guess is that plan is a structure pointer
returned by the first call and used by the later calls.

> That might be what's happening here, since the dimensions
> and the subscripts aren't completely simple.

That sounds suspicious to me.  If the called program was
assuming a simple array very strange things could happen.

>  My rule of thumb is to usually fix the bugs I know
> about and hope that fixes everything.

I like this rule, too.

-- glen

>
> Please let us know if you make any progress.
>

Unfortunately it doesn't work yet. I got rid of intent(in) and
intent(out) in specification of a FFW routines interfaces (as someone
suggested) but it didn't help.

The code seems to blow up after:

call dfftw_plan_dft_2d(plan, nx, ny, kdistro, tempo,direction, FFT_ESTIMATE

The question which comes to me is why this code works fine when Portland
Fortran compiler is used instead?

Thanks,
Jacek