---

FAQ

This document provide answers to very basic questions about ABINIT, as well as to more elaborate questions. We have taken the DACAPO FAQ pages as a model.

Copyright (C) 2003 ABINIT group (MMikami, JMBeuken, XGonze)
This file is distributed under the terms of the GNU General Public License, see ~ABINIT/Infos/copyright or http://www.gnu.org/copyleft/gpl.txt .
For the initials of contributors, see ~ABINIT/Infos/contributors .

Summary

• General
• What is ABINIT ?
• What can ABINIT do ?
• What cannot ABINIT do ?
• Does it run in parallel ?
• Is there a summary about ABINIT ?
• Is there a review paper on ABINIT ?
• What is the copyright conditions ?
• I like to contribute the ABINIT project in any way. How ?
• Is there a graphical user interface (GUI) ?
• Is there a mailing list (ML) ? 
• I think there is a bug - making a bug report
• I didn't receive any response to my question on ML. Why ?
• Is there a tutorial ?
• Is there a good pseudopotential database ?
• Are there (Vanderbilt-type) Ultrasoft pseudopotentials in ABINIT ?
• How do I generate a new pseudopotential ?
• Recent studies based on ABINIT ?
• I am a complete newbie. How do I get started ?
• The documents seem too many for a newbie like me to read through. How to find relevant documents for my questions ?
  
• I am new to Density Functional Theory/Pseudopotential+Planewave: What should I know ?
• Why do my ABINIT results differ from experimental results ?
• (to be added, if any)
  
• Installation of ABINIT
  • What hardware/software do I need ? How to install ?
  • How to update ? How to catch up the latest versions ?
  • I find errors during compilation. How should I do ?
  • Is my installation successful ?
  • I cannot make "abinip". What should I check ?
    
  • Linux_cpp_P6 : /lib/cpp failed to remove some C style comments
  • Linux_cpp_Alpha : /lib/cpp failed to remove some C style comments
  • Linux_Intel : problem to run abinit with dynamic IP allocation
  • Win2K_Intel : How to install ABINIT on Windows2000 with PGI ?
  • Linux_Intel : compiler versions and options for IFC 
  • MacOSX_Absoft: buffer allocation failed
  • IBM SP : Memory allocation error
    
  • (to be added, if any)
    
• Setting up calculations
• How can I quickly setup a calculation for my model ?
• Is there anybody willing to give me an input file example?
• How to find test cases relevant to my target system ?
• Is there a rule of thumb for parameter settings ?
• How should I choose the key calculation parameters ?
• (to be added, if any)
  
• Tips to use ABINIT
  • How to choose the q-points ?
  • How to set "sciss" with other parameters ?
  • Compaq-Digital Tru64 Unix : "forrtl: error (65): floating invalid" in non-SCF cycles.
  • Negative frequencies in phonon band structure
  • Non-zero phonon frequencies at Gamma point ?
  • ASR: large changes in phonon frequency
    
  • Alchemical mixing of PSPs 
  • Slab calculation
  • GW calculation
  • Spin-orbit coupling
  • Berry phase
  • Bader charge analysis
  • FHI98PP + core correction
  • Restarting calculation
  • nbands for metallic case
  • scfcge: ERROR - Potential-based CG line minimization not converged
  • How to prepare input data for my crystal ?
  • energy selective charge density
    
  • (to be added, if any)
• Parallelisation of ABINIT
  • SGI Origin 2000 : speed-up problem
  • parallelization over bands in ABINIT
  • (to be added.if any)
    
• Utilities
• kptgen : accuracy of atomic positions
• Misc. trouble shooting
• Reading old WF/DEN/POT files with v3.4 (and later versions)
  
• Fermi energy is not printed out ?
• Negative value of DOS ?
• Tetrahedron method
• PAW method
  
• unit of oscillator strengths ?
• latest definition of Bohr in Angstrom
• What is IFC ?
• I cannot download a file "foo" from "ftp.abinit.org/pub/incoming". Why ?
• Why are different symmetries assigned by different versions of ABINIT ?
• Why do ABINIT and other calculation methods produce different results ?
  
• (to be added, if any)
  

• VASP Data Viewer 
• Scilab (free MATLAB lookalike for linux)
• XCrysDen 
• OpenDX : see also for examples
• Jmol 
• VENUS
• XtalEdit
  
• (to be completed...)

• Announce List (announce@abinit.org - Announce of new ABINIT release, urgent bug reports, etc.)
• Forum List (forum@abinit.org - The ABINIT Users Mailing List)
• Advisory Committee List (advisory@abinit.org - The ABINIT Advisory Committee Mailing List)
• Developer List (developer@abinit.org - The ABINIT Developer Mailing List)

• It might be a FAQ. Please check this FAQ list carefully.
• Answers might be already available somewhere in ~ABINIT/Infos/*. Please try
       grep -i (keyword for your question) *
  at the directory, and the directries therein.
• Answers might be already available in the forum archive. Please try keyword search there.
  
• Your question might be unclear with insufficient disclose of your case.(Readers cannot guess what you are doing !) Otherwise, your mail might be too lengthy/winding. Please write specific/concise e-mail for readers to follow. Attachment of input/output could help.
• Your question might be too tough to respond quickly. Otherwise, those who have answers have less time to reply at that time, unfortunately. Please be patient ...
• Your question would be beyond our interest. Please ask at other sites.
• Other possibilities.
  (e.g. Your question might suggest that you give up efforts to learn ABINIT.)
  

• Troullier-Martins pseudopotentials for most of the elements in the periodic table, generated by A. Khein and D.C. Allan
• Goedecker-Teter-Hutter pseudopotentials for selected elements
• Hartwigsen-Goedecker-Hutter pseudopotentials for most of the elements in the peri odic table.
• Teter "extended norm-conserving" pseudopotentials for selected elements
• Fritz-Haber-Institute (FHI) pseudopotentials for selected elements (Troullier-Martins scheme)
• LDA core-hole pseudopotential files for selected elements

• Fritz-Haber-Institute (FHI) pseudopotentials for selected elements (Troullier-Martins scheme)
• Hartwigsen-Goedecker-Hutter pseudopotentials for selected elements

1. Read this (~ABINIT/Infos/welcome.html")
2. Read installation_notes (~ABINIT/Infos/Installation_notes/install_*.html).
3. During installation, read "New user guide" (~ABINIT/Infos/new_user_guide.html).
4. Then try Tutorials (~ABINIT/Infos/Tutorial/welcome.html), consulting help_files (Abinis (main), Abinis (respfn), Mrgddb, Anaddb, AIM (Bader)) and "List of input variables" (~ABINIT/Infos/keyhr.html) when needed.
5. Then try Test_*. (See "README" file to know how to run the tests) Please be aware that some input parameters are deliberately reduced for short CPU time.
6. Then go into the ~ABINIT/Infos directory. Read memos, references cited in bibliography, ... etc.

• G.P.Srivastava, "Theoretical Modelling of Semiconductor Surfaces"(World Scientific, 1999)
• R.M.Martin, "Electronic Structure" (Cambridge University Press, scheduled in 2004)
  
• (To be completed ... Any suggestions ?)
  

On an Intel P6 running Linux, I found that /lib/cpp failed to remove some C style comments, thus making compilation of abinis.f impossible.
By using a different version of cpp (/usr/lib/gcc-lib/i386-redhat linux/2.7.2.3/cpp)
I managed to get around this problem.

+----------------------------------------------------+
Andrew Horsfield e-mail: horsfield@fecit.co.uk
FECIT, 2 Longwalk Road, Stockley Park, Uxbridge,
Middlesex UB11 1AB, United Kingdom.
phone: +44-(0)181-606-4653 FAX: +44-(0)181-606-4422
+----------------------------------------------------+

(From Vitaliy Godlevsky, 2 March 2000)

Summary: Installation of Abinit under Alpha LINUX (Red Hat)

(Hardware : Dual Alpha DEC 21264 500 MHz system)
While compiling abinit by Compaq Fortran compiler "fort" I used Linux CPP (/lib/cpp).
There was a problem with C style comments (/* */) that weren't removed from the code. Using CPP without -C option resulted in removing C++ style comments ( // ). This, in turn, messed up input subroutines which rely on fortran90 string operations //
The solution was to use C preprocessor provided by fort which is invoked with "fort -P".
Since fort -P file.f write the preprocessed file in file.i, I had to modify some makemake scripts changing the part concerning CPP command by something like:

abinis.o: abinit.f

\$(CPP) \$(CPP_OPTS) \$(CPP_FLAGS) abinit.f
\$(FC) \$(MAIN_ROUTINE_FFLAGS) \$(FFLAGS) -c abinit.i
mv abinit.o abinis.o
rm -f abinit.i

PS : see the file Machine_dept_files/DEC/makefile_macros.DecLinux

I modified /etc/hosts to include:

127.0.0.1 dmt.ipm.virginia.edu dmt

I used the loopback IP as my machine has never been IP'd due to dynamic IP allocation.
So, after adding dmt to the /etc/hosts file, abinis appears to run.
Also, there's the ability to set the environmental variable PGHPF_HOST.
i.e.

set PGHPF_HOST dmt

or

setenv PGHPF_HOST dmt

+----------------------------------------------------+
Dave Tater
teter@virginia.edu
+----------------------------------------------------+

Answer by Luc Sindic:
         First, you need to have a minimal knowledge of Unix systems 
because PGI Workstation is a "Bash" unix shell under Windows. Read the
"PGI Workstation documentation" and record the differences with a DOS prompt 
window (e.g. / for \ ; cp for copy ; ls for dir, ...)
         If this is not already done, you have to "unpack" the Abinit
package under PGI Workstation, in a clean subdirectory called ABINIT_HOME below, 
with the following commands:
                 gunzip src_test_3.3.3.tar.gz
                 tar xvf src_test_3.3.3.tar

         Then, browse the file
                 ABINIT_HOME\Infos\Installation_notes\install_v3.3.htm
You will see how to make the executables. You will also see that you need 
to have Perl installed on your PC and how to get it if necessary.
         Before making the executables, you have to customize your 
"makefile_macros" file that describes the compilers paths, options, ...
You can derive it from the one I'm using on my PC:
   ABINIT_HOME\Machine_dept_files\Intel_P6\makefile_macros.PGIwk.3.0

Doug Ritchie wrote:

> I have a question.
> I did a parallel run (on a SGI Origin 2000) on the simple test case of an energy
> band calculation on Si with input file starting as:
>
> # Si in diamond structure; 60 special points in core; low ecut.
>
> acell 3*10.26311
> densty 1.2
> diemac 12.0d0
> ecut 5.8
> mkmem 60
> natom 2 nband 4
> ngfft 3*16
> nkpt 60
> nline 3
> nstep 15
> nsym 24
> ntype 1
> rprim 0 .5 .5 .5 0 .5 .5 .5 0
> symrel
> ...
>
> This runs very quickly and the times are:
>

np	t(0)	sum(t(p))
1	101.4	101.4
2	52.9	105.7
3	37.8	113.5
4	30.0	120.2
5	25.4	127.2
6	22.1	132.1
10	15.7	157.2
12	14.2	170.8
15	12.7	189.8
20	11.2	224.1
30	9.8	296.3

> which isn't great, I am wondering if I am doing something obviously silly.
> I did take np to be an integral divisor of nkpt = 60
>
 
Xavier Gonze wrote:

I think that you are doing the right things. Simply, the test case is not
suited for as many processors. I have to mention a few things :

• the parallelisation is only done over the k-points, and in abinip
  there are some sequential steps that last together a few seconds (4-6 secs) before and after the k-point loops.
• in this test case, for each k point, the computation inside the k-point loop
  is on the order of 1-2 seconds. This test case has been chosen to run fast,
  while still sufficiently efficient for 4 and 10 processors
• this k-point parallelisation needs very few communication, and that is why it
  is called 'efficient'. It works well even on a cluster of workstations linked
  by Ethernet 100 Mb/s...

So, what you observe is the influence of the sequential part,
and there is nothing to do without modifying the test case, I think. 

• a better speed-up is obtained when systems with higher cut-off energy (ecut)
  and number of bands are treated. These usually take much more time, and the
  ratio between the sequential part of the code to the parallel part of the
  code decreases. But except for some metallic systems,
  one needs fewer k point (between 1 and 10 let's say) in realistic situations.
• in order to obtain an artificially better speed-up, you can for example change ecut,
  and instead of ecut 5.8 , use ecut 20 (unrealistic for Si, but allright for tests),
  and also instead of nband 4 , use nband 8.
  By these operations, the time needed per k-point will be multiplied by about 16.
  The time of some sequential parts will also change, but the behaviour should already be better...

+----------------------------------------------------+
Doug Ritchie
ritchie@neon.sao.nrc.ca
+----------------------------------------------------+

When I used KPTGEN today (May 27, 1999), I had a curious experience.
(In fact, no curious... Only I might have not realized the following.)

If I use the following input for "kptgen", it fails.

---

Example unit cell

7.1431642 7.1431642 12.402272 acell
0.8660254037844386 0.5 0 -0.8660254037844386 0.5 0 0 0 1 rprim
5 3 natom, ntype
1 2 2 3 3
0.00000 0.00000 0.00000
0.33333 0.66667 0.29000
0.66667 0.33333 0.71000
0.33333 0.66667 0.64000
0.66667 0.33333 0.36000
0 0 ibrav, inpgd
0 nkpt
4 4 4 0 0 0 Monkhorst-Pack indices and origin for grid

---

The error message in standard output is as follows:

cpointg error: atom 2 doesn't fit symmetry 2
rotated coord -2.062033266329 -3.571617815821 3.596658880000
other atom 2.062095127946 3.571582100000 8.805613120000
difference -4.124128394275 -7.143199915821 -5.208954240000
phases -.500036275549 -.499981861897 -.876306680044
rotation matrix: -.50 -.87 .00 .87 -.50 .00 .00 .00 1.00
nonsymmorphic transl: .000000000000 .000000000000 .000000000000

---

But If I use the following input (the digits of "xred" are increased),
it did work !

---

Example unit cell

7.1431642 7.1431642 12.402272 acell
0.8660254037844386 0.5 0 -0.8660254037844386 0.5 0 0 0 1 rprim
5 3 natom, ntype
1 2 2 3 3
0.000000000 0.000000000 0.000000000
0.333333333 0.666666667 0.290000000
0.666666667 0.333333333 0.710000000
0.333333333 0.666666667 0.640000000
0.666666667 0.333333333 0.360000000
0 0 ibrav, inpgd
0 nkpt
4 4 4 0 0 0 Monkhorst-Pack indices and origin for grid

---

Thus I really realized that the digits of "xred" is very important and that enough digits of "xred" are prepared in all the input examples
(in.*). (The criterion condition (the parameter of "tolerance") in cpointg.f seems to be set severely.)

+-------------------------------+
Masayoshi Mikami
Mitsubishi Chemical Corporation (Research and Development Division, Yokohama Research Center)
Phone: +81-45-963-3265 Fax:+81-45-963-3947
E-mail: mmikami@rc.m-kagaku.co.jp (office), mmikami@yk.rim.or.jp (home)
+-------------------------------+

(From Patrick Tepesh, on 13/9/1999)
Can you give me some hints or refer me to a paper to help me choose q-points for integrating to obtain free energies?
My first impulse is to just use the same MP grids as for the electronic structure calculations,
but it seems from looking at a few papers that this might not be the way most people do it (the papers I've seen so far do not give much detail about the choice of the grid).

(From Masayoshi Mikami, on 27/9/1999)
Which is the smartest way to choose the q-points for finer mesh in Hexagonal (or Trigonal) Lattice case ? (Is it the same way in the choice of "kpt" in SCF-calculation (MP-mesh)?)

(Response)
About the q-points : usually, one needs in any case the gamma point (for effective charges and dielectric constant).
This point is not part of the usual Monkhorst-Pack (shifted) grids. Unlike with the k-points for the electronic structure calculations,
the workload of each q-point can be very different : if there are remaining symmetries, they can be used fully : the code automatically select the "primitive" perturbations, and do not care about their symmetric. The code even decreases the number of k points if there is still some residual symmetry to be taken into account for one perturbation. Even if unshifted MP grids usually lead to more q-points than shifted grids, each of these q point may be more symmetric, and thus much faster to compute.
The current attitude (see the work in Ferroelectrics 206-207, pp. 205-217 (1998), especially p. 207) is to use a set of MP grids who share common q-points, so that one can judge of the convergence by simple "data reuse"...

(From Masayoshi Mikami, 27/9/1999)
How to set "sciss" with other parameters (or dataset) ...
I tried another input, just adding "sciss4 0.0735294117647" in the input below. (The calculated band gap is smaller than experimental one by about 2 eV. Thus the above "sciss4" corresponds to 2 eV.) It affected phonon-frequencies as well as Born effective charges and dielectric tensors... Is this really expected ?! We should not set both "rfphon 1" and "rfelfd 1" at the same time when non-zero "sciss" is applied ?

(Response)
When a non-zero "sciss" is applied, all the response functions are affected. So, the reaction of the code is normal. On the other hand, within the present understanding of the scissor approximation, in order to get physical results, the scissor should only be applied to the dielectric tensor calculation (with rfelfd 1). So, it is right that rfphon 1 and rfelfd 1 calculations should be done separately when a scissor is used.

(From Fabio Finocchi, 6 Nov 2000)
This FAQ is addressed to the owners of Compaq-Digital Tru64 Unix workstations on which the sequential version abinis runs. On these machines, a bug was noted at the very beginning of the non-SCF cycles, just after the calculation of the band residuals, resulting in a message like this:
" forrtl: error (65): floating invalid "

After some tests, I noted that - for a given system - this happened when increasing the number of bands, rather independently of

1. their occupancy
2. the number of k-points
3. the number of G-vectors.

Thus, I guessed that the bug should concern the linear algebra routines (BLAS) used for the calculation of band residuals. Indeed, the latters turned out to be wrong, through a comparison with the runs carried out on another machine. Rather than looking into the code, I tried to link with the BLAS routines supplied with the ABINIT package, by explicitly modifying the machine dependent makefile. This action fixed the bug, on Tru64-ev6 as well as on Tru64-ev56 systems (that is, for two distinct processors but using the same operating system). The modification in the makefile_macros file is below.
If anybody is aware of other less empirical remedies to the same bug, or if someone noted other bugs linked to the use of the BLAS library provided with the Compaq Tru64-Unix workstations, please let me know.

# Definition of libraries
    #BLAS_A=-ldxml
    BLAS= Lib_blas
    BLAS_A= $(BLAS)/blas.a -ldxml
    LIBS= $(LAPACK_A) $(FFTS_A) $(NUMRECIP_A) $(BLAS_A) 

Fabio Finocchi