My Community

Hi there,

I am encountering the following error when trying to perform a calculation with ALGO=TDHF on this system. Do you have any ideas as to what this could be? I've never encountered this issue before, and seems to be an error encountered in a scaLAPACK routine. I am using VASP 5.4.4, and can try using the newest version, but wanted to check before doing so. I have attached all relevant inputs/outputs for the calculation. Due to size limitations, I couldn't attach my WAVECAR/WAVEDER files.

|.........|........ BSE redistributing all elements

 BSE diagonalizing matrix (scaLAPACKaware)
{    0,    0}:  On entry to
PZHENTRD parameter number   13 had an illegal value
{    1,    0}:  On entry to
PZHENTRD parameter number   13 had an illegal value
{    2,    0}:  On entry to
PZHENTRD parameter number   13 had an illegal value
{    3,    0}:  On entry to
PZHENTRD parameter number   13 had an illegal value
{    2,    1}:  On entry to
PZHENTRD parameter number   13 had an illegal value
{    3,    1}:  On entry to
PZHENTRD parameter number   13 had an illegal value
{    4,    0}:  On entry to
PZHENTRD parameter number   13 had an illegal value
{    5,    0}:  On entry to
PZHENTRD parameter number   13 had an illegal value
{    0,    1}:  On entry to
PZHENTRD parameter number   13 had an illegal value
{    1,    1}:  On entry to
PZHENTRD parameter number   13 had an illegal value
{    4,    1}:  On entry to
PZHENTRD parameter number   13 had an illegal value
{    5,    1}:  On entry to
PZHENTRD parameter number   13 had an illegal value
Abort(269032709) on node 10 (rank 10 in comm 0): Fatal error in PMPI_Bcast: Invalid communicator, error stack:
PMPI_Bcast(431): MPI_Bcast(buf=0xacb7a80, count=3, MPI_DOUBLE, root=0, comm=comm=0x0) failed
PMPI_Bcast(370): Invalid communicator

Thanks!
Jake

Hi Jake,

Thank you for the error report and the files. It's not immediately clear what is happening to me beyond an issue with the parallelisation (MPI). I'll try to repeat the calculation and get back to you.

Best wishes,

Chris

Chris,

Just updating that I found an error in my INCAR with the number of occupied bands. I have corrected it to match the number of electrons in the structure (702), but still I get the error. Here is my corrected line:

NBANDS = 720
NBANDSO = 351
NBANDSV = 369

Best,
Jake

Hi Jake,

I've tried to repeat the calculation, but have not been able to with your settings. I think that it requires too much memory, which I presume will be the same for you. Your system is quite large, so it will require a lot of memory to do TDDFT. The number of occupied and unoccupied orbitals (NBANDSO and NBANDSV, respectively) will increase the memory demands. I would recommend using a smaller number. NBANDSO + NBANDSV does not need to add up to NBANDS. They are the number of orbitals that you want to include in TDDFT calculation. E.g., for this TDDFT calculation on Si, NBANDSO + NBANDSV does not add up to NBANDS.

An alternative solution is to use IBSE=2, which solves the Casida equation for TDDFT more efficiently than IBSE=0 (the default and only option in 5.4.4). This is available in 6.5.0 onwards. Using (after ALGO = TDHF):

ALGO = TDHF
IBSE = 2
NBANDSO = 32
NBANDSV = 32
NBSEBLOCKO = 4
NBSEBLOCKV = 4

The calculation ran in 96 seconds using 32 CPUs and 1 GB of memory (as a maximum). It's important to set NBSEBLOCKO and NBSEBLOCKV to ensure optimal efficiency with IBSE=2. My colleague also ran your calculation with NBANDSO = 351, and NBANDSV = 360, using 128 cores and 10 GB memory (max usage), and the calculation ran (taking around 20000 s). It will be possible to do your calculation with IBSE=0 in 5.4.4, but IBSE=2 will make it significantly easier and more affordable. IBSE=0 will be deprecated in the future for this reason.

Does this help answer your question?

Best wishes,

Chris