
Known problems

This file contains the list of known problems
at the time a version of ABINIT is released.
Note that bugs discovered later than the
release are NOT described here...
(In particular, at the time of release, a particular
 version is not tested already on ALL platforms,
 only on a subset of 5, usually).

The present release 5.3.4 is suitable for production runs.

For version 5.3.4, list closed on 20070402
after installation and tests for: 	
seq and paral   PC/Linux with PGI compiler (~ABINIT/doc/config/build-examples/i686-pgi4.0_sleepy.ac)
seq             PC/Linux with PGI compiler (~ABINIT/doc/config/build-examples/i686-pgi4.0_dummy.ac)
seq and paral   PC/Linux with IFC compiler (~ABINIT/doc/config/build-examples/i686-intel8.1_sleepy.ac)
seq             PC/Linux with IFC compiler (~ABINIT/doc/config/build-examples/i686-intel9.0_dummy.ac)
seq             PC/Linux with g95 compiler (~ABINIT/doc/config/build-examples/i686-g95_sleepy.ac)
seq             PC/Linux with pathscale compiler (~ABINIT/doc/config/build-examples/i686-pathscale_sleepy.ac)
seq and paral   Itanium2 machine with IFC compiler (~ABINIT/doc/config/build-examples/ia64-intel8.1_chpit.ac)
seq and paral   Compaq/Dec EV67 OSF (~ABINIT/doc/config/build-examples/alphaev67-compaq_deccint.ac)
seq and paral   Compaq/Dec EV56 Linux (~ABINIT/doc/config/build-examples/alphaev56-compaq_tux.ac)
seq and paral   SGI Octane IRIX (~ABINIT/doc/config/build-examples/mips-mipspro_spinoza.ac)
seq and paral   IBM Power 5 (~ABINIT/doc/config/build-examples/powerpc64-ibm_fock.ac)
seq             IBM Power 4 (~ABINIT/doc/config/build-examples/powerpc-ibm_dirac.ac)
                Mac OS X, xlf compiler (~ABINIT/doc/config/build-examples/powerpc-ibm_max.ac)
seq and paral   Opteron with Intel compiler (~ABINIT/doc/config/build-examples/opteron-intel9.1_lemaitre.ac)

Compilation of Netcdf and ETSFIO, and corresponding testing were tried. (with v5.3.3) 
however these should NOT be attempted by non-expert users with this ABINITv5.3

Netcdf test ETSFIO test
failed                   PC/Linux with PGI compiler (~ABINIT/doc/config/build-examples/i686-pgi4.0_sleepy.ac)
failed                   PC/Linux with PGI compiler (~ABINIT/doc/config/build-examples/i686-pgi4.0_dummy.ac)
failed                   PC/Linux with IFC compiler (~ABINIT/doc/config/build-examples/i686-intel8.1_sleepy.ac)
OK    OK    OK           PC/Linux with IFC compiler (~ABINIT/doc/config/build-examples/i686-intel9.0_dummy.ac)
OK    OK    OK           PC/Linux with g95 compiler (~ABINIT/doc/config/build-examples/i686-g95_sleepy.ac)
                         PC/Linux with pathscale compiler (~ABINIT/doc/config/build-examples/i686-pathscale_sleepy.ac)
                         Itanium2 machine with IFC compiler (~ABINIT/doc/config/build-examples/ia64-intel8.1_chpit.ac)
                         Compaq/Dec EV67 OSF (~ABINIT/doc/config/build-examples/alphaev67-compaq_deccint.ac)
                         Compaq/Dec EV56 Linux (~ABINIT/doc/config/build-examples/alphaev56-compaq_tux.ac)
                         SGI Octane IRIX (~ABINIT/doc/config/build-examples/mips-mipspro_spinoza.ac)
OK    OK    failed       IBM Power 5 (~ABINIT/doc/config/build-examples/powerpc64-ibm_fock.ac)
                         IBM Power 4 (~ABINIT/doc/config/build-examples/powerpc-ibm_dirac.ac)
                         Mac OS X, xlf compiler (~ABINIT/doc/config/build-examples/powerpc-ibm_max.ac)
OK    OK    OK           Opteron with Intel compiler (~ABINIT/doc/config/build-examples/opteron-intel9.1_lemaitre.ac)
 
Compilation of LibXC  was not tested, and should NOT be attempted by non-expert users with this ABINITv5.3
Compilation of XMLF90 was not tested, and should NOT be attempted by non-expert users with this ABINITv5.3

Speed was not tested. 

All the problems are listed cumulatively.
Those specific to version 5.3 are found at the end of this file

===============================================

The type of the problem is identified as follows :

NUMERICAL ERROR : the physical result is incorrect,
 but the job does not crash. Moreover,
 the use of the input variables is legitimate.
 This is a very dangerous type of problem. 
 There are two subclasses :
 - INTERNALLY INCOHERENT
  (the bug can be seen because two sets of
   input variables should give the same results
   and do not) 
 - INTRINSIC
  (the bug does not cause incoherency, it can
   only be seen when comparing results with 
   those of another code or with experimental results)
 The latter one is the most dangerous, of course ...

CRASH : the code does not produce the result, because
 it stops unduly.

SLOWING DOWN : the physical result is correct,
 but the code does not go as fast as it should.
 For example, the reading of a restart file might 
 not be correct, or the SCF convergence 
 might not be as fast as it should.

OTHER : some information (not numerical results)
might be erroneous ...

In each class of problem, one can identify
MACHINE-DEPENDENT problems (on some platform, this
problem does not occur, not on others) as well as 
GENERAL problems.

Some of the problems listed below
have been reported by user, but have not yet been
examined for confirmation, in which case they are 
labelled "TO BE CONFIRMED". 

=================================================

P0. (Many reports)
SLOWING DOWN
The iterative procedures (SCF and determination
of geometry) still present instabilities,
in particular for metallic slabs

P2. (XG, 001223 + later) 
OTHER  (TO BE DONE)
GENERAL
The memory needs are not yet evaluated correctly
for the spin-orbit case and non-collinear magnetism
case.

P8. (GMR, November 2000)
SLOWING DOWN
GENERAL
restartxf for optcell/=0 might have a bug,
despite Test_v1#80
Identified in March 2001 by GMR : only happens when
restarting from a different, non-zero, optcell.
Should be corrected, but documented, now.

P9. (Massimilio Stengel, October 2000) 
CRASH
MACHINE-DEPENDENT : Compaq/DEC
Problem with non-linear XC correction, it seems

P15. (XG, 010103) 
OTHER
GENERAL
Should enforce coding rule related to length of file

P117. (Laurent Pizzagalli, 010622)
CRASH
Observed on PC AMD, atomic relaxation (ionmov==7),
no cell optimisation, stops in xfpack complaining
about ndim. See mail 010622.

P118. (XG, 010710)
OTHER
GENERAL (d/dk by finite differences)
Test_v3 #5 . Sensitivity to phase choice.

P121. (GMR, 010801)
NUMERICAL RESULT
MACHINE_DEPENDENT (Compaq ES40, Turing)
The use of fourdp , with fftalg 200 or 1xx
gives complex conjugate results. This was seen
in the process of merging the GW code with ABINIT.
To be examined in detail.

P204. (XG, 011020)
OTHER (TO BE DONE)
MACHINE_DEPENDENT
Test_v3#14 : the output file is machine-dependent,
because the spin-phase of spin-degenerate wavefunctions
has not been fixed...
Or, is there something more fundamental ??

P205. (XG, 011020)
SLOWING DOWN
MACHINE_DEPENDENT ??
On a Intel/Linux PIII 900 MHz, with PGI
compiler, slowing down in getghc,
due to the use of datastructures...
For example, 18% of the total time
in Test_v3/t10.out ... Argh ...
even more in Test_v2/t30.out ...

P220. (XG, 020114)
OTHER
GENERAL
Refs files in Test_physics should be updated.

P230. (MTijssens, 020306)
TIMING PROBLEM
MACHINE-DEPENDENT (P6, with IFC compiler v5.0)
The wall clock timing of one routine can be completely
wrong. Seems to come from the date_and_time
intrinsics, called by timein.f .
Previously, it was even causing
crash, in the headwr.f routine.

P250. (LSi, 020521)
CRASH
MACHINE-DEPENDENT (DOS/Windows)
Access violation Test_v2#7,26,30,90,92,96
and Tutorial#55,56

P302. (XG, 020305; DDKlug, 020313)
NUMERICAL ERROR
MACHINE_DEPENDENT (IBM 44P; SGI)
RF GGA : Test_v3#8,16,18,60,61,62,66
Problem with Response Function GGA tests.
The accuracy of the RF GGA Test_v3#16
is very bad on these machines : the acoustic
modes have large frequencies...

P331. (XG, 020528)
SLOWING DOWN
MACHINE_DEPENDENT (MACOSX)
Test_v2 #53 and 54
The computation of the dielectric matrix
is numerically incorrect. Fortunately, this
dielectric matrix is only used to precondition the
SCF cycle.

P332. (XG,020528)
OTHER
MACHINE_DEPENDENT (MACOSX)
Test_v3 #31 and 32
The Fermi energy is not printed out correctly.
 
P349. (XG021016)
OTHER
LIKELY GENERAL
Test_v3 #77. This test is not yet portable : accuracy
of fldiff was already tuned, but still problems
of portability.

P350. (XG030225)
OTHER
GENERAL
psp*cc.f the fifth derivative is not computed.

P402. (XG021227)
NUMERICAL ERROR
LIKELY GENERAL
Lattice Wannier Function only
Test_v3#96 and 97 are still undergoing changes

P404. (XG030103)
NUMERICAL ERROR
LIKELY GENERAL
fftalg 401 works, but gives a slightly
different answer than usual for Tfast#10.
To test this, replace the default value in indefo.f

P405. (XG030106)
CONVERGENCE PROBLEM
LIKELY GENERAL
Test_v3#15 : with very well non-SCF converged wavefunction (nnsclo=2),
the total energy at intermediate steps is lower than the
final energy !

P406. (XG030106)
CONVERGENCE PROBLEM
LIKELY GENERAL
Test_v3#85 : set iscf to 5 in the RF, one sees a very bad convergence...

P407. (XG030108)
NUMERICAL ACCURACY
INTEL with IFC compiler, EV67 under OSF, EV56 under Linux
Test_v3#14,77,85 with diffs compared to refs, that are a bit too large.

P411. (XG030515)
PORTABILITY PROBLEM
INTEL with IFC compiler, EV67 under OSF, EV56 under Linux
Test_v4#40 differences compared to refs are a bit large
Test_v4#42 sign of some eigenvectors might not be portable

P416. (XG030522)
CRASH
Seen on Intel/PC with PGI compiler, in parallel
Test_v1#75,80  do not work
Problem to read XFhistory part of a wavefunction file.

P41.9. (XG030719)
PORTABILITY PROBLEM
GENERAL
Test_v4#37 is not portable : the spin decomposition of the
spinor wavefunctions is not gauge invariant. This
test has been disabled.

P42.7. (DH030929)
OTHER
Should examine the d2sym3.f routine, giving extra
zeros in the output file. See mail
from DHamman, on 2003-9-29.

P43.3. (XG040218)
PORTABILITY of AUTOMATIC TESTS
On P6 with INTEL compiler, DEC EV67, DEC EV56
Test_v4#54,67,68,71,75,77,78 and
Tutorial#61-69 : 
Accuracy criterion to be adjusted,
or portability improved.

P43.12. (DRH040227)
NUMERICAL ERRORS
On a PC with IFC compiler version 5.0.1
Test_v4#77
Erroneous polarization

P44.2. (DHamann20040527)
NUMERICAL INACCURACY
For the treatment of pseudopotentials with pspcod=6 (FHI),
the non-linear XC core charge is not treated consistently
in psp6cc.f and in the rest of the code.
See Don's mail to the developers of 20040527 
See also input variable optnlxccc .

P44.12 (MM20040901)
PORTABILITY / NUMERICAL ERROR
IFC v7.0
From Mikami-san
Test_v4#62 : completely erroneous ?!

P45.5. (XG050220)
OTHER : PARALLEL TESTING
Test_v4#90 (CASINO output) crash in parallel (test_paral on grumpy).

P45.6. (XG050225) 
NUMERICAL PROBLEM (with ionmov=12)
Test_v4#97 has one strange output

P45.8. (XG050227)
SCRIPT PROBLEM
Too much errors observed when using the script parents : should change the rules
or the script

P45.14. (XG050619)
Libxc from Miguel is still to be tested.

P45.16. (N. Choudhury 050107)
In case of a very high symmetry unit cell, with atoms
placed such that the space group is of low symmetry, there
is a problem to recognize the space group.
This is illustrated by Test_v4#98.

P45.17 (B. Andriyevsky 050405)
Problem of normalisation of the epsilon'' from 
the "conducti" code ?!
A factor of pi (3.1416) might be missing.
See his mail of 5 April 2005 to the forum.
See also other mails exchanged on the forum.

P45.18 (D Hamann 050510)
NUMERICAL ERROR
With finite-difference ddk calculation
See his mail of 10 May, 2005.
(Excerpt : ... 

The problem is that 4.4.4 and 4.5.2 WILL run drf.in and produce incorrect
results, all related to the dataset 3 finite-differend ddk calculation.
The results are only somewhat incorrect, not obvious garbage. Here is a
small sample, Born charges from "2nd-order matrix" in the .out files:

Correct (from erf.out):
   1    1   1    4   -4.1367712586    0.0000000000
   1    1   2    4   -0.0863319602    0.0000000000
   1    1   3    4    0.0706059161    0.0000000000

Incorrect (from drf.out):
   1    1   1    4   -3.4782061716    0.0000000000
   1    1   2    4   -0.0832639192    0.0000000000
   1    1   3    4    0.0560776887    0.0000000000


Putting in some istwfk printing, I found that setting berryopt/=0 now forces
istwfk=1 for dataset 3.  The problem apparently is that dataset 2 has some
istwfk>1, and apparently dataset 3 is getting incorrect WFK's from dataset 2
and using them.  Why it doesn't re-converge them first isn't clear.

Setting istwfk=1 in dataset 2 (erf.in) fixes the problem and gets correct
results.  (My hack also had the effect of setting istwfk=1 in dataset 2 as
well as 3.)

Curiously, removing the dataset 2 calculation altogether and feeding the
kptopt1=1 WFK's from dataset 1 directly to the finite-difference ddk
calculation (nrf.in) also fixes the problem, despite the fact that dataset 1
has some istwfk>1.

Clearly something bad is going on in WFK readin, but only in certain cases.
I've never looked at this part of the code, and I'm afraid I can't divert
any more time now towards tracking this down.



P46.1. (XG050701)
PORTABILITY PROBLEM
Test tutorial Finite electric field 
alas_relaxdion.in (the last one)
does not work on my PC : it stops before the end.

P46.6. (XG050716)
MISC.
Variables nqptdm and qptdm should be substituted with nqpt and qpt.

P46.7. (XG050716)
PORTABILITY
DEC EV67 (Deccint)
afterscfloop.F90 only compiles with -O1 .
dyfnl3.F90 only compiles with -O1 .

P46.8. (XG050716 - modified XG050723)
PORTABILITY
Itanium 2 (Chpit)
Test_v4#30, initialisation differs widely from other machines ?!

P46.21. (XG051017)
Memory leaks
Using the g95 compiler with debugging option,
makefile_macros.g95_sleepy_debug  (-g)
Identified remaining memory leaks in
Test_v2#01 : hdr not cleaned (init in hdr_init routine)
Test_v3#30 : hdr not cleaned (init in hdr_io routine)
Test_v4#50 : in sortph.F90 

P50.1 (XG051130)
OTHER : PARALLEL CASE
in tests on sleepy with PGI compiler, make tests_abinip has the following problems :
tutorial#ffield_6 numerical result is wrong
tutorial#gw_7 The diff analysis cannot be done : the number of lines to be analysed differ.
v1#75 and 80 did not read (x,f)history 
v2#81,82 Berry phase with positive berryopt is not parallelized
v3#03,04,05 Berry phase with positive berryopt is not parallelized
v4#78 Fermi energy is wrong (finite electric field calculation)
v4#90 outqmc parallelism is not presently supported

P50.2 (XG051203)
(PORTABILITY)
On a PC/Linux, with g95 compiler.
g95 in sequential is OK, parallel compilation is OK,
but parallel execution fails :
-P-0000  leave_test : synchronization done...

 chkinp: machine precision is   2.2204460492503131E-16

 chkinp: Checking input parameters for consistency.
-P-0000
-P-0000 ================================================================================

Actually, this problem is already present in v4.6.5 . Parallelisation
with g95 never worked (this was also checked on intermediary patches leading to v4.6.5).



P50.3 (XG051203, confirmed XG060212, adapted XG060223, XG060311, confirmed XG070305)
(PORTABILITY)
On a PC/linux, With pathscale compiler.
The binaries cannot be linked properly when MPI is enabled.
One has to use
enable_mpi="no"
in the ~/.abinit/build/*.ac file .

make[1]: Entering directory `/home/gonze/ABINIT/ABINITv5.3.3/abinit-5.3.3p24_pathscale_mpi/src/main'
/usr/local/mpi-pathscale/bin/mpif90  -extend-source -fno-second-underscore   -o abinip  abinip-abinit.o ../../src/21drive/lib21drive.a ../../src/21paral_md/lib21paral_mdp.a ../../src/18seqpar/lib18seqparp.a ../../src/17suscep/lib17suscep.a ../../src/16response/lib16response.a ../../src/16geomoptim/lib16geomoptim.a ../../src/15gw/lib15gw.a ../../src/15common/lib15common.a ../../src/15rsprc/lib15rsprc.a ../../src/14occeig/lib14occeig.a ../../src/14iowfdenpot/lib14iowfdenpot.a ../../src/14wvl_wfs/lib14wvl_wfs.a ../../src/14wfs/lib14wfs.a  ../../src/13ionetcdf/lib13ionetcdf.a ../../src/13iovars/lib13iovars.a ../../src/13io_mpi/lib13io_mpip.a ../../src/13paw/lib13paw.a ../../src/13recipspace/lib13recipspace.a ../../src/13xc/lib13xc.a ../../src/13xml/lib13xml.a ../../src/13nonlocal/lib13nonlocal.a ../../src/12poisson/lib12poisson.a ../../src/12nlstrain/lib12nlstrain.a ../../src/12ffts/lib12ffts.a ../../src/13psp/lib13psp.a ../../src/12geometry/lib12geometry.a ../../src/12parser/lib12parser.a ../../src/12spacepar/lib12spaceparp.a ../../src/11contract/lib11contract.a ../../src/11util/lib11util.a ../../src/01manage_mpi/lib01manage_mpip.a ../../src/00basis/lib00basis.a ../../src/lib01cg/liblib01cg.a ../../src/lib01hidempi/liblib01hidempip.a ../../src/lib01fftnew/liblib01fftnewp.a ../../src/defs/libdefs.a -L../../lib/numeric -lnumeric -L../../lib/numericf90 -lnumericf90 -L/home/gonze/ABINIT/ABINITv5.3.3/abinit-5.3.3p24_pathscale_mpi/lib/linalg -llinalg
/usr/bin/ld: skipping incompatible /usr/local/mpich-1.2.4-pathscale-2.1-64/lib/libmpichf90.a when searching for -lmpichf90
/usr/bin/ld: skipping incompatible /usr/local/mpich-1.2.4-pathscale-2.1-64/lib/libmpichf90.a when searching for -lmpichf90
/usr/bin/ld: cannot find -lmpichf90
collect2: ld returned 1 exit status



P50.5 (XG051206)
(PORTABILITY)
Deccint alphaev67
tutorial#nlo_2
The numerical accuracy is quite bad (sixth digit).

P50.7 (XG051209)
NQXC and XMLF90 libraries 
In order to work properly, these libraries 
need the AC_FC_WRAPPERS  line to be uncommented
in configure.ac . However, in that case, the config
does not work for the PGI compiler.

P50.16 (XG061215)
DOC
Many documentation files should be updated still ...
Although most of the files put on the Web (.html) are OK.
In particular :
doc/developers/dirs_and_files is to be updated

P51.1 (XG060221)
(PORTABILITY)
The tests Tutorial#paw1* present too large variations
of precision (sometimes at a few digit level). The number
of lines produced by fldiff is quite large.

P51.4 (XG060222)
(PORTABILITY)
On tux (Compaq alpha EV56)
On deccint (Compaq alpha EV67)
Problem with the Optic utility.
On tux and deccint test_v4#57 is rather inaccurate

P51.10 (XG060311)
SLOWING DOWN
On tux, in parallel, some routines (inwffil, vtorho3:SYNCHRO) 
take a huge amount of time.
Speed should be checked systematically before this version 
can be put in production.

P51.11 (XG060312)
PORTABILITY
PAW : numerical results seem quite sensitive,
for the all series tutorial/paw1_*

P51.16 (MTorrent060505)
In the specific setting of directories used by MTorrent,
Problem Tv3#68 and Tv3#69 does not work, because
the CML file is not at the correct place

P51.22 (MGiantomassi060627)
The new value of rprimd is not stored in _WFK file .
So, restart cannot benefit from modifications of acell.
See his mail of June 27, 2006. See also P8.

P52.4 (XG060720)
PORTABILITY
Test_paral#M (GW in parallel) crash on Decci (Compaq/Dec EV67).

P52.12 (XG061009)
PORTABILITY
Tv5#1 crash on Decci EV67.

P53.1 (YP061218)
ETSF XC library
There is a memory leak in the calls to the ETSF XC library, which causes
ABINIT to crash.

P53.2 (closed)

P53.3 (closed)

P53.4 (closed)

P53.5 (closed)

P53.6 (closed)

P53.7 (closed)

P53.8 (XG070117)
bdgw should be made spin-dependent ...

P53.9 (XG070120)
abirules.pl has still troubles with some routines ...
Was not applied to v5.3.2
Should improve abirules in v5.4 , test with v5.3.3 or v5.3.4

P53.10 (XG070121)
During the application of the abirules script (patch-40 to patch-56
in the abinit-devel--merge--5.3 branch),
the numerical values obtained from test v5#04 has changed (1e-7).
There might be a complex(dpc) changed to complex ?!

P53.11 (XG070121)
Still have to get rid off old iscf value for tutorial and tutorespfn automatic 
testing, as well as updating tutorial html files.
Later, get rid off old iscf value in other automatic tests.

P53.12 (closed)

P53.13 (closed)

P53.14 (closed)

P53.15 (closed)

P53.16 (XG070223)
PORTABILITY  / CRASH
All PAW tests, on PC /PGI 4.0 
Need to compile 13paw with -O0, then everything is OK ...

P53.17 (close)

P53.18 (XG070211)
PORTABILITY / NUMERICAL ACCURACY
Test_v5#21 on IBM 44P (Power 3 - Dirac)
Too large variability of the results

P53.19 (XG070211)
PORTABILITY / NUMERICAL ACCURACY
Test_v4#87&88 on IBM 44P (Power 3 - Dirac)
Completely wrong numerical results. Should be easy to debug.

P53.20 (closed)

P53.21 (XG070211)
PARALLEL TESTS
Test_paral#N does not work under Mac OSX.

P53.22 (XG070302)
PARALLELISM : EFFICIENCY
outkss.F90 actually works k point by k point, sequentially ...
In the k point and spin loop, one should write locally
vkb,vkbd, en and wfg , without communication, then
transmit them in a separate spin and k point loop.
The k point loop only starts at 1020 , the write start at line 1506.

P53.23 (XG070305)
NETCDF
Tetsf_io#01
the ncdump of the DEN_etsf_io.nc reveals that some
mandatory fields are missing.
Also, the testing should involve ncdump, and comparison with a reference txt file.

P53.24 (XG070305)
PARALLELISM : on IBP 44P (Dirac)
Compilation seems to work, but testing 
fails for reasons related to reading of tests.env file
on one side, and command to be issued to run the
parallel case...

P53.25 (closed)

P53.26 (closed)

P53.27 (XG070401)
NUMERICAL ERROR
GW parallelism over bands
Using two or four procs does not give the same answer as with one proc.
The test N has been temporarily desactivated, as well as gwpara=2 .

P53.28 (XG070401)
Build system
make multi    does not work on Lemaitre (Opteron SMP) because 
 netcdf should be compiled before parallel lib

P53.29 (XG070401)
Build system
make multi    does not work on Fock (IBM Power 5) 

P53.30 (XG070402)
NUMERICAL ERROR
IBM 44P , PAW antiferromagnetism
Test_v4#08
An unoccupied electronic eigenvalue is not converged ?!
Should check whether there is a degeneracy ...
