I also noticed that during the ifort compilation, the c compiler was gcc.
Should this be changed to icc?
Thanks,
Ilya
On Dec 9, 2007 10:11 AM, Ilya Chorny <ichorny.gmail.com> wrote:
> I only have one version of MKL( I do have different version for differetn
> architechtures (i.e. 32, 64, and emt64). In the make log and in the error,
> the linking is to the emt64.
>
> Has anyone successfully compiled Amber 9 with MKL 10?
>
> Thanks,
>
> Ilya
>
>
>
> On Dec 9, 2007 10:01 AM, Ross Walker <ross.rosswalker.co.uk> wrote:
>
> > Hi Ilya,
> >
> > If this is for running production jobs then yes you should be using
> > ifort over gfortran. That makes a 30% or more difference in performance. If
> > it is only for local 'debugging / testing' on your local machine then you
> > are fine sticking with gfortran.
> >
> > Note, while Dave says that MKL doesn't make much of a difference it can
> > depend on what type of simulation you run, GB sims benefit more than PME
> > sims. The QMMM calculations benefit quite a bit from MKL and in AMBER 10
> > will benefit a signficantly (read > 50% for systems with more than 90 QM
> > atoms) from MKL10 and other math libraries that have optimized diagonalizers
> > in them.
> >
> > What seems weird with the error you are seeing below is that this is a
> > runtime error that should have been picked up at compile time. Hence it
> > looks to me like you are using a different version of MKL at runtime than
> > you linked against at compile time. If this is a cluster you should probably
> > check that each of the nodes has identical versions of MKL installed (in the
> > same paths) as the login node. You should also check your environment
> > variables are the same on the compute nodes as the one you compiled on.
> >
> > I would also suggest trying to compile statically so you don't run into
> > these problems. This sometimes work, sometimes doesn't depending on whether
> > statically linkable libraries are available. For MKL this is generally okay
> > but I haven't tried it with v10 yet.
> >
> > Good luck,
> >
> > Ross
> >
> >
> > /\
> > \/
> > |\oss Walker
> >
> > | HPC Consultant and Staff Scientist |
> > | San Diego Supercomputer Center |
> > | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
> > | http://www.rosswalker.co.uk | PGP Key available on request |
> >
> > Note: Electronic Mail is not secure, has no guarantee of delivery, may
> > not be read every day, and should not be used for urgent or sensitive
> > issues.
> >
> >
> > ------------------------------
> > *From:* owner-amber.scripps.edu [mailto:owner-amber.scripps.edu] *On
> > Behalf Of *Ilya Chorny
> > *Sent:* Sunday, December 09, 2007 09:22
> > *To:* amber.scripps.edu
> > *Subject:* Re: AMBER: Re: Amber_ifort_x86_64 test error
> >
> > should I even be using ifort?
> >
> > On Dec 9, 2007 9:13 AM, David A. Case <case.scripps.edu> wrote:
> >
> > > On Sun, Dec 09, 2007, Ilya Chorny wrote:
> > > >
> > > >
> > > > cd circ_dna; ./Run.circdna
> > > >
> > > > MKL func load error:
> > > > /data0/software/intel/mkl/10.0.1.014/lib/em64t/libmkl_vml_mc.so:
> > > undefined
> > > > symbol: vmlGetErrorCallBack
> > > > ./Run.circdna: Program error
> > > > make: *** [test.sander.GB] Error 1
> > > >
> > >
> > > Amber 9 was released before Intel had version 10 of the MKL libraries,
> > > and
> > > the calling sequences have been changed. Someone on the list who has
> > > access
> > > to version 10 might be able to post a bug-fix here.
> > >
> > > In the meantime, please realize the MKL has very little impact on
> > > overall
> > > performance, and you should probably just un-define your MKL_HOME
> > > variable and
> > > re-configure.
> > >
> > > ...dac
> > >
> > >
> > > -----------------------------------------------------------------------
> > > The AMBER Mail Reflector
> > > To post, send mail to amber.scripps.edu
> > > To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
> > >
> >
> >
> >
> > --
> > Ilya Chorny Ph.D.
> >
> >
>
>
> --
> Ilya Chorny Ph.D.
>
--
Ilya Chorny Ph.D.
-----------------------------------------------------------------------
The AMBER Mail Reflector
To post, send mail to amber.scripps.edu
To unsubscribe, send "unsubscribe amber" to majordomo.scripps.edu
Received on Wed Dec 12 2007 - 06:07:10 PST
