DETERMINE_ALTERNANT error for GW calculation

[bprobinson102]

VASP team,

I have received the following bug report from my GW calculation

Code: Select all

-----------------------------------------------------------------------------
|                     _     ____    _    _    _____     _                     |
|                    | |   |  _ \  | |  | |  / ____|   | |                    |
|                    | |   | |_) | | |  | | | |  __    | |                    |
|                    |_|   |  _ <  | |  | | | | |_ |   |_|                    |
|                     _    | |_) | | |__| | | |__| |    _                     |
|                    (_)   |____/   \____/   \_____|   (_)                    |
|                                                                             |
|     internal error in: minimax.F  at line: 4008                             |
|                                                                             |
|     internal ERROR, DETERMINE_ALTERNANT was not able to find alternant      |
|     47 12288 10                                                             |
|                                                                             |
|     If you are not a developer, you should not encounter this problem.      |
|     Please submit a bug report.                                             |
|                                                                             |
 -----------------------------------------------------------------------------

Thanks!

[michael_wolloch]

Hello,

thanks for submitting a bug report. To try and reproduce the issue, I would need to know more details. Please attach your makefile.include and also your INCAR for the DFT step. (Is there a reason why you are not using the single-step procedure?

It would also be nice to know if the problem persists for the current release version 6.4.3. From the OUTCAR I see that you have used 6.4.1. It would be great if you could compile 6.4.3 and try again.

Cheers, Michael

[bprobinson102]

Michael,

Thank you for getting back to me. I have attached my makefile.include and dft INCAR. There is no specific reason as to why I do not use the single-step procedure, I will use this in the future. Also, I will try to recompile with 6.4.3 and see if I get the same error.

Brian

[michael_wolloch]

Hi again,

and thanks for the data. I will wait for your report if the bug persists with the newer version. If it does, I will try and reproduce it on our machines.

Cheers, Michael

[michael_wolloch]

Dear Brian,

I wanted to follow up on this finally. I failed to reproduce the bug with 6.4.1, although I did lower some settings to speed up the calculation (5x5x5 k point mesh and ENCUT = 350).

Before I try to run a potentially very long calculation with your settings, I wanted to ask if you tried it yet with 6.4.3?

Also, I do not understand some things about the calculation and wanted to get more information:

1) The structure you are using is very out of equilibrium: With your original settings, but small Gaussian smearing I get a volume of 15.21, while you are calculating at a volume of 37.4. The difference in total energy is ~65% or roughly 3.3 eV. Is this intentional?

2) I think you do have a small, but existing bandgap with your settings. Do you still need to use LFINITE_TEMPERATURE?

3) Any specific reason to choose the specific electronic temperature you did with SIGMA = 1.0?

4) Can you explain your choice of NBANDS and NBANDSGW?

Generally, it would be very helpful to understand what you are trying to calculate exactly.

Bug reports are very important to us, and I would like to thank you again for reporting one, but if we struggle to reproduce them, it is hard to figure out what goes wrong exactly. So any more info you can provide would be very much appreciated!

Thanks, Michael

[bprobinson102]

Michael,

I did try with 6.4.3 and still got the same error.

As for my calculation:

1. Yes, this structure is intentionally out of equilibrium
2. We are interested in finite temperature effects, so yes
3. SIGMA = 1.0 has to do with our finite temperature interest
4. We set NBANDS and NBANDSGW to 128 because we found this value to be the smallest value that gives us good results

Let me know if you need anything else, thanks!

Brian

[michael_wolloch]

Dear Brian,

thanks for your help and clarifications. I will continue working on this.

A small note I forgot to mention: We recommend using the _GW potentials whenever a significant number of empty states are involved in a calculation. I do not think this is relevant to the bug you reported but it might influence the accuracy of your results. A Be_sv_GW LDA potential is available.

Cheers, Michael

[merzuk.kaltak]

Dear Brian,

the error message is unfortunately not very helpful in this case.
The main problem in the GW-step is the combination of NOMEGA=24 and SIGMA=1.
This results in a too tight convergence criterion for the Remez-Algorithm, which then fails to converge.
In fact, if you look at the lines in "gw.stdout" you see following output:

Code: Select all

...
  Looking for a minimax solution for ITYPE= -1 B=0.5778E+03
     iter      E_min       E_max       dError      iters_nl  0.3368E-26
       1       0.2241E-22  0.2443E-22  0.2025E-23        48
       2       0.2250E-22  0.2252E-22  0.1381E-25        44
...

This means that integration error is of the order of 10^-23.

For the selected SIGMA=1 (corresponding to an electronic temperature of ~11000 K) you may choose a much smaller number of grid points. For instance using NOMEGA=12 one ends up with an error of ~10^-12, which is probably sufficient for your application.

Note following rule of thumb for LFINITE_TEMPERATURE=T calculations. Using the minimax isometry method one typically requires less NOMEGA points with increasing SIGMA to obtain a certain integration error as demonstrated in Fig. 7 of PRB.101.205145.
Be aware of the relationship beta = 1/SIGMA, where beta is the inverse temperature measured in eV.