[gmx-users] problem with icc compiler

Thu Mar 11 08:44:29 CET 2010

Hi,
I have reported this problem to Bugzilla some months ago:

  http://bugzilla.gromacs.org/show_bug.cgi?id=378

I don't exactly know what the problem is, but it is definitely related
to the MKL FFTs, which can be seen by switching from PME to cutoff, and
the problem should go away.

I have reproduced this behavior on several computers, as I have written
in the bugzilla report.

/ Erik Brandt

tor 2010-03-11 klockan 01:34 +0100 skrev Mark Abraham:

> On 11/03/2010 3:04 AM, Thomas Schlesier wrote:
> > Gromacs was compiled on a xeon (woodcrest). for the simulations i used
> > an old xeon (don't know what chip, but also 64bit system) and a i7.
> 
> Well, don't do that. IMO, dynamic linking should work in that kind of 
> scenario, but something is clearly broken.
> 
> > About static / dynamic libraries:
> > I used there default settings. At the end of the configure command it
> > tells me the following:
> > * On most platforms you can save 10X space with dynamic libraries,
> > although the binaries might be less portable. Why not try --enable-shared?
> > So i think the libraries are static.
> 
> Your internal GROMACS linking is static, which you could change with 
> --enable-shared. You will need to kick the linker harder than that to 
> force it to link statically to system libraries also.
> 
> > I tried Mark's suggestion and compiled a new version, where i change
> > '--with-fft=mkl' with '--enable-fft=fftpack' (the restr of the configure
> > command was the same then before). With that, the error didn't appear.
> > Does that mean that the linking to mkl did not work for mdrun, but
> > worked for mdrun_mpi (because there the temperature was right)?
> 
> Yep, that is strong evidence for my hypothesis. Either compile GROMACS 
> on the target execution system (even submit a cluster job for the 
> compilation!), or (if the former doesn't work) get the MKL documentation 
> and read it about how to enforce static linking. There may be some 
> cunning linker option for that, or you may need to explicitly cite the 
> static versions of the libraries. Or, get FFTW installed and link to 
> that. I have found near-negligible performance differences between MKL 
> and FFTW on my machine.
> 
> > One thing for the temperature jump:
> > Temperature starts at around 300 K (from 'gen_temp') then goes in 1-2ps
> > up to around 425 K and then stays there. the simulation was 100ps long,
> > in the end i had an average value of about 425 K (from log file).
> >
> > Here are the first 20ps from g_energy
> > 0.000000 305.240509
> > 1.000000 381.614166
> > 2.000000 410.572906
> > 3.000000 434.954956
> > 4.000000 414.660400
> > 5.000000 394.799591
> > 6.000000 389.087128
> > 7.000000 414.893982
> > 8.000000 449.444183
> > 9.000000 417.877472
> > 10.000000 442.470306
> > 11.000001 446.170258
> > 12.000001 448.844666
> > 13.000001 412.847473
> > 14.000001 454.549744
> > 15.000001 447.908478
> > 16.000000 404.607422
> > 17.000000 404.629944
> > 18.000000 441.559448
> > 19.000000 396.328400
> > 20.000000 421.386017
> 
> That's broken all right!
> 
> Mark
> 
> > and:
> > Energy Average RMSD Fluct. Drift Tot-Drift
> > ----------------------------------------------------------------
> > Temperature 424.625 21.7645 21.6696 0.0703201 7.03215
> >
> >
> >
> >>
> >> On 10/03/2010 12:21 AM, Thomas Schlesier wrote:
> >>> Could anybody reproduce that error or has an idea what is happening?
> >>> Or i am alone with that problem?
> >>
> >> Nothing looks obviously wrong, but it's hard to be sure in the absence
> >> of information about your hardware. The most likely issue is some kind
> >> of dynamically-linked library mismatch. This can happen if your
> >> execution environment differs from your linking environment. Try forcing
> >> linking to static versions of the libraries, which will prevent this.
> >>
> >> Also try disabling things until you get sensible behaviour in all cases,
> >> like --enable-fft=fftpack. That would reveal that the problem was with
> >> linking to mkl.
> >>
> >> Also 1-2ps is a bit too short to expect convergence of temperature -
> >> check the plot of T against t with g_energy.
> >>
> >> Mark
> >>
> >>>> Date: Fri, 5 Mar 2010 23:11:45 +0100
> >>>> From: Thomas Schlesier <schlesi at uni-mainz.de>
> >>>> Subject: [gmx-users] problem with icc compiler
> >>>> To: "gmx-users at gromacs.org" <gmx-users at gromacs.org>
> >>>> Message-ID: <4B9181A1.7060106 at uni-mainz.de>
> >>>> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
> >>>>
> >>>> Hi,
> >>>> i observed the following problem. if i simulate water (spc or tip4p)
> >>>> with gromacs 4.0.5 i get with v-rescale or berendsen thermostat the
> >>>> wrong temperature (ref_t = 300K -> average around 425K, in about
> >>>> 1-2ps),
> >>>> but only in serial, not in parallel runs.
> >>>> non-water molecules or nose-hoover thermostat make no problems.
> >>>> see also
> >>>> http://lists.gromacs.org/pipermail/gmx-users/2010-March/049248.html
> >>>> for mdp and log file.
> >>>>
> >>>> gromacs was compiled with the following comands:
> >>>> and in the file 'configure' all '-lmkl' were deleted (don't ask me why,
> >>>> i don't really understand that stuff, the command were from our
> >>>> previous
> >>>> phd student).
> >>>>
> >>>> ./configure CC="icc"
> >>>> CPPFLAGS="-I/share/apps/intel/mkl/10.0.011/include"
> >>>> LDFLAGS="-L/share/apps/intel/mkl/10.0.011/lib/em64t
> >>>> -lmkl_solver_lp64_sequential -Wl,--start-group -lmkl_intel_lp64
> >>>> -lmkl_sequential -lmkl_core -Wl,--end-group -lpthread" --with-fft=mkl
> >>>> --prefix="/share/apps/gromacs/4.0.5"
> >>>> make
> >>>> make install
> >>>> make clean
> >>>> ./configure CC="icc"
> >>>> CPPFLAGS="-I/share/apps/intel/mkl/10.0.011/include"
> >>>> LDFLAGS="-L/share/apps/intel/mkl/10.0.011/lib/em64t
> >>>> -lmkl_solver_lp64_sequential -Wl,--start-group -lmkl_intel_lp64
> >>>> -lmkl_sequential -lmkl_core -Wl,--end-group -lpthread" --with-fft=mkl
> >>>> --prefix="/share/apps/gromacs/4.0.5" --enable-mpi --disable-nice
> >>>> --program-suffix=_mpi
> >>>> make mdrun
> >>>> make install-mdrun
> >>>>
> >>>> for gromacs 4.0.5 i used the icc 9.1.046 compiler.
> >>>>
> >>>> i also tried gromacs 4.0.7 with icc 9.1.046 and icc 10.1.008 with spc
> >>>> water, v-rescale thermostat.
> >>>> -> serial: too high temperature 425K iso 300K
> >>>> -> parallel: no problems
> >>>> with non-water (mesitylene) i have no problem in serial.
> >>>>
> >>>> the problem does not come from grompp because i can use same tpr-file
> >>>> for serial and parallel runs with the above results.
> >>>>
> >>>> if someone needs more informations about this please tell me.
> >>>>
> >>>> greetings
> >>>> thomas
> >>>>
> 

-- 
Erik Brandt <erbr02 at kth.se>
KTH
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-users/attachments/20100311/c25dfbf5/attachment.html>