GW0 Band Gap with Wannier

[mgverg]

I am trying to calculate the Band Gap with the tag LWANNIER90=TRUE but I get stuck already in the optic calculation of previous steps.

I have a system of 24 atoms and my INCAR is the following

NPAR = 2
PREC = High
ISMEAR = 0
SIGMA = 0.01
GGA = PE

# STEP2
ALGO = EXACT
LOPTICS =.TRUE.
NBANDS = 200
NEDOS = 2000


LORBIT = 10
ENCUT = 400 eV

NELMIN = 3
ISIF = 2
ISYM = 0
NSW = 0
IBRION = -1

EDIFF = 1E-05

LMAXMIX = 4


The error I get is the following

internal ERROR: invalid n in M_sumb_d -1707860984

What can I do ?

[rbhttri1]

I am also having exactly the same issue when running BSE calculations. It appears in the second step (ALGO = Exact) where the WAVECAR/CHGCAR files from the previous run (ALGO = Normal) are used. I tried changing ENCUT, NBANDS, KPAR, NPAR, KPOINTS, number of cpus..... None of them worked.

[fabien_tran1]

Hi,

Could you please share your input files (as a zip file) and describe the steps of the procedure that you followed? And which versions of VASP and Wannier90 are you using?

[rbhttri1]

Hi,

The input files and procedure are attached in a zip file. I am using the 5.4.4 version of vasp.
Thank you.

[fabien_tran1]

In principle, we do not provide support for such old versions of VASP. Nevertheless, the crash (which occurs at step 2, right?) may be due to integer overflow, since your system is not that small for ALGO=Exact, which by the way also requires a machine with a large amount of RAM. A way to alleviate this problem would be to use ALGO=Normal (instead of ALGO=Exact) with a very small value of EDIFF (1E-8 or even 1E-10) to ensure a good convergence for the unoccupied states.

[rbhttri1]

Hi fabien_tran1,

By using the vasp.6.3.2 version, I was able to solve that problem. However, I got another problem in 3rd step shown below (ALGO = GW0 or EVGW0). When I talked to the HPC cluster support, they said that there was no issue of insufficient memory, instead it could be a problem with the input files. I was wondering if you could do a test run to see whether it runs smoothly on your machine.

available memory per node: 628.68 GB, setting MAXMEM to 643767
min. memory requirement per mpi rank 313647.9 MB, per node 627295.8 MB

[1715701997.480408] [ab02:3691635:0] rcache.c:190 UCX ERROR mmap(size=151552) failed: Cannot allocate memory
[ab02:3691635:0:3691635] pgtable.c:75 Fatal: Failed to allocate page table directory
==== backtrace (tid:3691635) ====

===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 2 PID 3691634 RUNNING AT ab02
= KILLED BY SIGNAL: 9 (Killed)
===================================================================================

Thank you.

[rbhttri1]

For reference, I've attached two of the slurm outputs below:

The intel version was using intel one api 2022.2 (mpi/mkl/ifort/icc).
The other one was using openmpi 4.1.6, aocc 3.2.0, aocl 3.2.0. It is also compiled with openmp support (noticeable in the output).

(the openmpi one seems to fail slightly less gracefully, but the intel one is a little random when it comes to what it outputs).