On Apr 27, 2013, at 4:43 PM, Jason Swails wrote:
> On Sat, Apr 27, 2013 at 10:21 AM, M. L. Dodson <mldodson.comcast.net> wrote:
>
>>
>> On Apr 27, 2013, at 8:53 AM, Jason Swails wrote:
>>
>>> On Thu, Apr 25, 2013 at 9:32 PM, Eugene Yedvabny <eyedvabny.berkeley.edu
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I am trying to compile the new AmberTools release and am running into
>>>> issues with FFTW3 compilation when configuring with the -openmp flag.
>>>> Specifically, the installation dies because it can't include libfftw3.a
>>>> when compiling pbsa. The machine is CentOS 6.4 with Intel Composer 13
>> and
>>>> GCC 4.4.6 and I've tried compiling with both of the compilers, with and
>>>> without MKL.
>>>>
>>>
>>> It works just fine for me. I don't have exactly the same ifort version
>> you
>>> have, but it's at least in the same release family:
>>>
>>> swails.Batman ~/amber (master) $ ifort --version
>>> ifort (IFORT) 13.0.1 20121010
>>> Copyright (C) 1985-2012 Intel Corporation. All rights reserved.
>>>
>>
>> FFTW3 failed this way for me, as well. I did not follow up at the time,
>> just
>> did without. But mine was an -openmp compile as well, but with gnu
>> compilers:
>>
>
> Ah. It appears that Dave found the problem. I was indeed able to
> reproduce this issue after I tried an OpenMP build from a completely clean
> tree.
>
> The issue is that the OpenMP build should invoke the THIRDPARTY rule to
> make sure that fftw gets built. If you do an OpenMP build after either a
> standard serial or parallel installation, fftw will already be built, so
> this error will not occur. I'm guessing we'll release an update to fix
> this…
>
And the manual clearly states (at least the AT12 manual) that you should
do a make serial first. That always annoyed me: the user having to do
something that should be make's job. This time I just forgot (really I did).
I wanted an openmp build so I told make to just do it.
I don't know how widespread openmp support is among operating systems likely
to be used for AmberTools installs, but if it is near universal, my opinion
is that -openmp installs should be the default, not serial installs. This is
because almost all modern CPUs are multicore, hence fit well with openmp.
Assuming operating system support, of course.
If support is mixed among Linux distributions, then we should be encouraging
use of those that support openmp. Aside from research groups with cuda gear
or supercomputing centers, multicore CPU workstations should be the rule,
not the exception. So -openmp should be more useful than MPI compiles for
most people, right? You can always bodge the build to support only one core
by default if you think doing otherwise is a problem. (I know pmemd and
sander have no support for openmp, but that just means their builds should be
agnostic to the -openmp flag, it seems to me.)
Thanks for the response.
Bud Dodson
>
>>
>>>>
>>>> gfortran -DFFTW -DBINTRAJ -DLIBPBSA -c -O3 -mtune=native -ffree-form
>>>> -I/home/eyedvabny/amber12/include -I/home/eyedvabny/amber12/include
>> -o
>>>> fftw3.LIBPBSA.o fftw3.F90
>>>> fftw3.F90:5: Error: Can't open included file 'fftw3.f03'
>>>>
>>>> ifort -DFFTW -DBINTRAJ -DLIBPBSA -c -ip -O3 -xHost -FR
>>>> -I/home/eyedvabny/amber12/include -I/home/eyedvabny/amber12/include
>> -o
>>>> fftw3.LIBPBSA.o fftw3.F90
>>>> fftw3.F90(5): error #5102: Cannot open include file 'fftw3.f03'
>>>>
>>>> ifort -DFFTW -DMKL -DBINTRAJ -DLIBPBSA -c -ip -O3 -xHost -FR
>>>> -I/home/eyedvabny/amber12/include -I/home/eyedvabny/amber12/include
>>>> -I/share/apps/intel/composer_xe_2013.2.146/mkl/include -o
>> fftw3.LIBPBSA.o
>>>> fftw3.F90
>>>> fftw3.F90(5): error #5102: Cannot open include file 'fftw3.f03'
>>>>
>>>
>>> These errors make it seem like fftw is not getting built correctly...
>>>
>>>
>>>>
>>>> I am not planning on using pbsa and so can live with -nofftw, but
>>>> unfortunately some OpenMP problems persist:
>>>>
>>>> /home/eyedvabny/amber12/bin/nab -o matextract matextract.o
>>>> icc: error #10236: File not found:
>>>> '/share/apps/intel/composer_xe_2013.2.146/lib/intel64/ifort/libiomp5.a'
>>>> cc failed!
>>>>
>>>> The correct path should be
>>>>
>> /share/apps/intel/composer_xe_2013.2.146/compiler/lib/intel64/libiomp5.a,
>>>> so it looks like Amber uses the old Intel folder structure. My
>>>> LD_LIBRARY_PATH includes the .../compiler/lib/intel64/ directory so the
>> lib
>>>> would have been found if not for the hard-coded path. Compilation seems
>> to
>>>> complete successfully for OpenMP with both Intel and GNU (there are some
>>>> issues in the make log but they don't seem fatal) if I exclude MKL and
>>>> fftw3. But now I am losing all performance gains of using an optimized
>>>> library.
>>>>
>>>
>>> This is not an Amber issue, I don't think (Amber makes no assumptions
>> about
>>> where the intel libraries are--the intel compilers have them built-in).
>>> This sounds more like an issue with how your compilers are set up and/or
>>> accessed...
>>>
>>> Also, what exact commands did you execute (in which directories) to get
>>> these errors?
>>>
>>> HTH,
>>> Jason
>>>
>>
>> I don't think the problem is limited to Intel compilers. See above.
>>
>
> Sorry, I was unclear. The 'intel' error I was referring to was this one:
>
>
> icc: error #10236: File not found:
>
> '/share/apps/intel/composer_xe_2013.2.146/lib/intel64/ifort/libiomp5.a'
> cc failed!
>
> All the best,
> Jason
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 352-392-4032
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
--
M. L. Dodson
Business email: activesitedynamics-at-gmail-dot-com
Personal email: mldodson-at-comcast-dot-net
Gmail: mlesterdodson-at-gmail-dot-com
Phone: eight_three_two-five_63-386_one
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sat Apr 27 2013 - 17:30:03 PDT
