annotate Lib/fftw-3.2.1/doc/html/.svn/text-base/Upgrading-from-FFTW-version-2.html.svn-base @ 0:25bf17994ef1

First commit. VS2013, Codeblocks and Mac OSX configuration
author Geogaddi\David <d.m.ronan@qmul.ac.uk>
date Thu, 09 Jul 2015 01:12:16 +0100
parents
children
rev   line source
d@0 1 <html lang="en">
d@0 2 <head>
d@0 3 <title>Upgrading from FFTW version 2 - FFTW 3.2.1</title>
d@0 4 <meta http-equiv="Content-Type" content="text/html">
d@0 5 <meta name="description" content="FFTW 3.2.1">
d@0 6 <meta name="generator" content="makeinfo 4.8">
d@0 7 <link title="Top" rel="start" href="index.html#Top">
d@0 8 <link rel="prev" href="Calling-FFTW-from-Fortran.html#Calling-FFTW-from-Fortran" title="Calling FFTW from Fortran">
d@0 9 <link rel="next" href="Installation-and-Customization.html#Installation-and-Customization" title="Installation and Customization">
d@0 10 <link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
d@0 11 <!--
d@0 12 This manual is for FFTW
d@0 13 (version 3.2.1, 5 February 2009).
d@0 14
d@0 15 Copyright (C) 2003 Matteo Frigo.
d@0 16
d@0 17 Copyright (C) 2003 Massachusetts Institute of Technology.
d@0 18
d@0 19 Permission is granted to make and distribute verbatim copies of
d@0 20 this manual provided the copyright notice and this permission
d@0 21 notice are preserved on all copies.
d@0 22
d@0 23 Permission is granted to copy and distribute modified versions of
d@0 24 this manual under the conditions for verbatim copying, provided
d@0 25 that the entire resulting derived work is distributed under the
d@0 26 terms of a permission notice identical to this one.
d@0 27
d@0 28 Permission is granted to copy and distribute translations of this
d@0 29 manual into another language, under the above conditions for
d@0 30 modified versions, except that this permission notice may be
d@0 31 stated in a translation approved by the Free Software Foundation.
d@0 32 -->
d@0 33 <meta http-equiv="Content-Style-Type" content="text/css">
d@0 34 <style type="text/css"><!--
d@0 35 pre.display { font-family:inherit }
d@0 36 pre.format { font-family:inherit }
d@0 37 pre.smalldisplay { font-family:inherit; font-size:smaller }
d@0 38 pre.smallformat { font-family:inherit; font-size:smaller }
d@0 39 pre.smallexample { font-size:smaller }
d@0 40 pre.smalllisp { font-size:smaller }
d@0 41 span.sc { font-variant:small-caps }
d@0 42 span.roman { font-family:serif; font-weight:normal; }
d@0 43 span.sansserif { font-family:sans-serif; font-weight:normal; }
d@0 44 --></style>
d@0 45 </head>
d@0 46 <body>
d@0 47 <div class="node">
d@0 48 <p>
d@0 49 <a name="Upgrading-from-FFTW-version-2"></a>
d@0 50 Next:&nbsp;<a rel="next" accesskey="n" href="Installation-and-Customization.html#Installation-and-Customization">Installation and Customization</a>,
d@0 51 Previous:&nbsp;<a rel="previous" accesskey="p" href="Calling-FFTW-from-Fortran.html#Calling-FFTW-from-Fortran">Calling FFTW from Fortran</a>,
d@0 52 Up:&nbsp;<a rel="up" accesskey="u" href="index.html#Top">Top</a>
d@0 53 <hr>
d@0 54 </div>
d@0 55
d@0 56 <h2 class="chapter">8 Upgrading from FFTW version 2</h2>
d@0 57
d@0 58 <p>In this chapter, we outline the process for updating codes designed for
d@0 59 the older FFTW 2 interface to work with FFTW 3. The interface for FFTW
d@0 60 3 is not backwards-compatible with the interface for FFTW 2 and earlier
d@0 61 versions; codes written to use those versions will fail to link with
d@0 62 FFTW 3. Nor is it possible to write &ldquo;compatibility wrappers&rdquo; to
d@0 63 bridge the gap (at least not efficiently), because FFTW 3 has different
d@0 64 semantics from previous versions. However, upgrading should be a
d@0 65 straightforward process because the data formats are identical and the
d@0 66 overall style of planning/execution is essentially the same.
d@0 67
d@0 68 <p>Unlike FFTW 2, there are no separate header files for real and complex
d@0 69 transforms (or even for different precisions) in FFTW 3; all interfaces
d@0 70 are defined in the <code>&lt;fftw3.h&gt;</code> header file.
d@0 71
d@0 72 <h3 class="heading">Numeric Types</h3>
d@0 73
d@0 74 <p>The main difference in data types is that <code>fftw_complex</code> in FFTW 2
d@0 75 was defined as a <code>struct</code> with macros <code>c_re</code> and <code>c_im</code>
d@0 76 for accessing the real/imaginary parts. (This is binary-compatible with
d@0 77 FFTW 3 on any machine except perhaps for some older Crays in single
d@0 78 precision.) The equivalent macros for FFTW 3 are:
d@0 79
d@0 80 <pre class="example"> #define c_re(c) ((c)[0])
d@0 81 #define c_im(c) ((c)[1])
d@0 82 </pre>
d@0 83 <p>This does not work if you are using the C99 complex type, however,
d@0 84 unless you insert a <code>double*</code> typecast into the above macros
d@0 85 (see <a href="Complex-numbers.html#Complex-numbers">Complex numbers</a>).
d@0 86
d@0 87 <p>Also, FFTW 2 had an <code>fftw_real</code> typedef that was an alias for
d@0 88 <code>double</code> (in double precision). In FFTW 3 you should just use
d@0 89 <code>double</code> (or whatever precision you are employing).
d@0 90
d@0 91 <h3 class="heading">Plans</h3>
d@0 92
d@0 93 <p>The major difference between FFTW 2 and FFTW 3 is in the
d@0 94 planning/execution division of labor. In FFTW 2, plans were found for a
d@0 95 given transform size and type, and then could be applied to <em>any</em>
d@0 96 arrays and for <em>any</em> multiplicity/stride parameters. In FFTW 3,
d@0 97 you specify the particular arrays, stride parameters, etcetera when
d@0 98 creating the plan, and the plan is then executed for <em>those</em> arrays
d@0 99 (unless the guru interface is used) and <em>those</em> parameters
d@0 100 <em>only</em>. (FFTW 2 had &ldquo;specific planner&rdquo; routines that planned for
d@0 101 a particular array and stride, but the plan could still be used for
d@0 102 other arrays and strides.) That is, much of the information that was
d@0 103 formerly specified at execution time is now specified at planning time.
d@0 104
d@0 105 <p>Like FFTW 2's specific planner routines, the FFTW 3 planner overwrites
d@0 106 the input/output arrays unless you use <code>FFTW_ESTIMATE</code>.
d@0 107
d@0 108 <p>FFTW 2 had separate data types <code>fftw_plan</code>, <code>fftwnd_plan</code>,
d@0 109 <code>rfftw_plan</code>, and <code>rfftwnd_plan</code> for complex and real one- and
d@0 110 multi-dimensional transforms, and each type had its own `<samp><span class="samp">destroy</span></samp>'
d@0 111 function. In FFTW 3, all plans are of type <code>fftw_plan</code> and all are
d@0 112 destroyed by <code>fftw_destroy_plan(plan)</code>.
d@0 113
d@0 114 <p>Where you formerly used <code>fftw_create_plan</code> and <code>fftw_one</code> to
d@0 115 plan and compute a single 1d transform, you would now use
d@0 116 <code>fftw_plan_dft_1d</code> to plan the transform. If you used the generic
d@0 117 <code>fftw</code> function to execute the transform with multiplicity
d@0 118 (<code>howmany</code>) and stride parameters, you would now use the advanced
d@0 119 interface <code>fftw_plan_many_dft</code> to specify those parameters. The
d@0 120 plans are now executed with <code>fftw_execute(plan)</code>, which takes all
d@0 121 of its parameters (including the input/output arrays) from the plan.
d@0 122
d@0 123 <p>In-place transforms no longer interpret their output argument as scratch
d@0 124 space, nor is there an <code>FFTW_IN_PLACE</code> flag. You simply pass the
d@0 125 same pointer for both the input and output arguments. (Previously, the
d@0 126 output <code>ostride</code> and <code>odist</code> parameters were ignored for
d@0 127 in-place transforms; now, if they are specified via the advanced
d@0 128 interface, they are significant even in the in-place case, although they
d@0 129 should normally equal the corresponding input parameters.)
d@0 130
d@0 131 <p>The <code>FFTW_ESTIMATE</code> and <code>FFTW_MEASURE</code> flags have the same
d@0 132 meaning as before, although the planning time will differ. You may also
d@0 133 consider using <code>FFTW_PATIENT</code>, which is like <code>FFTW_MEASURE</code>
d@0 134 except that it takes more time in order to consider a wider variety of
d@0 135 algorithms.
d@0 136
d@0 137 <p>For multi-dimensional complex DFTs, instead of <code>fftwnd_create_plan</code>
d@0 138 (or <code>fftw2d_create_plan</code> or <code>fftw3d_create_plan</code>), followed by
d@0 139 <code>fftwnd_one</code>, you would use <code>fftw_plan_dft</code> (or
d@0 140 <code>fftw_plan_dft_2d</code> or <code>fftw_plan_dft_3d</code>). followed by
d@0 141 <code>fftw_execute</code>. If you used <code>fftwnd</code> to to specify strides
d@0 142 etcetera, you would instead specify these via <code>fftw_plan_many_dft</code>.
d@0 143
d@0 144 <p>The analogues to <code>rfftw_create_plan</code> and <code>rfftw_one</code> with
d@0 145 <code>FFTW_REAL_TO_COMPLEX</code> or <code>FFTW_COMPLEX_TO_REAL</code> directions
d@0 146 are <code>fftw_plan_r2r_1d</code> with kind <code>FFTW_R2HC</code> or
d@0 147 <code>FFTW_HC2R</code>, followed by <code>fftw_execute</code>. The stride etcetera
d@0 148 arguments of <code>rfftw</code> are now in <code>fftw_plan_many_r2r</code>.
d@0 149
d@0 150 <p>Instead of <code>rfftwnd_create_plan</code> (or <code>rfftw2d_create_plan</code> or
d@0 151 <code>rfftw3d_create_plan</code>) followed by
d@0 152 <code>rfftwnd_one_real_to_complex</code> or
d@0 153 <code>rfftwnd_one_complex_to_real</code>, you now use <code>fftw_plan_dft_r2c</code>
d@0 154 (or <code>fftw_plan_dft_r2c_2d</code> or <code>fftw_plan_dft_r2c_3d</code>) or
d@0 155 <code>fftw_plan_dft_c2r</code> (or <code>fftw_plan_dft_c2r_2d</code> or
d@0 156 <code>fftw_plan_dft_c2r_3d</code>), respectively, followed by
d@0 157 <code>fftw_execute</code>. As usual, the strides etcetera of
d@0 158 <code>rfftwnd_real_to_complex</code> or <code>rfftwnd_complex_to_real</code> are no
d@0 159 specified in the advanced planner routines,
d@0 160 <code>fftw_plan_many_dft_r2c</code> or <code>fftw_plan_many_dft_c2r</code>.
d@0 161
d@0 162 <h3 class="heading">Wisdom</h3>
d@0 163
d@0 164 <p>In FFTW 2, you had to supply the <code>FFTW_USE_WISDOM</code> flag in order to
d@0 165 use wisdom; in FFTW 3, wisdom is always used. (You could simulate the
d@0 166 FFTW 2 wisdom-less behavior by calling <code>fftw_forget_wisdom</code> after
d@0 167 every planner call.)
d@0 168
d@0 169 <p>The FFTW 3 wisdom import/export routines are almost the same as before
d@0 170 (although the storage format is entirely different). There is one
d@0 171 significant difference, however. In FFTW 2, the import routines would
d@0 172 never read past the end of the wisdom, so you could store extra data
d@0 173 beyond the wisdom in the same file, for example. In FFTW 3, the
d@0 174 file-import routine may read up to a few hundred bytes past the end of
d@0 175 the wisdom, so you cannot store other data just beyond it.<a rel="footnote" href="#fn-1" name="fnd-1"><sup>1</sup></a>
d@0 176
d@0 177 <p>Wisdom has been enhanced by additional humility in FFTW 3: whereas FFTW
d@0 178 2 would re-use wisdom for a given transform size regardless of the
d@0 179 stride etc., in FFTW 3 wisdom is only used with the strides etc. for
d@0 180 which it was created. Unfortunately, this means FFTW 3 has to create
d@0 181 new plans from scratch more often than FFTW 2 (in FFTW 2, planning
d@0 182 e.g. one transform of size 1024 also created wisdom for all smaller
d@0 183 powers of 2, but this no longer occurs).
d@0 184
d@0 185 <p>FFTW 3 also has the new routine <code>fftw_import_system_wisdom</code> to
d@0 186 import wisdom from a standard system-wide location.
d@0 187
d@0 188 <h3 class="heading">Memory allocation</h3>
d@0 189
d@0 190 <p>In FFTW 3, we recommend allocating your arrays with <code>fftw_malloc</code>
d@0 191 and deallocating them with <code>fftw_free</code>; this is not required, but
d@0 192 allows optimal performance when SIMD acceleration is used. (Those two
d@0 193 functions actually existed in FFTW 2, and worked the same way, but were
d@0 194 not documented.)
d@0 195
d@0 196 <p>In FFTW 2, there were <code>fftw_malloc_hook</code> and <code>fftw_free_hook</code>
d@0 197 functions that allowed the user to replace FFTW's memory-allocation
d@0 198 routines (e.g. to implement different error-handling, since by default
d@0 199 FFTW prints an error message and calls <code>exit</code> to abort the program
d@0 200 if <code>malloc</code> returns <code>NULL</code>). These hooks are not supported in
d@0 201 FFTW 3; those few users who require this functionality can just
d@0 202 directly modify the memory-allocation routines in FFTW (they are defined
d@0 203 in <code>kernel/alloc.c</code>).
d@0 204
d@0 205 <h3 class="heading">Fortran interface</h3>
d@0 206
d@0 207 <p>In FFTW 2, the subroutine names were obtained by replacing `<samp><span class="samp">fftw_</span></samp>'
d@0 208 with `<samp><span class="samp">fftw_f77</span></samp>'; in FFTW 3, you replace `<samp><span class="samp">fftw_</span></samp>' with
d@0 209 `<samp><span class="samp">dfftw_</span></samp>' (or `<samp><span class="samp">sfftw_</span></samp>' or `<samp><span class="samp">lfftw_</span></samp>', depending upon the
d@0 210 precision).
d@0 211
d@0 212 <p>In FFTW 3, we have begun recommending that you always declare the type
d@0 213 used to store plans as <code>integer*8</code>. (Too many people didn't notice
d@0 214 our instruction to switch from <code>integer</code> to <code>integer*8</code> for
d@0 215 64-bit machines.)
d@0 216
d@0 217 <p>In FFTW 3, we provide a <code>fftw3.f</code> &ldquo;header file&rdquo; to include in
d@0 218 your code (and which is officially installed on Unix systems). (In FFTW
d@0 219 2, we supplied a <code>fftw_f77.i</code> file, but it was not installed.)
d@0 220
d@0 221 <p>Otherwise, the C-Fortran interface relationship is much the same as it
d@0 222 was before (e.g. return values become initial parameters, and
d@0 223 multi-dimensional arrays are in column-major order). Unlike FFTW 2, we
d@0 224 do provide some support for wisdom import/export in Fortran
d@0 225 (see <a href="Wisdom-of-Fortran_003f.html#Wisdom-of-Fortran_003f">Wisdom of Fortran?</a>).
d@0 226
d@0 227 <h3 class="heading">Threads</h3>
d@0 228
d@0 229 <p>Like FFTW 2, only the execution routines are thread-safe. All planner
d@0 230 routines, etcetera, should be called by only a single thread at a time
d@0 231 (see <a href="Thread-safety.html#Thread-safety">Thread safety</a>). <em>Unlike</em> FFTW 2, there is no special
d@0 232 <code>FFTW_THREADSAFE</code> flag for the planner to allow a given plan to be
d@0 233 usable by multiple threads in parallel; this is now the case by default.
d@0 234
d@0 235 <p>The multi-threaded version of FFTW 2 required you to pass the number of
d@0 236 threads each time you execute the transform. The number of threads is
d@0 237 now stored in the plan, and is specified before the planner is called by
d@0 238 <code>fftw_plan_with_nthreads</code>. The threads initialization routine used
d@0 239 to be called <code>fftw_threads_init</code> and would return zero on success;
d@0 240 the new routine is called <code>fftw_init_threads</code> and returns zero on
d@0 241 failure. See <a href="Multi_002dthreaded-FFTW.html#Multi_002dthreaded-FFTW">Multi-threaded FFTW</a>.
d@0 242
d@0 243 <p>There is no separate threads header file in FFTW 3; all the function
d@0 244 prototypes are in <code>&lt;fftw3.h&gt;</code>. However, you still have to link to
d@0 245 a separate library (<code>-lfftw3_threads -lfftw3 -lm</code> on Unix), as well as
d@0 246 to the threading library (e.g. POSIX threads on Unix).
d@0 247
d@0 248 <!-- ************************************************************ -->
d@0 249 <div class="footnote">
d@0 250 <hr>
d@0 251 <h4>Footnotes</h4><p class="footnote"><small>[<a name="fn-1" href="#fnd-1">1</a>]</small> We
d@0 252 do our own buffering because GNU libc I/O routines are horribly slow for
d@0 253 single-character I/O, apparently for thread-safety reasons (whether you
d@0 254 are using threads or not).</p>
d@0 255
d@0 256 <p><hr></div>
d@0 257
d@0 258 </body></html>
d@0 259