[Insight-developers] USE_FFTWF and USE_FFTWD and Exlicit Instantiation

[Gaëtan Lehmann]

Le Fri, 25 Aug 2006 17:19:06 +0200, Kent Williams  
<kent at psychiatry.uiowa.edu> a écrit:

> You can do this, but you need to check to make sure the build works even  
> if FFTW is not configured in, and if only the double or single precision  
> versions of the FFTW libraries are built.

That's already what is done. Without that, build would also fail.
The difference is the error message, and I think it is currently a little  
much clear than before: the user was including the FFTW classes but  
nothing was defined in it without USE_FFTW?, so he had to search in the  
code what to do; now the filter type are defined even without USE_FFTW?,  
but the build is still failing for a non obvious reason - the user still  
has to read the code to get what is wrong.
If the #if block is no there, then he will get an error message telling  
him that such or such method from fftw is not declared, or a link error  
with undefined symbols from fftw. It looks better for me, really

>
> Would it work to move the implementation of the proxy classes to  
> separate CXX files, that are included or excluded by CMake?  The main  
> reason for the ifdefs is to not include calls to function libraries that  
> don't exist in the current configuration.

Yes, it should work, but look complex for a small gain - see above

>
> I'm sorry this has been a thorn in your side. It wouldn't be a problem  
> if FFTW wasn't set up in such a crazy fashion.
>
> Gaëtan Lehmann wrote:
>
>>
>> Hi,
>>
>> I have tried to wrap those classes, and I'm still stopped by the #if   
>> defined(...) blocks.
>> Is it a problem for someone if I remove them ? I really can't  
>> understand  how they can help the user to not make some mistake.
>>
>> thanks,
>>
>> Gaetan
>>
>>
>> Le Thu, 24 Aug 2006 20:29:56 +0200, Kent Williams   
>> <kent at psychiatry.uiowa.edu> a écrit:
>>
>>> I spent some time this morning looking at the itkFFTDirectInverse2  
>>> test  and frankly I was baffled.
>>>
>>> This test makes a new file by going from image->fft->ifft->image, and   
>>> then comparing the input image with the output image.  I looked at  
>>> both  images in the Gimp, and they appear to be exactly the same --  
>>> pixel 0,0  == 255, everything else 0.  But the test fixture main()  
>>> (in  itkTestMain.h) compares the two files, and says they're  
>>> different. I  don't know who to believe -- the test fixture or my  
>>> lying eyes?
>>>
>>> Gaëtan Lehmann wrote:
>>>
>>>>
>>>> It doesn't segfault anymore :-)
>>>> http://www.itk.org/Testing/Sites/marvin.jouy.inra.fr/Mandriva2006.0-i586-gcc4.0.1-ExplicitInstantiation-Debug/20060823-1723-Experimental/Test.html   
>>>> There is still a problem with one test, but I'm not sure that's  
>>>> related  to  your changes. It's surely better to wait for the tests  
>>>> of the  other  testing hosts.
>>>>
>>>> I will look at wrapping those modified classes now. It should be  
>>>> much  easy  :-)
>>>>
>>>> Thanks,
>>>>
>>>> Gaetan
>>>>
>>>> Le Wed, 23 Aug 2006 18:35:28 +0200, Kent Williams    
>>>> <kent at psychiatry.uiowa.edu> a écrit:
>>>>
>>>>> I discovered and corrected this error. Thanks for pointing it out!  
>>>>> I   didn't set the first element of the index for the output image  
>>>>> region;  I  don't know why this didn't break tests before, other  
>>>>> than the  usual:  happenstance in memory layout, dumb luck, etc.
>>>>>
>>>>> Gaetan Lehmann wrote:
>>>>>
>>>>>> On Tue, 22 Aug 2006 16:15:29 +0200, Kent Williams     
>>>>>> <kent at psychiatry.uiowa.edu> wrote:
>>>>>>
>>>>>>> Sorry about this problem -- It passed local regression tests, but   
>>>>>>> we   don't build the double-precision FFTW by default, so I  
>>>>>>> missed  the   problems in the double precision version of the  
>>>>>>> proxy class.  Thanks  for  fixing it Luis.
>>>>>>>
>>>>>>> The only way I know of to always test this code is to always  
>>>>>>> build   both  single and double precision FFTW libraries on the  
>>>>>>> testing   machines.   This isn't a big deal, since FFTW changes  
>>>>>>> only once in  a  great while.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Kent,
>>>>>>
>>>>>> That's nice to have it build, but there is still lots of problems   
>>>>>> with   those filters. I tried to trace the errors, but fixing them  
>>>>>> is  not in  my  capabilities :-(
>>>>>> Can you have a look at them ?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Gaetan
>>>>>>
>>>>>>
>>>>>> [glehmann at marvin build-debug]$ ctest -R FFT
>>>>>> Start processing tests
>>>>>> Test project
>>>>>> 719/1092 Testing itkVnlFFTTest                    Passed
>>>>>> 720/1092 Testing itkFFTWF_FFTTest              ***Exception:  
>>>>>> SegFault
>>>>>> 721/1092 Testing itkFFTWD_FFTTest              ***Exception:  
>>>>>> SegFault
>>>>>> 996/1092 Testing FFTImageFilterTest               Passed
>>>>>> 997/1092 Testing FFTDirectInverse2Test         ***Failed
>>>>>> 998/1092 Testing FFTImageFilterTest2              Passed
>>>>>> 999/1092 Testing FFTImageFilterTest3              Passed
>>>>>>
>>>>>> 57% tests passed, 3 tests failed out of 7
>>>>>>
>>>>>> The following tests FAILED:
>>>>>>         720 - itkFFTWF_FFTTest (SEGFAULT)
>>>>>>         721 - itkFFTWD_FFTTest (SEGFAULT)
>>>>>>         997 - FFTDirectInverse2Test (Failed)
>>>>>> Errors while running CTest
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>



-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr