ABINIT Discussion Forums

Hallo,
a comparison of abinit-7.0.5 and abinit packaged by debian 4.3 evidenced different results.
So I ran the tests and found that many of them did not pass.
I found the same on abinit-6.12.3 and 4.8.5 and so began varying the compilation options:
gfortran4.7 gfortran4.4, with and without openmpi
atlas openblas and netlib
I also tried a different machine but with no luck.
In the input that started all,
abinit compiled by me gives several warnings about density being lower than -0.05,
abinit from debian package gives different etot and no such warning.
What might the problem be?

When I compile abinit-7.0.5 with debug>enhanced
I get instead
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0 0x7F122AB0C667
#1 0x7F122AB0CC34
#2 0x7F1229EB04EF
#3 0x7F122CF1573F
#4 0x7F122CF15708
#5 0x7F122CA7437C
#6 0x7F122D16C7CF
#7 0x4050169 in __m_cgtools_MOD_cg_zdotc at m_cgtools.F90:494
#8 0x7764F5 in vtowfk_ at vtowfk.F90:878
#9 0x70A53F in vtorho_ at vtorho.F90:1089
#10 0x67D24E in scfcv_ at scfcv.F90:1334
#11 0x6408B3 in scfcv_new_ at scfcv_new.F90:240
#12 0x641085 in scfcv_new2_ at scfcv_new2.F90:144
#13 0x5DA699 in gstate_ at gstate.F90:1105
#14 0x4AE83B in gstateimg_ at gstateimg.F90:421
#15 0x48AA5F in driver_ at driver.F90:581
#16 0x46BBF1 in abinit at abinit.F90:435
might it be related?

Hi,

The segmentation fault is probably related to a bug in your implementation of BLAS. Configure abinit with the option --enable-zdot-bugfix and recompile. You may still have problems with Wannier functions if you use them.

About the consistency between Abinit versions.
A great care is devoted to the reproducibility of the results but it is unwise to do comparisons between version 4 and 6/7. There have been changes to the default values of several variables and this may affect the results. And I wouldn't do comparisons between absolute total energies but rather between differences.

Kind regards,

Alain

Putting
nsim 1
eliminates the density < -0.05 warnings and gives reasonable results again in version 7.0.5,
and equal to results from versions before 5.4.4p.
The same does displacing an atom by a physically irrelevant quantity to break symmetry.
So compilation options and libraries had nothing to do with the problem.
From the manual, I had deduced nsim has only to do with editing of coordinate nuclei,
but apparently it is not so.

Configure options and libs explain the segfaults you experienced, not the difference between versions

nsim? I don't know that one ... are you talking about nsym? By specifying nsym 1 you force to have no symmetry i.e. only identity (and I would add symrel to be sure which one is applied). Which spacegroup comes out of your test?
Looking at your input file, I can hardly recognize the bulk gold crystal in such a tiny cell. IMHO, gold is fcc, spacegroup 225 with a cell length of 4.0785A - according to Wyckoff. So I would define the crystall as ...
ntypat 1
znucl 79
acell 3*4.07825 angstrom
natom 1
typat 1
rprim 0.0 1/2 1/2
1/2 0.0 1/2
1/2 1/2 0.0
xred 0.0 0.0 0.0

and let the symmetry finder do its job.

Kind regards,

Alain

Yes, nsym I meant.
It is a 3 layer sqrt(3)xsqrt(3) slab, coordinates are from previous calculations on crystal (the program).
It was written so, because ready for geometry relaxation and an adsorption study.
The symmetry and multiplicity are recognized correctly, imo
--------------------------------
symlatt : the Bravais lattice is hP (primitive hexagonal)

chkprimit : COMMENT -
According to the symmetry finder, the unit cell is
not primitive, with multiplicity= 3.
This is allowed, as the input variable chkprim is 0.
.........
nsym = 36 n1xccc = 0 ntypat = 1 occopt = 4
.........
symrel 1 0 0 0 1 0 0 0 1 1 0 0 0 1 0 0 0 1
1 0 0 0 1 0 0 0 1 -1 0 0 0 -1 0 0 0 -1
-1 0 0 0 -1 0 0 0 -1 -1 0 0 0 -1 0 0 0 -1
-1 1 0 0 1 0 0 0 1 -1 1 0 0 1 0 0 0 1
-1 1 0 0 1 0 0 0 1 1 -1 0 0 -1 0 0 0 -1
1 -1 0 0 -1 0 0 0 -1 1 -1 0 0 -1 0 0 0 -1
-1 1 0 -1 0 0 0 0 1 -1 1 0 -1 0 0 0 0 1
-1 1 0 -1 0 0 0 0 1 1 -1 0 1 0 0 0 0 -1
1 -1 0 1 0 0 0 0 -1 1 -1 0 1 0 0 0 0 -1
0 -1 0 -1 0 0 0 0 1 0 -1 0 -1 0 0 0 0 1
0 -1 0 -1 0 0 0 0 1 0 1 0 1 0 0 0 0 -1
0 1 0 1 0 0 0 0 -1 0 1 0 1 0 0 0 0 -1
0 -1 0 1 -1 0 0 0 1 0 -1 0 1 -1 0 0 0 1
0 -1 0 1 -1 0 0 0 1 0 1 0 -1 1 0 0 0 -1
0 1 0 -1 1 0 0 0 -1 0 1 0 -1 1 0 0 0 -1
1 0 0 1 -1 0 0 0 1 1 0 0 1 -1 0 0 0 1
1 0 0 1 -1 0 0 0 1 -1 0 0 -1 1 0 0 0 -1
-1 0 0 -1 1 0 0 0 -1 -1 0 0 -1 1 0 0 0 -1
----------------------------------
My question is still, why should automatic symmetry recognition change the results?