Page 1 of 1

Forces are wrong in vasp.5.2.11 compiled with ifort 12

Posted: Tue Jul 26, 2011 3:05 pm
by rrobles
Dear admins,

We would like to report that when compiling vasp.5.2.11 with the last version of intel compiler (ifort 12) the resulting forces are wrong. We have seen that they are different to the ones obtained with previous versions of vasp or with the same version (5.2.11), but compiled with ifort 11.

A workaround for it is to compile the file force.F with -O1 (less optimization).

Has anybody else found the same behavior?

Best regards.

Forces are wrong in vasp.5.2.11 compiled with ifort 12

Posted: Wed Jul 27, 2011 11:21 am
by chorawut
Sure...I have the same problem even with ifc-11
http://cms.mpi.univie.ac.at/vasp-forum/ ... php?3.9798
I thought that VASP 5.2.11 should be back to ole one (vasp4.6 or vasp5.2.2).

Forces are wrong in vasp.5.2.11 compiled with ifort 12

Posted: Tue Aug 30, 2011 5:52 pm
by admin
please use Ifort.11 then. All the tests I refer to in my previous posts were done
with Intel 11.1, which is the compiler release we use here.

Forces are wrong in vasp.5.2.11 compiled with ifort 12

Posted: Sat Oct 15, 2011 6:05 pm
by Dr_Nick
Dear vasp-users,

I compiled the MPI-Version of VASP 4.6.38 and 5.2.12 with the following setup:

- CentOS 5
- OpenMPI 1.4.3
- Intel 12.0.3 or 11.1.069 compilers
- MKL for BLAS and LAPACK, no Scalapack was used
- Intel MKL FFTW Wrapper
- OFLAG: -O3 -msse3
- with and without lowering the optimization for force.F to -O1

bench.Hg was run on 1 Opteron 8380 CPU; results on a Xeon Workstation, using the same settings, are identical to those obtained on the Opteron:

- Within a given version (4.6 or 5.2) the forces are identical
- The forces between 4.6 and 5.2 differ ! (in the order of 1 x 10-5 eV)
- Changing the compiler version has no effect on the forces
- Lowering the optimization has no effect on the forces

Additional tests were performed for 5.2.12 on the Opteron:

1)
- gcc 4.3.3
- gotoblas2-1.06
- fftw-3.3
2)
- Intel 12.0.3
- ACML 5.5.0
- Furthm?ller FFTW

In both tests, forces are identical to those obtained with the Intel/MKL/IFFTW setup, so we might rule out compiler / Math library issues, at least in my naive understanding.

I also tested a larger system (Al2O3 slab, 80 atoms, 5 k-points, 1 SCF cycle), confirming the above results. Discrepancies in force between 4.6.38 and 5.2.12 are in the order of 1 x 10-4 eV/a for some atoms. TOTEN differs by 1.8 x 10-5 eV. These small differences will not cause me sleepless nights but they show that results obtained with both versions are not identical.

Some additional notes:

- For both versions, when running on multiple CPUs (4, 8, 16 ...) identical forces were only obtained when using the same NPAR setting. When the NPAR tag is omitted, the forces are not identical!

-I would like to suggest an update of the OUTCAR.ref and OSZICAR.ref files of bench.Hg delivered with the VASP package. Including some heavier calculation as reference would also be nice, given the performance of current machines.






<span class='smallblacktext'>[ Edited Sat Oct 15 2011, 07:59PM ]</span>

Forces are wrong in vasp.5.2.11 compiled with ifort 12

Posted: Sun Oct 16, 2011 6:37 pm
by jber
Seems natural to cover such things by regression tests.

Forces are wrong in vasp.5.2.11 compiled with ifort 12

Posted: Mon Oct 17, 2011 11:56 am
by Dr_Nick
I fully agree with that!

Forces are wrong in vasp.5.2.11 compiled with ifort 12

Posted: Mon Oct 17, 2011 5:40 pm
by jber
Hi,

could any of you help me to verify my installation?
I'm getting the total energy of F atom dependent on the number of bands with
LASPH = .TRUE.
The inputs are given in the first post on second page of the following thread:
http://cms.mpi.univie.ac.at/vasp-forum/ ... php?4.9673

Forces are wrong in vasp.5.2.11 compiled with ifort 12

Posted: Tue Oct 18, 2011 12:00 am
by Dr_Nick
I started you test set on two different machines and will post the results to the original thread.

Forces are wrong in vasp.5.2.11 compiled with ifort 12

Posted: Tue Oct 18, 2011 12:33 pm
by jber
Thanks, i'm grateful for that!
Note that the problem is dependence of the total energy on the number of bands,
so you will have to scan several values of NBANDS.