[Wannier] parameter to control convergence
Tadashi Ogitsu
ogitsu at llnl.gov
Tue Aug 29 19:33:48 CEST 2006
Dear Jonathan and other developers,
Thanks for the reply. About the memory size, I was specifying
wannier_plot_supercell = 3 without thinking carefully. I was watching
the process using top command after a few of my jobs crashed, and
noticed that it goes beyond 10GB, then machine's response gets
extremely slow (I managed to kill the process though). With
wannier_plot_supercell = 3, the memory size is around 24GB (?), so,
it is understandable.
One feed back. For beta-boron (105 atom cell), one has to start with
using fixed_step at a smaller value than the default (I used 1), for
a couple of ten iterations, then, switch to the normal line
minimization. Otherwise, the calculation gets stuck somewhere; even
with num_iter = 5, the code did not write on STDOUT at all for
several hours, and I gave up. It may be helpful if the code either
halts or writes a warning if the line minimization steps gets too many.
I've tried larger values for number of bands, but it did not work.
Simply the spreads diverge over wide range of values from less than 1
to over 50.
My current understanding is as follows: Beta-boron's bonding
character is covalent, although it has a Fermi surface (large hole in
the valence band). Therefore it might be important to limit the
subspace for wannierisation within the valence band (i.e. include the
hole states in the valence band). Indeed, this strategy together
with 4x4x4 k-points grid seem to give a reasonable result. Any
comment will be appreciated.
Jonathan, I'll try your suggestions, the quality of band
interpolation and if MLWF real.
Many thanks for your help.
Best,
Tadashi Ogitsu
On Aug 27, 2006, at 6:52 PM, Jonathan Yates wrote:
> 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 this)
>
> 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 large systems]
>
>> 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 resource intensive.
>
> 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 yourself.
>
> Yours
> Jonathan
>
> --
> 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
> _______________________________________________
> Wannier mailing list
> Wannier at quantum-espresso.org
> http://www.democritos.it/mailman/listinfo/wannier
More information about the Wannier
mailing list