FFTW and Subroutines, copying arrays
in [Fortran]
|
From: Ralph Kube on 4 Nov 2009 06:31 Hello everybody, I am using FFTW with fortran and wonder about the way I have to pass arrays to subroutines. In every subroutine I use FFTW in, I have to locally declare the array fftw stores the array in. If I use an array passed to the subroutine as the target for the fftw routine, my program crashes. Here is an example: subroutine thetaeq(theta, strmf, thrhshat, planfw) include 'resol.h' double precision theta(0:My+1, 0:Nx+1) double precision strmf(0:My+1, 0:Nx+1) double complex thrhshat(0:My/2+1, 0:Nx+1) integer*8 planfw double precision akw(0:My+1, 0:Nx+1) double complex akwhat(0:My/2+1, 0:Nx+1) call arakw(theta, strmf, akw) call dfftw_execute_dft_r2c(planfw, akw, akwhat) thrhshat = akwhat end subroutine The routine dfftw_execute_dft_r2c stores the result in akwhat. Is there any way I can store the result in thrhshat so that I can ommit copying the array? Cheers, Ralph
From: dpb on 4 Nov 2009 08:51 Ralph Kube wrote: > Hello everybody, > I am using FFTW with fortran and wonder about the way I have to pass > arrays to subroutines. In every subroutine I use FFTW in, I have > to locally declare the array fftw stores the array in. If I use an array > passed to the subroutine as the target for the fftw routine, my > program crashes. > Here is an example: > > subroutine thetaeq(theta, strmf, thrhshat, planfw) > include 'resol.h' > double precision theta(0:My+1, 0:Nx+1) > double precision strmf(0:My+1, 0:Nx+1) > double complex thrhshat(0:My/2+1, 0:Nx+1) > integer*8 planfw > > double precision akw(0:My+1, 0:Nx+1) > double complex akwhat(0:My/2+1, 0:Nx+1) > > call arakw(theta, strmf, akw) > call dfftw_execute_dft_r2c(planfw, akw, akwhat) > thrhshat = akwhat > end subroutine > > The routine dfftw_execute_dft_r2c stores the result in akwhat. Is there > any way I can store the result in thrhshat so that I can ommit copying > the array? .... In the code as shown here, sure... call dfftw_execute_dft_r2c(planfw, akw, thrhshat) --
From: Ralph Kube on 4 Nov 2009 09:44 dpb wrote: > In the code as shown here, sure... > > call dfftw_execute_dft_r2c(planfw, akw, thrhshat) This is the call to the fftw subroutine that gives me a headache. When I pass an array defined in the same subroutine to it, it works okay. But when I pass an array, that has been passed to the subroutine where I call dfftw_execute_dft_r2c, it segfaults. Any ideas what causes this behaviour and how I can avoid declaring an extra array? Cheers, Ralph
From: steve on 4 Nov 2009 10:15 On Nov 4, 6:44 am, Ralph Kube <rku...(a)post.uit.no> wrote: > dpb wrote: > > In the code as shown here, sure... > > > call dfftw_execute_dft_r2c(planfw, akw, thrhshat) > > This is the call to the fftw subroutine that gives me a headache. When > I pass an array defined in the same subroutine to it, it works okay. > But when I pass an array, that has been passed to the subroutine where > I call dfftw_execute_dft_r2c, it segfaults. > > Any ideas what causes this behaviour and how I can avoid declaring > an extra array? Probably an array index is out of bounds. Most compilers have a debugging feature to check for this. -- steve
From: Richard Maine on 4 Nov 2009 10:31
Ralph Kube <rku000(a)post.uit.no> wrote: > dpb wrote: > > In the code as shown here, sure... > > > > call dfftw_execute_dft_r2c(planfw, akw, thrhshat) > > This is the call to the fftw subroutine that gives me a headache. When > I pass an array defined in the same subroutine to it, it works okay. > But when I pass an array, that has been passed to the subroutine where > I call dfftw_execute_dft_r2c, it segfaults. The odds of that actually being the problem are negligable. You haven't shown sufficient information to deduce what the actual problem is. More likely is that there is something wrong with the way that you passed the array between your subroutines - but you haven't shown that. Good candidates include disagreements between actual and dummy arguments, including disagreements as to shape. Speaking of shape, you haven't shown where Nx and My come from. Presumably they must have come in somehow via the include, or this code couldn't have compiled, but that tells almost nothing. I'd say that this was a classic case of the most single common error made in posting questions here - you have made a guess as to what the nature of the problem is andthen given only the data related to that guess. If your guess is wrong, then it isn't the right data to diagnose the problem. Since posting a question here tends to mean that you don't know the answer, it also comes with a high probability that the reason you can't find the answer is that you are looking in the wrong place. If you just show us that place, and the real problem is elsewhere, we won't be able to see it either. Ideal, since you are talking about a run-time error, would be a small, self-contained, runable example. Lacking that, it at least needs more information than this. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |