Hi,
On Mon, Feb 06, 2012 at 09:48:29AM -0500, Jason Swails wrote:
> I thought I fixed the parsing of the fort version... It works for me (in the developer version) for both ifort 11.1.069 and ifort 12.1.0.
I'm awol as far as amber12.
> On Feb 6, 2012, at 8:24 AM, David A Case <case.biomaps.rutgers.edu> wrote:
> > On Mon, Feb 06, 2012, Jan-Philip Gehrcke wrote:
> >> The regular expression filters for determining the Intel compiler
> >> version in the AmberTools configure script do not work correctly
> >>
> >>> icc_version=`$cc -v 2>&1`
...
> >> On my system, $icc_version then contains "icc version 12" instead of
> >> only a number, leading to the "integer expression expected" error. A
I noticed such complaints from AT1.5 and Amber11, using intel 12.1.0
but i ignored them and the config.h was correct.
> >> simpler approach would be:
> >> $ icc -dumpversion | sed -e 's/\..*//g'
> >> 12
> >> I am not sure if the -dumpversion switch works for older Intel compiler
> >> versions.
> >
> > "icc -dumpversion" works for icc 10,11 and 12. I don't have any access to
> > earlier versions right now.
icc -dumpversion
also works for 9.1 and 8.1
> > Unfortunately, ifort does not support a "-dumpversion" command :-(
> >>
> >> Is it still correct that Intel compiler versions higher than 11 must be
> >> treated specially, as stated in the AmberTools configure script? ->
> >>
> >>> # DRR - Add flags necessary for correct compilation with intel version >= 11
> >>> if [ "$icc_version" -ge 11 ] ; then
> >>> cxxflags="-std=c++0x $cxxflags"
> >>> ambercxxflags="-std=c++0x $ambercxxflags"
> >>> ldflags="-shared-intel"
> >>> fi
> >
> > Note that Jason took out the -std=c++0x stuff claiming it breaks 12.1.0. Not
> > sure myself whether we need the -shared-intel flags, and if so, only for
> > versions 11 and 12 (?)
> >
> > Note that the configure2 script has a bug in reporting the ifort_version.
> >
> > If anyone has a good knowledge of the best way to clean this up, please pipe
> > up. I'm inclined to go with "icc -dumpversion", but am not sure what to do
> > with ifort.
I second icc -dumpversion.
Another issue with amber configuring of intel compilers is
the optimization flags.
Based on AT1.5 and Amber11, the compiler options chosen
for intel look quite dated. Has anyone benchmarked this
recently ? Can't we get back to -fast ?
SSE_TYPES looks good until one tries to actually define it;
i wasted time trying to figure it out for Intel Xeon x5650 CPUs
and eventually decided to punt.
As an aside building AT1.5 and Amber11 on glenn and oakley
http://www.osc.edu/supercomputing/hardware/#opt
http://www.osc.edu/supercomputing/hardware/#oak
was substantially harder than building gromacs 4.5.5;
and about as annoying as building a recent LAMMPS.
Why ? Mostly bugfixing: extra downloads, several sources
of non identical directions, and this page not indicating
that re-configuring was really necessary (not just ./configure --help):
http://ambermd.org/bugfixes11.html
In addition, if one has to hand edit config.h, as i did for pgi
on glenn, then the whole procedure of multiple configures
is annoying since it forces several edits AND AT/src/config.h
is not equal to src/config.h. Sigh.
scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Feb 06 2012 - 21:30:02 PST
