Thank you for the prompt reply. I was able to resolve the Intel linking issue by modifying the $fl and $flibs_arch on line 783/784 in $AMBERHOME/AmberTools/src/configure2 script to coincide with the location of our Intel libraries. It seems Intel changed their folder structure and so the paths were improperly set. I hard-coded my paths but the sed pipe is easy to modify. Unfortunately it breaks backwards compatibility and so might require an if-else around icc version.
The other big fix was for the FFTW3 inclusion. It appears the Makefile was not actually compiling FFTW3 if run with -openmp. The openmp target calls nabonly target, so the easy fix was to replace nabonly: configured_serial $(NETCDF) $(XBLAS) with nabonly: configured_serial THIRDPARTY on line 80 in $AMBERHOME/AmberTools/src/Makefile
Which brings up a separate issue: THIRDPARTY is called by the serial, parallel, and [now] openmp targets regardless of whether the $rism or $pbsaflag have been set. But the configure2 script only calls FFTW3's configure if we are compiling RISM/PBSA with FFTW. So while there is no effective difference (because there are further checks for $rism=no within the target), Amber should still only compile FFTW3 if it plans on actually using it. The solution would be to remove $(FFTW3) from THIRDPARTY and call it conditionally from within the targets.
Thank you,
Eugene Yedvabny
On Friday, April 26, 2013 at 12:51 PM, David A Case wrote:
>
> On Thu, Apr 25, 2013, Eugene Yedvabny wrote:
> >
> > /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 problem is at line 1629 or 1636 of AMBERHOME/AmberTools/src/configure2.
> It looks like it only is triggered with the combination of MKL, -openmp, and
> some pretty recent version of the Intel compilers. It looks like you (or we)
> may be able to fix up the "$fl" variable and re-run configure. Or maybe
> libiomp5.a is not really needed(?)
>
> It looks like not using MKL would avoid the problem, and that is probably the
> least intrusive work-around. And be sure you really need the intel compilers,
> which keep changing all the time :-(
>
> I'll play around with various options, and try to get a fix.
>
> [Incidentally, the first step in debugging the problem above is to add the
> "-v" (verbose) flag to the nab command, which gives details on what is going
> on underneath the hood.]
>
> Thanks for the report....dac
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org (mailto:AMBER.ambermd.org)
> http://lists.ambermd.org/mailman/listinfo/amber
>
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Fri Apr 26 2013 - 17:30:03 PDT
