-
Notifications
You must be signed in to change notification settings - Fork 139
FAQ
wannier90 is a computer package, written in Fortran90, for obtaining maximally-localised Wannier functions, using them to calculate bandstructures, Fermi surfaces, dielectric properties, sparse Hamiltonians and many things besides.
The most recent release of wannier90 may be found on the website http://www.wannier.org. However, the most recent stable version may be obtained by cloning the develop branch of the wannier-developers/wannier90 GitHub repository.
Yes! wannier90 is available for use free-of-charge under the GNU General Public Licence. See the file LICENSE that comes with the wannier90 distribution or the GNU homepage at http://www.gnu.org.
Yes! The examples directory of the wannier90 distribution contains input files for a number of tutorial calculations. The doc directory contains the accompanying tutorial handout.
Yes! Starting from release 3.0 you can found a solution booklet in the doc directory.
There are a number of options:
- The wannier90 User Guide, available in the doc directory of the distribution, and from the webpage (link)
- The wannier90 webpage for the most recent announcements (http://www.wannier.org)
- The wannier90 mailing list (see http://www.wannier.org/forum.html)
- For technical issues about the wannier90 code, the GitHub repository (see https://github.com/wannier-developers/wannier90), where you may raise issues or ask questions about the code.
Yes! You need to register: go to http://www.wannier.org/forum.html and follow the instructions.
- Check and double-check. Make sure it’s a bug.
- Check that it is a bug in wannier90 and not a bug in the software interfaced to wannier90.
- Check that you’re using the latest version of wannier90.
- Check if an issue or a pull-request has already been raised to solve the same bug.
- Raise an issue on the GitHub repository (https://github.com/wannier-developers/wannier90/issues)
- If you know how to fix the bug then make a pull-request. Your fix must comply to the wannier90 contributor guides in order to be accepted (see https://github.com/wannier-developers/wannier90/wiki/ContributorsGuide)
We’re always happy to listen to suggestions. The best way to report a suggestion/wish is by raising an issue on the issues page (https://github.com/wannier-developers/wannier90/issues) of the wannier90 GitHub repository. In this way, the wannier90 developers have a record of your suggestion and can attach a label to it. This will also increase the chances that your idea will be implemented by other contributors. Alternatively, you may send an email to the wannier90 developers. N.B. A convention for the use of this mailing list is to sign with your name and affiliation in all posts, and we would all be very grateful if you would please adhere to this convention.
Great! There’s always plenty of functionality to add. The best way to contribute is to make a pull-request to the develop branch of the wannier90 GitHub repository (https://github.com/wannier-developers/wannier90). Your contribution must comply to the wannier90 Contributors guidelines (see https://github.com/wannier-developers/wannier90/wiki/ContributorsGuide)
Our Swiss bank account number is... just kidding! There is no need to donate anything, please just cite our latest paper (see the > How to cite > section on the home page of the wannier90 GitHub repository) in any publications that arise from your use of wannier90.
Follow the instructions in the file README.install in the main directory of the wannier90 distribution.
Not at present.
Yes. wannier90 works on top of an electronic structure calculation. At the time of writing there are public, fully functioning, interfaces between wannier90 and Quantum ESPRESSO (https://www.quantum-espresso.org/), abinit (http://www.abinit.org), siesta (https://launchpad.net/siesta), VASP (https://www.vasp.at), Wien2k (http://www.wien2k.at), fleur (http://www.flapw.de), OpenMX (http://www.openmx-square.org/), GPAW (https://wiki.fysik.dtu.dk/gpaw/). To use wannier90 in combination with Quantum ESPRESSO (a plane-wave, pseudopotential, density-functional theory code) you will need to download it either from the webpage http://www.quantum-espresso.org or from the GitLab repository of the Quantum ESPRESSO Foundation https://gitlab.com/QEF/q-e. Then compile the pw program and the wannier90 interface program pw2wannier90. For instructions, please refer to the documentation that comes with the quantum ESPRESSO distribution.
For examples of how to use pw and wannier90 in conjunction with each other, see the wannier90 Tutorial.
It is worth mentioning that many of the general issues arising from the use of wannier90.x and postw90.x may be solved by simply making sure to have the most recent version of these programs installed, which can be downloaded from the wannier-developer repository on GitHub.
Our experience is that when computing Wannier functions for an isolated set of bands, setting the projections to random usually works just fine - in other words the minimisation is fairly robust to the initial guess for the WFs.
When computing WFs for entangled bands, this is less true and it is usually important to provide both a set of projection centres that correspond to your chemical intuition for where the final WFs might be, and to adjust the frozen/inner and outer energy windows appropriately to include the states that are needed in the final subspace. This needs some trial and error and experience.
Alternatively, one can use the SCDM-k algorithm [Damle, Lin arXiv:1703.06958], which is parameter-free for insulators, and only needs two parameters for system with entangled bands. This method is currently implemented in pw2wannier90.x, see user guide for the definition of the keywords and example 27 of the wannier90 tutorial.
If spinors=true
in the .win file, then a spinor_projections block is written to the .nnkp file; otherwise it's a projections block. In both cases, the projections are defined in the .win file within the projections block (see Chapter 3 of user guide). This was done to preserve backward compatibility when spinor projections were added.
Assuming you have no entangled bands (which is the most common scenario for this error to appear), you have to match number of bands and number of wannier functions with the number of projections defined. The number of bands must take into account whether there are excluded bands or not, i.e. number of bands = total number of bands in the valence manifold - number of excluded bands.
Kramers degeneracy broken by Wannier interpolation OR interpolation of bands on equivalent k-paths gives different result
Try setting use_ws_distance = .true.
in the .win input file, it might be able to solve both problems.
This is usually an error arising when using a fine k-point grids. The problem might be solved by specifying the unit cell parameters more precisely.
Setting guiding_centres=T
in your wannier input file might resolve the issue with the large spreads.
The key point is that if you have a system with spin-orbit coupling - then you cannot globally divide the states into spin-up and spin-down.
The keywords spin_component = up
and spin_component = down
in pw2wannier90 are not valid. Pw2wannier90 should probably be improved to give a more sensible error message in this case.
In wannier90 the default units for the coordinates of the unit cell are Angstroms. To instruct the program that you want the coordinates in Bohrs you need to add Bohr
to the first line inside the unit_cell_cart
block. If, for instance, in the scf file the coordinates of the unit cell are given in 'alat' and also you have specified celldm(1), then the coordinates will be in units of Bohr. In the wannier90 input file (.win), in order to have the same coordinates, you will have to write
begin unit_cell_cart
bohr
...
<-- coordinates in the scf file multiplied by celldm(1)
end unit_cell_cart
Actually, they are the same but printed in different units, Wannier90 uses Ang^-1, QE uses 2pi/alat units. If you multiply the QE reciprocal vectors by 2pi/a = 2*pi/alat you exactly get the Wannier90 ones.
The number of bands has to be an integer multiple of the number of cores you are using (or of NPAR, but it does not work with wannier as far as we know). So, if you use 64 bands for the scf calculation, then use 64 cores (or 32, or 16...) for the wannier part. Otherwise VASP will increase the number of bands to the to the smallest integer multiple of the number of cores that is larger or equal than the specified value in the INCAR or the one read in from the WAVECAR file.