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
[email protected]
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/[email protected]/index.html
