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-boun...@zeus.theochem.tuwien.ac.at> on behalf of Falke,
Johannes <johannes.fa...@cpfs.mpg.de>
Sent: Tuesday, June 30, 2020 3:24 PM
To: wien@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@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@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
