[gmx-developers] Error configuring 5.0.5 with GMX_BUILD_OWN_FFTW=yes

Thu May 14 12:06:31 CEST 2015

Hi,

On Wed, May 13, 2015 at 10:50 PM Berk Hess <hess at kth.se> wrote:

> On 05/13/2015 10:43 PM, Mark Abraham wrote:
>
>
>
> On Wed, May 13, 2015 at 10:24 PM Berk Hess <hess at kth.se> wrote:
>
>>  Hi,
>>
>> I also noticed only now that there is more logic on line 158 of
>> FindFFTW.cmake that probably should have been updated (as well as the
>> documentation at the top). I should have stayed out of the business of
>> editing cmake files :-(
>>
>
>  It's not exactly your fault that nobody thought to comment anywhere that
> FindFFTW.cmake and the own-fftw build are supposed to fulfil the same
> contract...
>
> I already thought they would need to fulfill the same contract, but I
> thought that would happen through the same test, since it tests for
> HAVE_SIMD as well. I still don't understand how HAVE_SIMD gets set (and
> HAVE_SSE not) when we build our own FFT. Anyhow, it's probably better if
> someone else looks into fixing this.
>

It can't happen through a CMake test, because the download and build of
FFTW happens at make time, not configure time. So the old implementation
faked it in the file I mentioned.

I uploaded a hack-fix for the release branch, and a refactoring on master
that avoids the need for faking things just to avoid warnings.

Mark

> Berk
>
>
>  Anyway, bring on the day when we can do our own FFTs! ;-)
>
>  Mark
>
>
>>
>>
>> Berk
>>
>>
>> On 05/13/2015 10:21 PM, Mark Abraham wrote:
>>
>> Hi,
>>
>> On Wed, May 13, 2015 at 8:54 PM Berk Hess <hess at kth.se> wrote:
>>
>>>  Hi,
>>>
>>> I had a look at my change to the FFTW checks, but I don't see how
>>> something can go wrong here. As far as I can see the order and essential
>>> logic have not changed compared to 5.0.4.
>>>
>>
>>  The issue is on line 91. The new AND NOT works only under the
>> assumption that FFTWF_FOUND means that we ran the SIMD-flavour trycompile
>> tests. But the auto-download sets FFTWF_FOUND *and* FFTWF_HAVE_SIMD
>> (because it will have SIMD) and runs/fakes none of the tests. The previous
>> logic was positive, so the issue did not arise. One fix is to change
>> src/contrib/fftw/CMakeLists.txt to set a fake ${FFTW}_HAVE_SSE2.
>>
>>  Ideally, we could have a sane test that the auto-download works, but
>> even if we'd had one, the build would have worked and we likely wouldn't
>> have verified the warning-issuing behaviour :-(
>>
>>  Mark
>>
>>   Cheers,
>>>
>>> Berk
>>>
>>>
>>> On 05/13/2015 05:54 PM, Mark Abraham wrote:
>>>
>>> Hi,
>>>
>>>  Thanks for the email.
>>>
>>> On Wed, May 13, 2015 at 5:34 PM Hardy, Adam <ah259 at hw.ac.uk> wrote:
>>>
>>>> Dear all,
>>>>
>>>> I'm having trouble installing the latest release. Leaving all other
>>>> options default, but switching GMX_BUILD_OWN_FFTW=yes results in a cmake
>>>> warning:
>>>>
>>>> "
>>>> CMake Warning at cmake/gmxManageFFTLibraries.cmake:93 (message):
>>>>    The FFTW library was compiled with neither --enable-sse nor
>>>> --enable-sse2;
>>>>    those would have enabled SSE(2) SIMD instructions.  This will give
>>>>    suboptimal performance.  You should (re)compile the FFTW library
>>>> with both
>>>>    SSE2 and AVX instruction support (use both --enable-sse2 and
>>>> --enable-avx).
>>>>    The FFTW library will determine at runtime which SIMD instruction
>>>> set is
>>>>    fastest for different parts of the FFTs.
>>>>  Call Stack (most recent call first):
>>>>    CMakeLists.txt:742 (include)
>>>
>>> "
>>>
>>>
>>> That's inconsistent and somewhat embarassing, but not actually a
>>> problem. FFTW hasn't been downloaded or built by the time that warning is
>>> issued, so we have some logic that doesn't work correctly in the
>>> auto-download case.
>>>
>>>  Later on, FFTW is built but is still compiled with only --enable-sse2.
>>> We may change that behaviour for 5.1, if it is clear that adding
>>> --enable-avx as well is always neutral-or-useful, but there's nothing wrong
>>> with the resulting mdrun here.
>>>
>>>  This configuration works as expected with 5.0.4.
>>>>
>>>> I get the same results with this setting as "no". This message doesn't
>>>> make much sense in either case as I do not have an FFTW library on my
>>>> machine.
>>>
>>>
>>>  Hmm that could be a minor problem, but none of us have tried a build
>>> on a machine without FFTW, for the obvious reason. :-)
>>>
>>>
>>>> The error I get in 5.0.4 for this scenario is:
>>>>
>>>> "
>>>> Could not find fftw3f library named libfftw3f, please specify its
>>>> location in CMAKE_PREFIX_PATH or FFTWF_LIBRARY by hand (e.g.
>>>>  -DFFTWF_LIBRARY='/path/to/libfftw3f.so')
>>>>
>>>>  CMake Error at cmake/gmxManageFFTLibraries.cmake:76 (MESSAGE):
>>>>    Cannot find FFTW 3 (with correct precision - libfftw3f for
>>>> mixed-precision
>>>>    GROMACS or libfftw3 for double-precision GROMACS).  Either choose
>>>> the right
>>>>    precision, choose another FFT(W) library (-DGMX_FFT_LIBRARY), enable
>>>> the
>>>>    advanced option to let GROMACS build FFTW 3 for you
>>>>    (-GMX_BUILD_OWN_FFTW=ON), or use the really slow GROMACS built-in
>>>> fftpack
>>>>    library (-DGMX_FFT_LIBRARY=fftpack).
>>>>  Call Stack (most recent call first):
>>>>    CMakeLists.txt:738 (include)
>>>> "
>>>>
>>>> I see some in the release notes some changes were made to the cmake
>>>> warnings for AVX capable processors which I belive mine is
>>>
>>> (AMD fx-8350).
>>>>
>>>
>>>  Yes, but we don't expect much/any improvement on AMD cpus from adding
>>> --enable-avx. Use --enable-sse2 always (which is what the auto-download
>>> does).
>>>
>>>  Mark
>>>
>>>  Thanks,
>>>>
>>>> Adam Hardy
>>>> PhD Student
>>>> School of Engineering and Physical Sciences
>>>> Heriot-Watt University
>>>> Edinburgh EH14 4AS, UK
>>>>
>>>> -----
>>>> We invite research leaders and ambitious early career researchers to
>>>> join us in leading and driving research in key inter-disciplinary
>>>> themes.
>>>> Please see www.hw.ac.uk/researchleaders for further information and how
>>>> to apply.
>>>>
>>>> Heriot-Watt University is a Scottish charity
>>>> registered under charity number SC000278.
>>>>
>>>> --
>>>> Gromacs Developers mailing list
>>>>
>>>> * Please search the archive at
>>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
>>>> before posting!
>>>>
>>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>>
>>>> * For (un)subscribe requests visit
>>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>>>> or send a mail to gmx-developers-request at gromacs.org.
>>>>
>>>
>>>
>>>
>>>  --
>>> Gromacs Developers mailing list
>>>
>>> * Please search the archive at
>>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>>> posting!
>>>
>>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>>
>>> * For (un)subscribe requests visit
>>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>>> or send a mail to gmx-developers-request at gromacs.org.
>>
>>
>>
>>
>>  --
>> Gromacs Developers mailing list
>>
>> * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
>> posting!
>>
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>> or send a mail to gmx-developers-request at gromacs.org.
>
>
>
>
>  --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20150514/84b340a1/attachment-0001.html>