Closed arnabkabiraj closed 3 years ago
greschd
commented
3 years ago Hi,
Unfortunately I don't have access to a VASP license, so I can't test these things. Can you test if the skip_b1_tests = .true. input to Wannier90 works in the version that you use?
arnabkabiraj
commented
3 years ago It does! Now the calculation is continuing. However, the Wannier90 output says " Ignoring
num_wann = 10 num_bands = 10 spinors : true num_iter 0 shell_list 1 exclude_bands 11-16 skip_b1_tests = .true.
greschd
commented
3 years ago If the POTCAR has 5 electrons and the VASP calculation is running with 16 bands that seems correct.
I'm not 100% sure about the "ignoring .." warnings - I think the num_bands warning is harmless, but maybe it means you could omit that from the input file. VASP prints some things into the input file by itself, maybe this is one of them. The exclude_bands parameter however is definitely needed (and common source of problems when VASP uses more bands than instructed to fit CPUs).
As for the "spinors" warning - I don't know what the latest status is, but it may be that VASP doesn't fully implement the spinor case interface. Since we only use the overlap (.mmn) matrices however, it might not be a problem.
arnabkabiraj
commented
3 years ago Nice! It seems VASP 6.1.1 is working with Wannier90 2.1 without any modification, so the executable can be used with other Wannier 90 related calculations too. I can confirm that both executables of VASP 6.1.1 (compiled with unmodified Wannier90 2.1 and modified Wannier90 1.2) produces identical results for the Bi example. I will try other test cases in the future. I'm closing the issue. On a slightly unrelated note, how do you exactly determine the value of the variable num_wann/num_bands in Wannier90 input for a specific unit cell and POTCAR? For the Bi example, there are 2 atoms in the cell with 5 electrons (6s2 6p3) each. Wannier90 newbie here, obviously! :)
greschd
commented
3 years ago Here that is quite simply: we just choose it to be the number of electrons per unit cell - because the calculation should give the Z2 invariant of the occupied subspace.
In general for Wannier90 calculations (outside of Z2Pack) it's a bit more complicated - for example if you want to capture conduction bands, more Wannier orbitals are needed. There are several approaches - for example you can "guess" a reasonable initial projection (maybe s and p for Bi, I haven't tried that), and choose the number of Wannier functions to match that (2 * (2+6) = 16 in this case). But it really depends on what you need the Wannier orbitals for in the end.
arnabkabiraj
commented
3 years ago Okay. Thanks a lot!
arnabkabiraj
commented
3 years ago Hi again, I'm trying to calculate Z2 invariant of a 2D material with the same tools (VASP 6.1.1 - Wannier90 2.1). However, I'm facing the error message "No overlap matrices were found. Maybe switch from shell_list to search_shells in wannier90.win or add more k-points to the line.". Issue #40 mentions the same error and you've said that explicitly specifying the neighbors would be possible in Wannier90 2.1, which should solve the problem. How do I achieve this? I've tried setting search_shells = 12 to 120, but the issue remains. Another solution you've mentioned is incresing the kpoints density for vasp. How do I do this? I'm using the follwing system definition. system = z2pack.fp.System( input_files=["../static_run/CHGCAR", "input/INCAR", "input/POSCAR", "input/POTCAR", "input/wannier90.win" ], kpt_fct=z2pack.fp.kpoint.vasp, kpt_path="KPOINTS", command="mpirun -np 4 vasp_ncl_611 >& log" ) The KPOINTS file contains a grid of 1 x 7 x 1.
greschd
commented
3 years ago The number of k-points that Z2Pack uses is controlled by the iterator keyword, see the corresponding reference.
The default value is range(8, 27, 2), which means it will start with 8 points (including the periodic image of the start, so that's the 1x7x1 KPOINTS file), and increase by 2 until it reaches 26. So you will need to increase the lower bound - depending on how flat your reciprocal space is. The goal is that two k-points along the line should be closer to each other than those in neighboring cells.
The option of explicitly specifying the k-points is definitely preferable, but I haven't yet tried this with VASP + Wannier90. To try it, you will need to specify either wannier90_nnkpts (source) or wannier90_full (source) (I'm not 100% sure which) as a kpt_fct when constructing the fp.System (reference). For an example of how these are used, you can see these two lines in the QuantumESPRESSO example:
The goal here is that the nnkpts block of the Wannier90 input will be written by Z2Pack, and Wannier90 will not need to generate it itself. Since VASP uses Wannier90 in library mode though, I'm not entirely sure if this will work.
arnabkabiraj
commented
3 years ago Increasing the lower bound of iterator worked, but obviously increased the computational expense severely (had to go up to 24 for a c=32 A). But more surprisingly, explicitly specifying the k-points also worked despite VASP using Wannier90 in library mode. However, the postproc_setup = true tag must be there in the Wannier90 input to enable this. My system definition now looks like: system = z2pack.fp.System( input_files=["../stat_SOC/CHGCAR", "input/INCAR", "input/POSCAR", "input/POTCAR", "input/wannier90.win" ], kpt_fct=[z2pack.fp.kpoint.vasp,fp.kpoint.wannier90_nnkpts], kpt_path=["KPOINTS","wannier90.win"], command="mpirun -np 4 vasp_ncl_611 >& log" ) wannier90_full also works but probably is less efficient. And the generic Wannier90 input (*.win) looks like: num_wann = 18 num_bands = 18 spinors = true num_iter = 0 shell_list = 1 exclude_bands = 19-28 skip_b1_tests = true postproc_setup = true
Closing the issue. Again, thanks a lot for your swift responses and help.
greschd
commented
3 years ago Fantastic! In that case, the skip_b1_tests input may no longer be needed.
Would you mind contributing the modified example as vasp/6/Bi? Alternatively I can add the example, and give it to you to test.
I wonder if this means that VASP + Wannier90 can now also be used for "curved" surfaces. There isn't a ready-made kpt_fct for this, but one would first need to test if specifying explicit k-points (instead of a grid + offset) works in VASP + Wannier90 2.1.
arnabkabiraj
commented
3 years ago Sure, I'll make the contribution. Would take a few days as I'm a bit new to Github. Also, if you could prepare and provide me inputs to test curved surfaces, I'd be glad to test it out for you and provide you the reference outputs.
greschd
commented
3 years ago Cool, thanks!
For the curved surfaces, you could try running VASP explicitly on the inputs directory from the Bi example, with the following wannier90.win contents:
num_wann = 10
num_bands = 10
spinors : true
num_iter 0
exclude_bands 11-15
mp_grid: 4 1 1
begin kpoints
0.0 0.0 0.0
0.2 0.3 0.0
0.6 0.5 0.0
0.8 0.9 0.0
end kpoints
begin nnkpts
1 2 0 0 0
2 3 0 0 0
3 4 0 0 0
4 1 1 1 0
end nnkptsAnd a KPOINTS file
Curved k-points test
4
Reciprocal
0.0 0.0 0.0 1.
0.2 0.3 0.0 1.
0.6 0.5 0.0 1.
0.8 0.9 0.0 1.There could be some syntax mistake in the above, so it may need some tweaking. The goal is that VASP either runs and produces a wannier90.mmn file (in which case curved surfaces are possible), or aborts stating that we need to use a regular mesh (in which case they are not possible).
jkidd1
commented
3 years ago Hello, I have also compiled VASP 6.1.2 with W90 2.1 to test this. It would really be great if VASP could be used this way for something like a Weyl semimetal calculation. Dominik, I followed your last suggestion, but I receive the following error:
Your generating k-point grid is not commensurate to the symmetry of the lattice.
This does not sit well in combination with the PEAD routines, sorry ...
Suggested SOLUTIONS:
) If not already the case, use automatic k-point generation.
) Shift your grid to Gamma (G) (e.g. required for hex or fcc lattice).
I REFUSE TO CONTINUE WITH THIS SICK JOB ... BYE!!!This is confusing to me because I have set ISYM = -1. I have also tested this with other meshes. For example, I used this KPOINTS file:
Automatically generated mesh
6
Reciprocal lattice
0.00000000000000 0.00000000000000 0.00000000000000 1
0.16666666666666 0.00000000000000 -0.00000000000000 1
0.33333333333334 0.00000000000000 -0.00000000000000 1
0.50000000000000 0.00000000000000 -0.00000000000000 1
-0.33333333333334 -0.00000000000000 0.00000000000000 1
-0.16666666666666 0.00000000000000 0.00000000000000 1which is equivalent to this:
Auto
0
Gamma
6 1 1and while I am able to obtain the overlap matrices when I use the latter for my file, the error occurs when I instead specify the k-points explicitly. This happens even if I use postproc_setup = true. @arnabkabiraj, perhaps you have some suggestion, since you said you didn't have a problem when using explicit k-points?
greschd
commented
3 years ago As far as I can tell, the method used by @arnabkabiraj above
system = z2pack.fp.System(
input_files=["../stat_SOC/CHGCAR", "input/INCAR", "input/POSCAR", "input/POTCAR", "input/wannier90.win" ],
kpt_fct=[z2pack.fp.kpoint.vasp,fp.kpoint.wannier90_nnkpts],
kpt_path=["KPOINTS","wannier90.win"],
command="mpirun -np 4 vasp_ncl_611 >& log"
)explicitly specifies the k-point neighbors in the wannier90.win file (through the wannier90_nnkpts function), but still uses the implicit mesh syntax in the VASP KPOINTS file.
It's entirely possible VASP still doesn't support explicitly specifying the k-points for VASP2WANNIER calculations - unfortunately, I don't have the means to check for myself.
mkhorton
commented
3 years ago I'm not sure if this is relevant, but it looks like VASP 6.2 (released this month) just modernized their wannier90 interface, and now supports wannier90 2.x and 3.x, dropping support for 1.x. Perhaps this could help with some of these issues.
greschd
commented
3 years ago Thanks @mkhorton, that's good to know.
jkidd1
commented
3 years ago Thanks for sharing @mkhorton. Dominik, I am working on testing V6.2 + W3.x right now and will share what I find here. One thing I wanted to point out is that .mmn files are automatically generated when using the LOCPROJ tag in VASP 6.2. Would this work with Z2Pack, or would we still need to run Wannier90 in library mode?
greschd
commented
3 years ago Any way of generating the .mmn files should work. One thing to consider is whether it allows for specifying curved lines, but this also needs testing when the Wannier90 library mode is used.
Hi, VASP 6.1.1 supports interface with Wannier90 v2.1 (v2.x written in manual). I have successfully compiled VASP 6.1.1 with Wannier90 2.1. However, when I try running the Bismuth VASP example of Z2pack, using run.py, the calculation halts with the following Wannier90 output. VASP output says "B1 condition not satisfied". This problem does not arise when I use the same version of VASP compiled with your modified Wannier90 1.2. Is there a way to use "unmodified" Wannier90 2.1 with VASP 6?
-> Using Bohr value from CODATA *
Wannier90 is running in LIBRARY MODE
Setting up k-point neighbours...
Ignoring in input file
Ignoring in input file
---------------------------------------------------------------------------- | Site Fractional Coordinate Cartesian Coordinate (Ang) | +----------------------------------------------------------------------------+ | Bi 1 0.23389 0.23389 0.23389 | 2.31149 1.26114 0.87393 | | Bi 2 0.76611 0.76611 0.76611 | 7.57133 4.13089 2.86258 | ----------------------------------------------------------------------------
---------------------------------- MAIN ------------------------------------ | Number of Wannier Functions : 10 | | Number of input Bloch states : 11 | | Output verbosity (1=low, 5=high) : 1 | | Timing Level (1=low, 5=high) : 1 | | Optimisation (0=memory, 3=speed) : 3 | | Length Unit : Ang | | Post-processing setup (write .nnkp) : F | | Using Gamma-only branch of algorithms : F | ---------------------------------------------------------------------------- ------------------------------- WANNIERISE --------------------------------- | Total number of iterations : 0 | | Number of CG steps before reset : 5 | | Trial step length for line search : 2.000 | | Convergence tolerence : 0.100E-09 | | Convergence window : -1 | | Iterations between writing output : 1 | | Iterations between backing up to disk : 100 | | Write r^2_nm to file : F | | Write xyz WF centres to file : F | | Write on-site energies <0n|H|0n> to file : F | | Use guiding centre to control phases : F | | Use phases for initial projections : F | ---------------------------------------------------------------------------- ------------------------------- DISENTANGLE -------------------------------- | Using band disentanglement : T | | Total number of iterations : 200 | | Mixing ratio : 0.500 | | Convergence tolerence : 1.000E-10 | | Convergence window : 3 | ----------------------------------------------------------------------------* Time to read parameters 0.001 (sec)
+----------------------------------------------------------------------------+ | The b-vectors are set in the win file | Exiting....... kmesh_shell_fixed: B1 condition not satisfied