[Wien] error in hf+so calculaions

[Gavin Abo]

On page 127 of the WIEN2k 19.1/19.2 UG [1] under section "7.6.2 Input" 
for case.inhf, I see:

gmax=6 can eventually represent a good compromise between computational 
time and accuracy.

If it were my calculation, I would start with using the gmax=6 in 
case.inhf following that advice and only later increase it for 
convergence testing.  Though, you can go with the higher accuracy and 
higher computational time associated with gmax=16 if you want (assuming 
your system is performing the calculation in a reasonable amount of time 
for you).

Regarding the "WARNING: gmax in case.in2 is maybe not large enough", if 
you want to remove that, I would follow what the statement says to 
gradually increase the gmax value in case.in2 or case.in2c until the 
message goes away.  For a SO calculation, it probably is usually 
case.in2c.  So if case.in2 did not do anything, then you could try the 
case.in2c if it exists.  I don't know the details of your calculation, 
so you would have to determine the correct file for your case yourself.  
In the post at [2], the information there might help.

Regarding the use of 1 k-point (nx = ny = nx = 1) with hf, the advice in 
post [3] was to use a small but decent k-mesh.  I'm not aware of the 
reason(s) why if there are any issues with using 1 k-point for a hf 
calculation.  If some else in the list has experience with it (e.g., 
maybe one of the other mixers is better than the default for doing 1 
k-point), maybe they will respond later about that.  Though, I would 
expect that you would need to make sure you are using mpi parallel [4] 
or serial and not k-point parallel for doing that.

Regarding "almost 12 hours", as hf calculations seems to be known to be 
computationally demanding, that may or may not be normal. In your 
standard output to the terminal on a personal desktop computer (or 
output log file typically on high performance computing cluster), the 
ETEST and CTEST (e.g., like that seen in the post at [5]) may be useful 
for roughly monitoring if the calculation is converging or diverging 
(oscillating).  For more precising monitoring, I think it might have 
been "Check-mixing" that could be ran in a terminal or job script as 
seen in the post at [6].

Regarding the hf.error* files, like with other error files (e.g., refer 
to post [7]) I think that would be the desired behavior for the error 
text to be put in their when the file is first created but cleaned up 
later once the task completed successfully.

[1] http://susi.theochem.tuwien.ac.at/reg_user/textbooks/usersguide.pdf
[2] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg04411.html
[3] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg20901.html
[4] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg05595.html
[5] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg02833.html
[6] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg20445.html
[7] 
https://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/msg05279.html

On 4/5/2021 2:36 PM, Microsoft.com team wrote:
> Dear Prof. Gavin Abo
> Thanks a lot for your kind help.
> However, I removed all files from the case directory and started with 
> structure file with no warning .
> I use wien2k_19.1 complied with gfortran in parallel.
> I used gmax = 16 in inhf and in2 files.
> In init_hf step
> The k-mesh was not redused with
> nx = ny = nx = 1.
> The run is continuing right now since almost 12 hours .
> I found a warning in scfhf_1 file that " the value of gmax may be not 
> large enough".
> In addition, there are two errors in error files "hferror".
> I send this message from my mobile because almost my workstation is 
> hanged up because of computations.
> I don't know should I wait more or I have to stop.
> Thanks a lot once again.
> Kind regards .
> Tarek Hammad.