[Wien] Some issues encountered when upgrading k-mesh in HF/SO calculation

[Falke, Johannes]

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.