g95 and FFTW
in [Fortran]
|
From: Rick on 22 Apr 2010 16:33 I'm using both in-place and out-of-place real-data FFT in the same program, with FFTW3. Something along those lines: DOUBLE PRECISION :: bR(2*(L/2+1),L) DOUBLE PRECISION :: aR(2*(L/2+1),L) DOUBLE COMPLEX :: aC(L/2+1,L) .... CALL dfftw_plan_dft_r2c_2d(plan1, L,L, aR,aC, FFTW_MEASURE) CALL dfftw_plan_dft_r2c_2d(plan2, L,L, bR,bR, FFTW_MEASURE) It works and produces correct results. It compiles with ifort but g95 gives the following warning: Warning (155): Inconsistent types (REAL(8)/COMPLEX(8)) in actual argument lists This is because I'm using the same routine on real/real and real/ complex arrays. However, this is as far as I understand how the routine should be used: "For an in-place transform, in and out are aliased to the same array" (http://www.fftw.org/fftw3_doc/One_002dDimensional-DFTs-of-Real- Data.html) How could I solve this? How am I supposed to use a C routine with different argument types? I suspect this could be related to some bug that happens later in the software, and would like to at least clear this point...
From: Rick on 23 Apr 2010 05:22 Thanks for your answer. The only small problem with this is that when compiling, many warning lines are displayed which means that one should use the scroll bar in order to see the previous shell commands (which is usually useful when you compile and restart the program). But it's a very minor thing. I was wondering if there was a nice way to get ride of those warnings, but I'm happy enough to know that there isn't necessarily. On Apr 23, 1:40 am, nos...(a)see.signature (Richard Maine) wrote: > Rick <fernan...(a)gmail.com> wrote: > > I'm using both in-place and out-of-place real-data FFT in the same > > program, with FFTW3. > ... > > It works and produces correct results. It compiles with ifort but g95 > > gives the following warning: > > > Warning (155): Inconsistent types (REAL(8)/COMPLEX(8)) in actual > > argument lists > > > This is because I'm using the same routine on real/real and real/ complex > > arrays. However, this is as far as I understand how the routine should be > > used:... > > How could I solve this? > > Solve what? If that is how the routine is supposed to be used, and it is > working and producing correct results, then what is there to solve? Note > that the warning is just that - a warning. Warnings are not necessarily > errors and do not indicate that the code won't work. They just indicate > something strange enough to merit looking at. Sounds like you have > looked at it. > > Strictly speaking it isn't standard conforming to have such a type > disagreement in a call. (I haven't looked at the code in fftw3, but it > can't be of both types). Yes, it will almost certainly work, but it > isn't strictly standard conforming, which is why the warning. > > You could probably make it standard conforming and shut up the warning > by using an equivalence (only if the arrays are static, though, as you > can't equivalence dynamically allocated things). Or you could use > various tricks that hide the issue from the compiler, but don't actually > address anything about the underlying issue. I don't much see the > benefit, though. > > > How am I supposed to use a C routine with different argument types? > > Different from what? I assume from context that you must mean with > actual argument types different from the dummy argument types (or the > comparable things in C-speak). You aren't "supposed" to do that at all, > regardless of whether it is C, Fortran, or a mixture. In practice, it > will almost surely work in this case. > > The more general answer for C usually involves void pointers, which you > can interoperate with using Fortran's CPTR type (in f2003, but it should > be in most f95 compilers by now, including those two). > > > I suspect this could be related to some bug that happens later in the > > software, > > I doubt it, as long as you have verified that this is how the routine is > documented to work. > > -- > Richard Maine | Good judgment comes from experience; > email: last name at domain . net | experience comes from bad judgment. > domain: summertriangle | -- Mark Twain
From: Arjen Markus on 23 Apr 2010 09:42 On 23 apr, 11:22, Rick <fernan...(a)gmail.com> wrote: > Thanks for your answer. > > The only small problem with this is that when compiling, many warning > lines are displayed which means that one should use the scroll bar in > order to see the previous shell commands (which is usually useful when > you compile and restart the program). But it's a very minor thing. I > was wondering if there was a nice way to get ride of those warnings, > but I'm happy enough to know that there isn't necessarily. > > On Apr 23, 1:40 am, nos...(a)see.signature (Richard Maine) wrote: > > > > > Rick <fernan...(a)gmail.com> wrote: > > > I'm using both in-place and out-of-place real-data FFT in the same > > > program, with FFTW3. > > ... > > > It works and produces correct results. It compiles with ifort but g95 > > > gives the following warning: > > > > Warning (155): Inconsistent types (REAL(8)/COMPLEX(8)) in actual > > > argument lists > > > > This is because I'm using the same routine on real/real and real/ complex > > > arrays. However, this is as far as I understand how the routine should be > > > used:... > > > How could I solve this? > > > Solve what? If that is how the routine is supposed to be used, and it is > > working and producing correct results, then what is there to solve? Note > > that the warning is just that - a warning. Warnings are not necessarily > > errors and do not indicate that the code won't work. They just indicate > > something strange enough to merit looking at. Sounds like you have > > looked at it. > > > Strictly speaking it isn't standard conforming to have such a type > > disagreement in a call. (I haven't looked at the code in fftw3, but it > > can't be of both types). Yes, it will almost certainly work, but it > > isn't strictly standard conforming, which is why the warning. > > > You could probably make it standard conforming and shut up the warning > > by using an equivalence (only if the arrays are static, though, as you > > can't equivalence dynamically allocated things). Or you could use > > various tricks that hide the issue from the compiler, but don't actually > > address anything about the underlying issue. I don't much see the > > benefit, though. > > > > How am I supposed to use a C routine with different argument types? > > > Different from what? I assume from context that you must mean with > > actual argument types different from the dummy argument types (or the > > comparable things in C-speak). You aren't "supposed" to do that at all, > > regardless of whether it is C, Fortran, or a mixture. In practice, it > > will almost surely work in this case. > > > The more general answer for C usually involves void pointers, which you > > can interoperate with using Fortran's CPTR type (in f2003, but it should > > be in most f95 compilers by now, including those two). > > > > I suspect this could be related to some bug that happens later in the > > > software, > > > I doubt it, as long as you have verified that this is how the routine is > > documented to work. > > > -- > > Richard Maine | Good judgment comes from experience; > > email: last name at domain . net | experience comes from bad judgment. > > domain: summertriangle | -- Mark Twain- Tekst uit oorspronkelijk bericht niet weergeven - > > - Tekst uit oorspronkelijk bericht weergeven - I think it is possible, but it will involve some trickery with modules and interfaces. And possibly iso_c_bindings. What it boils down to is: - Make an interface specific for each type of call (even though it is to the same C routine) - in separate modules - Join all these separate interfaces so that the compiler is seeing a generic name I have not tried it and perhaps you need to rename the C routine, but I think it will work. Regards, Arjen
From: Richard Maine on 22 Apr 2010 19:40 Rick <fernand31(a)gmail.com> wrote: > I'm using both in-place and out-of-place real-data FFT in the same > program, with FFTW3. .... > It works and produces correct results. It compiles with ifort but g95 > gives the following warning: > > Warning (155): Inconsistent types (REAL(8)/COMPLEX(8)) in actual > argument lists > > This is because I'm using the same routine on real/real and real/ complex > arrays. However, this is as far as I understand how the routine should be > used:... > How could I solve this? Solve what? If that is how the routine is supposed to be used, and it is working and producing correct results, then what is there to solve? Note that the warning is just that - a warning. Warnings are not necessarily errors and do not indicate that the code won't work. They just indicate something strange enough to merit looking at. Sounds like you have looked at it. Strictly speaking it isn't standard conforming to have such a type disagreement in a call. (I haven't looked at the code in fftw3, but it can't be of both types). Yes, it will almost certainly work, but it isn't strictly standard conforming, which is why the warning. You could probably make it standard conforming and shut up the warning by using an equivalence (only if the arrays are static, though, as you can't equivalence dynamically allocated things). Or you could use various tricks that hide the issue from the compiler, but don't actually address anything about the underlying issue. I don't much see the benefit, though. > How am I supposed to use a C routine with different argument types? Different from what? I assume from context that you must mean with actual argument types different from the dummy argument types (or the comparable things in C-speak). You aren't "supposed" to do that at all, regardless of whether it is C, Fortran, or a mixture. In practice, it will almost surely work in this case. The more general answer for C usually involves void pointers, which you can interoperate with using Fortran's CPTR type (in f2003, but it should be in most f95 compilers by now, including those two). > I suspect this could be related to some bug that happens later in the > software, I doubt it, as long as you have verified that this is how the routine is documented to work. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Louis Krupp on 25 Apr 2010 00:25
Rick wrote: <snip> > The only small problem with this is that when compiling, many warning > lines are displayed which means that one should use the scroll bar in > order to see the previous shell commands (which is usually useful when > you compile and restart the program). But it's a very minor thing. I > was wondering if there was a nice way to get ride of those warnings, > but I'm happy enough to know that there isn't necessarily. <snip> My personal opinion is that it's a good idea to get rid of the warnings if it's at all practical. At my current place of employment, warnings in C and C++ (people laugh at me when I mention Fortran, while I read this group out of interest) are treated as errors which have to be fixed. I think it's a good thing; if only because it's nice not to have to wade through a bunch of messages about harmless issues in order to find warnings that might actually flag real problems. This may or may not apply to Fortran and its current compilers. Louis |