Dear Henrique,
I have recently begun to do more Wannier-conversion runs using VASP 6.3.1 and Wannier90 v3.1.0. Things seem to be working correctly, for the most part; however, the 'exclude_bands' flag is causing some very strange behavior. It seems the UNK* files are being written correctly at least, but I've noticed that if I have 'exclude_bands' in the wannier90.win file or alternatively in the INCAR via the WANNIER90_WIN flag, I can receive 1 of 3 possible errors for KPAR = 1, and some mixture of these same errors for KPAR > 1. I will only discuss the KPAR = 1 results here. I've attached files within a ZIP folder to the message.
To start, I'm considering a bulk primitive CdS wurtzite unit cell, which has 4 atoms and 36 electrons. I am using the default cutoff for these calculations, and NBANDS = 48 to ensure a well-converged valence band structure. I also want to mention at this point that the errors occur regardless if the cores are standard cores (~4.2 GB memory per core) or high-memory cores (~42 GB memory per core). Therefore, I do not believe the problem concerns the total available memory since this system is so small.
(1) The first error I receive seems to occur if I run the vasp-to-wannier interface on multiple cores, say 6-12 cores, but where the core count is less than NBANDS. The error message, which is printed in an e.* file and repeated multiple times depending on the core count, says something like
[smem0301:75240:0:75240] Caught signal 11 (Segmentation fault: address not mapped to object at address 0x1178ee78)
See attached file called 'e.6cores'. What's strange is this error does not cause VASP to crash, and no error message prints to the screen. The calculation stalls but continues running until the wall-time is reached, or until I cancel the calculation manually. The error also happens after the UNK* files are written if LWRITE_UNK = T, or after the *amn file is written if LWRITE_UNK = F. So it seems that all wannier90 files are written, at the very least, but it is still concerning this error happens at all. I do not recall seeing anything like this when I used to run VASP 5.4.4 linked with Wannier90 v1.2.
(2) The second error I can receive seems to occur if I run the vasp-to-wannier interface on a single core (again, either standard or high memory). Error messages print to the screen and to an e.* file, followed by a termination of my VASP process. Again, this happens after the wannier90 files are written, either after the UNK* files if LWRITE_UNK = T or after the *amn file if LWRITE_UNK = F. The error that prints to the screen states
===================================================================================
= BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
= RANK 0 PID 53651 RUNNING AT smem0201
= KILLED BY SIGNAL: 6 (Aborted)
===================================================================================
See screen.1core for an example. The information e.* file is much more complicated than the previous case.
See attached file called e.1core. At the head of this e.1core file, the error reads
*** Error in `/projects/rocl5502/programs/summit_vasp.6.3.1_O2_intel20/bin/vasp_std': corrupted size vs. prev_size: 0x0000000020b25c10 ***
followed by a backtrace and memory map.
(3) The third error I can receive seems to occur when I use numcores = NBANDS = 48. This error looks a lot like the previous error for 1 core and causes a full crash, yet interestingly, the messages I see are distinct from either of the previous cases. First, the messages printed to the screen involve several "KILLED BY SIGNAL: 9 (Killed)" statuses and a few " KILLED BY SIGNAL: 6 (Aborted)" statuses. In my experience in the past, signal 9 messages general mean the calculation fails due to memory demands. However, that doesn't make much sense to me here since I ran this calculation on a full high-memory node, which has 2 TB across all 48 cores.
See screen.48cores for an example. Lastly, the e.* file gives a different message than previously, namely
*** Error in `/projects/rocl5502/programs/summit_vasp.6.3.1_O2_intel20/bin/vasp_std': free(): invalid next size (normal): 0x000000000ddf67d0 ***
several times (differing only in the last few characters), followed by several backtraces and memory maps.
See e.48cores for an example.
Any help would be appreciated. I've tried multiple compilations of VASP, including -O2 and -O0 compilations, with and without the -xHOST flag, and I am using Intel 20.2, MKL 20.2, and IMPI 19.8 in all versions. Something of note: on my -O0 compilation without -xHOST, I did use 'gdb' on a single-core run to see if I could backtrace where exactly these issues happen in the code, but I could not figure out where to go from there. I could not find any of the addressed functions within either the VASP or Wannier90 codes, and the first message (#0) after the backtrace seems to point to some issue in the C-standard library, I believe.
See output.gdb for more details.
Thanks for your help,
Peyton Cline
Postdoctoral Associate
Prof. Joel Eaves' Group
University of Colorado Boulder
Department of Chemistry