[gmx-developers] Re: gromacs-4.0.4
Bernhard Bandow
bandow at rrzn.uni-hannover.de
Thu Mar 19 18:53:12 CET 2009
Are these findings serious in a way that users have to face consequences
for their results they obtain from such an installation?
-Bernhard
Justin A. Lemkul schrieb:
>
>
> Bernhard Bandow wrote:
>> Dear developers,
>>
>> further attemps to get gromacs-4.0.4 tests running are disappointing
>> either:
>> Configuration was done with:
>> ./configure --enable-fortran --with-fft=fftpack --enable-shared
>> again intel.compiler/11.0.069 was used.
>> Additionally on another machine the same configuration using
>> gcc/gfortran 4.3.3 was used.
>> The pattern of kernel tests that failed remains the same in both cases.
>> If all users of gromacs run the test suite I would expect more reports
>> on failing tests.
>
> I can report the same results (with nearly identical output in
> kernel020/checkvir.out) on a dual-core Intel MacBook with gcc-4.0.1.
> FFTW version is 3.0.1. Gromacs was built with:
>
> ./configure --with-gsl CPPFLAGS="-I/usr/local/fftw/include
> -I/sw/include" LDFLAGS="-L/usr/local/fftw/lib -L/sw/lib"
> make
> make install
>
> -Justin
>
>> Any comment or hint is appreciated.
>>
>> Best regards
>>
>> Bernhard Bandow
>>
>> Bernhard Bandow schrieb:
>>> I am not quite shure if this part of the output of kernel020/md.log says
>>> that fortran was used instead of the handcoded SSE routines:
>>> ...
>>> Table routines are used for coulomb: FALSE
>>> Table routines are used for vdw: FALSE
>>> Cut-off's: NS: 0.01 Coulomb: 0.01 BHAM: 0.9
>>> Determining largest Buckingham b parameter for table
>>> Buckingham b parameters, min: 0, max: 43.33
>>> System total charge: 0.000
>>> Generated table with 950 data points for 1-4 COUL.
>>> Tabscale = 500 points/nm
>>> Generated table with 950 data points for 1-4 LJ6.
>>> Tabscale = 500 points/nm
>>> Generated table with 950 data points for 1-4 LJ12.
>>> Tabscale = 500 points/nm
>>>
>>> Enabling SPC water optimization for 196 molecules.
>>>
>>> Configuring nonbonded kernels...
>>> Testing x86_64 SSE support... present.
>>> ...
>>>
>>> So I compiled again omitting the '--enable-fortran' option. This caused
>>> a number of tests in simple and complex to fail as well as the same
>>> tests in kernel as described below.
>>>
>>> David van der Spoel schrieb:
>>>> Bernhard Bandow wrote:
>>>>> Dear developers,
>>>>>
>>>>> During installing and testing gromacs4.0.4 together with its test
>>>>> suite
>>>>> a number of tests failed. Unfortunately playing around with compiler
>>>>> options, linking against different fft libraries as well as changing
>>>>> paramters in grompp.mdp files did not solve the problem - some tests
>>>>> still fail and I got stuck here.
>>>>>
>>>>> Since other postings regarding the same topic are part of another
>>>>> mailing list I would like to put an abstract here.
>>>>>
>>>>> i)The tests were run on one node of a linux cluster employing 8 cores.
>>>>> Each node is a dual socket blade with two quad core cpus.
>>>>> /proc/cpuinfo says:
>>>>>
>>>>> processor : 0
>>>>> vendor_id : GenuineIntel
>>>>> cpu family : 6
>>>>> model : 23
>>>>> model name : Intel(R) Xeon(R) CPU E5472 @ 3.00GHz
>>>>> stepping : 6
>>>>> cpu MHz : 2992.496
>>>>> cache size : 6144 KB
>>>>> physical id : 0
>>>>> siblings : 4
>>>>> core id : 0
>>>>> cpu cores : 4
>>>>> fpu : yes
>>>>> fpu_exception : yes
>>>>> cpuid level : 10
>>>>> wp : yes
>>>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep
>>>>> mtrr pge
>>>>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
>>>>> syscall
>>>>> nx lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr dca
>>>>> lahf_lm
>>>>> bogomips : 5990.08
>>>>> clflush size : 64
>>>>> cache_alignment : 64
>>>>> address sizes : 38 bits physical, 48 bits virtual
>>>>> power management:
>>>>>
>>>>> ... until processor 7
>>>>>
>>>>> The OS is SUSE Linux Enterprise Server 10 (x86_64), version 10,
>>>>> patchlevel 2.
>>>>>
>>>>> ii)Gromacs was compiled with Intel 11.0.069 compiler using mvapich2
>>>>> Further options in configure were:
>>>>> --enable-fortran
>>>> Can you please check whether fortran was actually used (in the md.log
>>>> file), if so please turn it off and try again. Fortran is a lot slower
>>>> than the handcoded SSE routines, which may also imply it has not been
>>>> tested to the same degree.
>>>>
>>>>> --enable-mpi
>>>>> --with-fft=mkl
>>>>> --enable-shared
>>>>> The system gromacs is intended to run on uses mpiexec to initiate
>>>>> message passing. So gmxtest.pl was modified at line 31 to:
>>>>>
>>>>> $mdprefix = "mpiexec -np $parallel"
>>>>>
>>>>> In order to exclude details of compilation and linking the
>>>>> optimisation level was then reduced until -O0, and the intel-mkl
>>>>> was
>>>>> replaced by fftw3.1.2.
>>>>>
>>>>> iii)As an example for failing tests in 'kernel' kernel020 fails with
>>>>> /kernel020/checkvir.out containing:
>>>>>
>>>>> LJ-14 step 0: -63.1209, step 0: 6.50742
>>>>> Potential step 0: -321.601, step 0: -251.972
>>>>> Kinetic En. step 0: 15.0135, step 0: 29.0739
>>>>> Total Energy step 0: -306.588, step 0: -222.898
>>>>> Temperature step 0: 1.93226, step 0: 3.74185
>>>>> Pressure (bar) step 0: -3095.37, step 0: -2497.79
>>>>> Vir-XX step 0: 1127.45, step 0: 1075.85
>>>>> Vir-XY step 0: 63.524, step 0: 21.7773
>>>>> Vir-XZ step 0: -264.813, step 0: -260.354
>>>>> Vir-YX step 0: 63.5241, step 0: 21.7775
>>>>> Vir-YY step 0: 803.252, step 0: 581.702
>>>>> Vir-ZX step 0: -264.813, step 0: -260.355
>>>>> Vir-ZZ step 0: 321.207, step 0: 176.574
>>>>>
>>>>> The deviations are obvious.
>>>>>
>>>>> I hope this helps to locate the reason for the tests to fail in
>>>>> order to
>>>>> come to a set of tests that help to test installations of gromacs.
>>>>>
>>>>> Best regards
>>>>>
>>>>> Bernhard Bandow
>>>>>
>>>>> David van der Spoel schrieb:
>>>>>> Bernhard Bandow wrote:
>>>>>>> Dear Prof. van der Spoel,
>>>>>>>
>>>>>>> as I have reported some days before we observe a number of tests in
>>>>>>> gromacs-4.0.4 failing. Those of the complex category can all be
>>>>>>> fixed if
>>>>>>> the hints to change parameters for electrostatics or thermostats.
>>>>>>> Reducing the Compiler optimisation to -O0 does additionally fix
>>>>>>> problems
>>>>>>> with two of the pbd2gmx tests. For the kernel tests we observe
>>>>>>> the same
>>>>>>> pattern of failing tests that were also reported elsewhere:
>>>>>>>
>>>>>>> Testing kernel020 . . . FAILED. Check files in kernel020
>>>>>>> Testing kernel120 . . . FAILED. Check files in kernel120
>>>>>>> Testing kernel121 . . . FAILED. Check files in kernel121
>>>>>>> Testing kernel122 . . . FAILED. Check files in kernel122
>>>>>>> Testing kernel123 . . . FAILED. Check files in kernel123
>>>>>>> Testing kernel124 . . . FAILED. Check files in kernel124
>>>>>>> Testing kernel220 . . . FAILED. Check files in kernel220
>>>>>>> Testing kernel221 . . . FAILED. Check files in kernel221
>>>>>>> Testing kernel222 . . . FAILED. Check files in kernel222
>>>>>>> Testing kernel223 . . . FAILED. Check files in kernel223
>>>>>>> Testing kernel224 . . . FAILED. Check files in kernel224
>>>>>>> Testing kernel320 . . . FAILED. Check files in kernel320
>>>>>>> Testing kernel321 . . . FAILED. Check files in kernel321
>>>>>>> Testing kernel322 . . . FAILED. Check files in kernel322
>>>>>>> Testing kernel323 . . . FAILED. Check files in kernel323
>>>>>>> Testing kernel324 . . . FAILED. Check files in kernel324
>>>>>>>
>>>>>>> Changing parameters in these cases is not successful. The situation
>>>>>>> remains even if the program is linked against fftw3.1.2 libraries
>>>>>>> instead of the intel mkl.
>>>>>>> As a scientist it think it is very imnportant to have a tool which
>>>>>>> functionality can be tested well in order to obtain results which
>>>>>>> can be
>>>>>>> trusted. For my own problems this of course also depends on my
>>>>>>> abilities
>>>>>>> in writing proper input.
>>>>>>> My concern at the HLRN is to provide knowledge for the users of our
>>>>>>> computing center how to install and run the installed software.
>>>>>>> Please tell me if or how I can contribute to a solution e.g. by
>>>>>>> testing
>>>>>>> or writing to people of the gromacs team without addressing only one
>>>>>>> person.
>>>>>>>
>>>>>> The best place is the gmx-developers list. You are also welcome to
>>>>>> submit a bugzilla.
>>>>>>
>>>>>> There were some rumors that the kernels fail in parallel, but not
>>>>>> sequentially but I haven't tested.
>>>>>>
>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> Bernhard Bandow
>>>>> _______________________________________________
>>>>> gmx-developers mailing list
>>>>> gmx-developers at gromacs.org
>>>>> http://www.gromacs.org/mailman/listinfo/gmx-developers
>>>>> Please don't post (un)subscribe requests to the list. Use the www
>>>>> interface or send it to gmx-developers-request at gromacs.org.
>> _______________________________________________
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://www.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the www
>> interface or send it to gmx-developers-request at gromacs.org.
>>
>
--
---------------------------------------------------------------------
Dr. Bernhard Bandow Phone: +49 511 762 794727
Leibniz Universitaet Hannover FAX: +49 511 762 3003
RRZN / HLRN Email: bandow at rrzn.uni-hannover.de
Schlosswender Str. 5
D-30159 Hannover http://www.rrzn.uni-hannover.de/
Germany https://www.hlrn.de/home/view
---------------------------------------------------------------------
More information about the gromacs.org_gmx-developers
mailing list