FP-LAPW user page

I) Program download

The full WIEN97 program, corresponding to the versions 97.7, 97.8, 97.9 and 97.10, is stored locally on our file-server at

/f21/f/lapw/WIEN97-2000 If you start a completely new type of calculation, use the latest version. However, if you want to compare with results achieved earlier, we recommend using exactly the version employed in the earlier computations. The versions indicated above are the versions currently used by one or the other in the theory group. In the above indicated directory, you will find subdirectories bearing the name of either of the mentioned versions. Copy the version you want to work with to your home directory and unpack the tar file using:

 tar -xvf wien97.*.tar 
 cd WIEN97 
 gunzip *

Adapt the compiler options in the Makefiles according to the machine you will be working on and compile. Further detailed information on how to install the program can be found in the user-guide, which is one of the files in the package. Alternatively, if you already have a running version of WIEN97, the subdirectory /up-dates provides tar packages containing just the files you need for the update. The latest updates of the WIEN 97 program, together with other WIEN 97 related information can also be found at the homepage of the group in Vienna, at http://www.tuwien.ac.at/theochem/wien97/. Joining the WIEN mailing list as soon as possible after starting is highly recommended - it sometimes trashes your mailbox, but one can learn a lot from it...

II) Compiler options

Currently, FP-LAPW calculations are done on the following machines: sp2, NEC, and HP. Additionally PC's and some old xtheo machines are used for smaller calculations or data analysis. Compiler options are given for all these platforms below. There is also a working WIEN97 version for the Cray. However, the latter derived from a local version of the WIEN97 code and exhibits some differences with respect to the WIEN97 version as described in the standard manual. For further information on this code, please ask Juarez.

III) Non-standard implementations

A surface quantity that is often required is the work function. Click here to see how to implement it. A nice feature is also to get the center of gravity of your bands. Click here to see how to implement it.

IV) Improving the efficiency of calculations at surfaces

Surface calculations, especially for larger surface unit cells, are time-consuming. Below there is a list of tricks, which help to speed-up a calculation. Please note, that these tricks may not help in all cases - you have to check for your particular system, which of them are useful.

  • Iterative Diagonalization

    This is a 'must' for surface calculations. Setting the -it switch as described in the WIEN97 manual, the program will use a Block-Davidson method to approximately diagonalize the Hamiltonian matrix only in the subspace corresponding to the eigenvalues really required. The speed-up, especially for large cells, is enormous. However, one has to use this scheme very carefully.
    i) Set the upper energy window in the file case.klist properly: The higher you set this upper limit, the less speed-up the iterative diagonalization will bring you. On the other hand, if you set it too low, the scheme will get imprecise. So, how to determine the value? A pragmatic way is to set it in such a way, that the calculated number of eigenvalues (check the list in case.scf) is equal to the number of valence electrons as given in case.in2 (NE). As each calculated eigenvalue may be occupied with two electrons (up and down in spin-unpolarized calculations), you end up with an equal number of occupied and unoccupied states in your calculation, which allows for a sufficient precision in the iterative calculation and a good speed-up.
    ii) Even if you have set the energy window properly, it's still good to check the precision of your calculation. Additionally, the forces that result from the iterative diagonalization are not exact - they are still good, though (depends on how precise you want to have them). Hence, after having reached self-consistency it's advisable to do one full diagonalization in the end. If your :DIS stays low and your energy doesn't change, you're on the safe side. If it does, trouble's ahead. Some of us use full-diagonalizations also during the self-consistency cycle, which may enhance the convergence. After every ten iterative diagonalizations, a full one is done - a run_lapw script that does this job can be found at /f21/f/lapw/WIEN97-2000/fhi-subroutines. This script works for the version 97.7, but should also work with other versions, except maybe for some variables that have to be renamed. To get information about this script type 'run_lapw_dasilva -h' or ask Juarez.
  • Starting from an atomic charge density

    The charge density given after lstart/dstart is pretty far away from where you want to go. It takes a lot of iterations to reach self-consistency and hence a long time to get there. However, you don't need a high precision in the first iterations, because your charge density is bad anyway. Hence, the following tricks help to tremendously speed up this first self-consistency cycle:
    i) Use low k-meshes and progressively increase their density: start with one k-point and go to self-consistency, then create a denser k-file and repeat the job, and so on. How many such steps should be done until the full set of k-points is reached depends on your system and needs to be checked.
    ii) Similarly, you may use a low number for the (l,m) type of expansions in the first iterations. Especially the calculation of the non-muffin tin matrix elements in lapw1 hits hard on the CPU time - using a lnsmax = 4 in the beginning is absolutely sufficient.
    iii) The cutoff may be reduced in the beginning, too.
  • Geometry optimizations

    If your initial geometry is not very far away from the relaxed geometry (good initial guess), the resulting forces are moderate and consequently the geometry changes are small from one step to the other. In such cases, the charge density resulting from the prior geometry will not be very different from the one appropriate for the current geometry. In such cases, new self-consistency is typically reached already in 10-15 iterations and the tricks mentioned above are not very useful. They would only converge your already quite good charge density away towards a form corresponding to the reduced basis set and afterwards you would have to converge it back to the high basis set. The only speed-up in such cases is to check on your force convergence criterion (-fc). If your forces are still of the order 20-50 mRy/au, why would you want to converge them to +/- 0.5 mRy/au? Already knowing them roughly will initiate a geometry move into the right direction. In the end, you have to reduce the force convergence criterion according to your forces, of course. It doesn't make any sense trying to minimize the forces below say 2 mRy/au, if you only calculate them with a precision of +/- 2 mRy/au...
    If your initial geometry is very far off, because you simply have no clue about your geometry, the geometry steps are large. In such cases, using the tricks given above for starts with an atomic charge density might be helpful. It could then also be advisable to do a coarse geometry optimization first - with a poor basis set and low k-mesh. After your structure is relaxed to a certain degree, i.e. your forces are moderate or low, switch to the good basis set and do the rest of the optimization. When using a low k-mesh. a high smearing factor in case.in2 simulates a denser k-space sampling and you may speed up convergence with it. Ultimately, you have to finish your calculation with a decent smearing, of course.

This page is maintained by Karsten Reuter.


Page last modified on February 15, 2012, at 02:03 PM CET