[gmx-developers] Error configuring 5.0.5 with GMX_BUILD_OWN_FFTW=yes
Berk Hess
hess at kth.se
Wed May 13 22:50:27 CEST 2015
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
> <mailto: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.
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
>> <mailto: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
>>> <mailto: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
>>> <http://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
>>> <mailto: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
>> <mailto: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
> <mailto: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/20150513/13876de1/attachment-0001.html>
More information about the gromacs.org_gmx-developers
mailing list