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.
_______________________________________________
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
