[Wien] Some issues encountered when upgrading k-mesh in HF/SO calculation
Falke, Johannes
Johannes.Falke at cpfs.mpg.de
Fri Jul 3 12:12:30 CEST 2020
Dear Fabien,
the calculation (`run_lapw -p -hf -so -redklist -newklist`) has now converged without errors despite what you wrote below regarding simultaneous use of -redklist and -newklist and I would like to calculate the DOS. But did this calculation even do what I intended?
For example, I am also running into problems with the DOS: I ran `x lapw2 -p -qtl -so -hf -redklist`. However, this results in an error in LAPW2 because `case.energyhfso_rbz_1` does not exist, only `case.energyhfso_rbz`. So I ran it without the `-p` argument. But this results in the traceback attached.
However, it does complete successfully with `x lapw2 -qtl -so -hf`. What does this mean for the preceding calculation? How do I check which k-meshes were actually in use?
Best regards,
Johannes Falke
-----Ursprüngliche Nachricht-----
Von: Wien <wien-bounces at zeus.theochem.tuwien.ac.at> Im Auftrag von Tran, Fabien
Gesendet: Dienstag, 30. Juni 2020 21:23
An: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at>
Betreff: Re: [Wien] Some issues encountered when upgrading k-mesh in HF/SO calculation
For question 3: As written in the manual, -so for run_kgenhf_lapw is only for spin-polarized calculations, but maybe -spso would be more clear.
For problem 5: For some reason that I don't remember, I made the simultaneous use of -newklist and -redklist possible only if -redklist is used for the two calculations (old and new k-meshes).
________________________________________
From: Wien <wien-bounces at zeus.theochem.tuwien.ac.at> on behalf of Falke, Johannes <Johannes.Falke at cpfs.mpg.de>
Sent: Tuesday, June 30, 2020 7:31 PM
To: A Mailing list for WIEN2k users
Subject: Re: [Wien] Some issues encountered when upgrading k-mesh in HF/SO calculation
Thanks for the hints.
With run_kgenhf_lapw -redklist, this is what happens when you run it naively, to get a 16x16x16 mesh with an 8x8x8 reduced mesh:
$ run_kgenhf_lapw -redklist
This script runs 'x kgen' twice and generates equivalent meshes in the IBZ and FBZ.
How many k-points in the full BZ?
If you type 0 you can give 3 integers for nx,ny,nz
0
How many in x?
16
How many in y?
16
How many in z?
16
NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
length of reciprocal lattice vectors: 0.877 0.877 0.877 0.000 0.000 0.000
Specify 3 mesh-divisions (n1,n2,n3):
Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
0 <<<<<<<<<<<============ HERE
165 k-points generated, ndiv= 16 16 16
KGEN ENDS
11.010u 0.027s 0:11.07 99.6% 0+0k 0+36232io 0pf+0w
1 symmetry operations without inversion
NUMBER OF K-POINTS IN WHOLE CELL: (0 allows to specify 3 divisions of G)
length of reciprocal lattice vectors: 0.877 0.877 0.877 0.000 0.000 0.000
Specify 3 mesh-divisions (n1,n2,n3):
Shift of k-mesh allowed. Do you want to shift: (0=no, 1=shift)
4096 k-points generated, ndiv= 16 16 16
KGEN ENDS
0.039u 0.008s 0:00.05 60.0% 0+0k 0+5288io 0pf+0w
Give nx,ny,nz for the reduced mesh
nx=?
ny=?
8
nz=?
8
Mod by 0.
Because I of course tried to input shift 0 as the program seemed to be waiting for my input. Hope that clears what I meant. Retrying with 8x8x8 it is obvious that no shift can be entered, but for a higher k-count the program stops there for a number of seconds.
Johannes
-----Ursprüngliche Nachricht-----
Von: Wien <wien-bounces at zeus.theochem.tuwien.ac.at> Im Auftrag von Tran, Fabien
Gesendet: Dienstag, 30. Juni 2020 18:09
An: A Mailing list for WIEN2k users <wien at zeus.theochem.tuwien.ac.at>
Betreff: Re: [Wien] Some issues encountered when upgrading k-mesh in HF/SO calculation
Regarding the DOS, section "TETRA (density of states)" in the manual gives some information about the method.
Don't forget to add "-hf -so" after "x lapw2" and "x tetra" for a HF-SO calculation.
The script run_kgenhf_lapw executes "x kgen". "x kgen" prints on the screen the message "Specify 3 mesh-divisions (n1,n2,n3):" that one has to ignore since the dimension of the k-mesh provided before by the user has been passed automatically to kgen by run_kgenhf_lapw.
Furthermore, when the k-mesh gets large, kgen takes time, which gives the impression that the program is waiting for information from the user when "Specify 3 mesh-divisions (n1,n2,n3):" is printed. Maybe we should modify run_kgenhf_lapw so that it does not print the confusing message "Specify 3 mesh-divisions (n1,n2,n3):".
So, when run_kgenhf_lapw is executed, the dimension of the k-mesh has to be provided only once, which is after "How many k-points in the full BZ?"
"If you type 0 you can give 3 integers for nx,ny,nz"
With -redklist, the reduced k-mesh has to be also provided, after "Give nx,ny,nz for the reduced mesh"
I hope my explanations were clear.
________________________________________
From: Wien <wien-bounces at zeus.theochem.tuwien.ac.at> on behalf of Falke, Johannes <Johannes.Falke at cpfs.mpg.de>
Sent: Tuesday, June 30, 2020 3:24 PM
To: wien at zeus.theochem.tuwien.ac.at
Subject: [Wien] Some issues encountered when upgrading k-mesh in HF/SO calculation
I have a converged calculation on an 8x8x8 k-mesh using both HF and SO. I would like to upgrade this to a 16x16x16 k-mesh as the lower resolution k-mesh results in some strange spikes in the DOS. While doing this, I encountered multiple issues, most of which I managed to fix or work around myself. However, I thought they may still be of interest for improving the documentation or code fixes.
Question 1)
How is the DOS calculated?
Is it simply the eigenenergies for all k-points smoothed by a Gaussian?
I am asking because the strange spikes I am getting for the 8x8x8 resolution seem to imply it is, they are absent for a 16x16x16 non-HF non-SO calculation, while present for the 8x8x8 non-HF non-SO calculation, and according to the band structure there is no flattening of bands and the 8x8x8 and 16x16x16 band structure looks virtually identical.
So it seems to me that this is due to the nature of the DOS calculation. And the only way I can think of that the DOS changes while the band structure remains unchanged is due to the method I speculated above. If so, wouldn't a much more robust method be to interpolate all k-points and integrate this analytically?
Problem 2)
Run_kgenhf_lapw seems to have concurrency issues/race conditions which becomes important for k-mesh sizes greater than 8x8x8.
After inputting the first set of k-mesh dimensions, it seems the ibz generation will start in the background and the first run of kgen messes with the input of the second kgen (or something like that). This seems to still allow you to properly generate the k-mesh, though.
Question 3)
run_kgenhf_lapw -so generates the an ibz that contains the full BZ - is this expected for Pm3m space group? In my case I'm running a non-spin-polarised calculation with SO, so it seems I should leave this off as it is only needed for spin-polarised calculations? Maybe this option should be called -sp or -spso instead for less confusion.
Problem 4)
It is very hard to get proper results from run_kgenhf_lapw -redklist with a 16x16x16 k-mesh due to the increased amount of kgens running apparently in parallel which exacerbates problem 2.
I discovered the following workaround after a lot of trial and error: after inputting the k-resolution for the FBZ, when being queried for a shift of the k-mesh, any input here will interfere with the input for the redklist kgen, resulting in one of the redklist fields (nx) being empty and redklist kgeneration failing with "Mod by 0.". So when queried for the shift, simply wait and do not input anything, then after around ~10s you will be queried for the redklist sizes.
So in general, without knowing the workaround, it is impossible to generate the redklist mesh. But even with the workaround, it seems it will be impossible to generate shifted versions (which I was luckily not interested in).
Problem 5)
I also encountered problems when trying to upgrade the non-redklist 8x8x8 HF/SO calculation to a 16x16x16 calculation with a 8x8x8 HF redklist. In particular, I skipped moving the reduced klists, because of course I did not have them. After a lot of trial and error I noticed in the stderr traceback that klist_rfbz_old is read in during the kmesh upgrade, which was of course non-existent/empty and thus caused the crash. So the documentation should probably explicitly note that the _old files are required as inputs for the upgrade, so that the user knows if changing to a redklist calculation one should do `cp case.klist_{,r}fbz_old` and `cp case.klist_{,r}ibz_old` after the first 3 `mv` instead.
_______________________________________________
Wien mailing list
Wien at zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
_______________________________________________
Wien mailing list
Wien at zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
_______________________________________________
Wien mailing list
Wien at zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
_______________________________________________
Wien mailing list
Wien at zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at: http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: traceback.txt
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20200703/b0b30f02/attachment.txt>
More information about the Wien
mailing list