[Wannier] parameter to control convergence
jryates at lbl.gov
Mon Aug 28 03:52:04 CEST 2006
On Thu, 24 Aug 2006, Tadashi Ogitsu wrote:
> 1. I have found that those MLWFs with unusually large spread vanish if I
> increased the k-points grid size. I was using 2x2x2 before and now I'm using
> 4x4x4. Does it make sense? (Now, all of the MLWFs look reasonably localized)
> #Since the unit-cell size is big with beta-boron, I thought 2x2x2 grid is not
> that bad, but this seems to tell me that I cannot go cheap...
Given the size of the unit cell I would expect it to be possible to find
a set of well-localised WF from a 2x2x2 grid.
I think the behaviour you see could arise when you try to describe a
metallic system with a number of WF that is very close to the number of
electrons (/2). This goes back to the points Nicola made in his first
email regarding a "natural"/"physical" num_wann. So I would suggest trying
to extract a larger number of WF.
You might find the discussion of "maximum localisation per WF" in
Thygesen et al Phys. Rev. B 72, 125119 (2005) relevant.
However, before trying this, as quick test re-run the 2x2x2 calculation
adding 'guiding_centres = T' to the input (see section IV-D-2 of the
Marzari-Vanderbilt paper - I have had to use this option to converge the
spread for certain systems.)
Also check that the disentanglement procedure (minimisation of the
invariant spread) has converged in both the 2x2x2 and 4x4x4 calculations.
I always check two things
1- That the MLWF provide a good interpolation of the band-structure within
the energy range of interest (ie the inner energy window)
2- That the MLWF are essentially real (the plotting routine tells you
When my Wannier functions pass these tests, I'm usually happy with them.
[although I realise that it is more difficult to apply these tests for
> My firs question on this issue is that, does the wannier_plot indeed require
> larger memory size? Then, how can I estimate the size?
> In that particular case, the job crashed after awhile, and the machine has
> 32GB memory, so it looks like, it went over 32GB!
> #I would imagine that the memory size would be estimated something like (FFT
> grid)*(# bands)*(# of kpoints) *prefactor. I would like to know the prefactor
> if this assumption is correct.
As you've noticed the plotting routine currently in Wannier90 is not as
smart and efficient as it could be. This is something Arash and I plan to
improve in the future. It is fine for small systems, but large systems are
The memory size is
[ (FFT grid)*(wannier_plot_supercell^3)*(num_wannier_plot)
+ (FFT grid)*(#wannier+#bands in outer window) ]*16bytes
It is independent of the number of kpoints. For your case this is ~7Gb.
Which is less than the physical memory, but compilers and operating
systems can have problems with very large arrays, so that could be a
cause. [it's hard to say without more information].
Plotting is always going to be an expensive operation in terms of time
and memory. Some things that can speed plotting up include:
1- wannier_plot_supercell defaults to 2. Reduce it to 1 (although at the
moment wannier90 does not translate a WF into the 'home' unit-cell for
plotting. So if a WF lies in a neighbouring unit-cell, or on the boundary
you will not see all of that WF).
2- Plot 1 WF at a time (via wannier_plot_list)
3- Reduce the FFT grid: For plotting there is no need to use the very
dense grid from the planewave calculation, rather we can "decimate" it by
removing, say, every 2nd element. This is the job of the ab-initio code,
rather than wannier90. I assume you are using pwscf - I will send you our
latest copy of the pw2wannier90 code, which include a 'decimation' option.
However, if you are using a different ab-initio program it is easy to do
Dr Jonathan Yates: email: jryates at lbl.gov phone: 510-642-7302
Material Science Division, Lawrence Berkeley National Laboratory and
Department of Physics, University of California,
366 Le Conte Hall #7300, Berkeley, CA 94720-7300, USA
More information about the Wannier