Silent fail in superlattice with U correction

[edith_simmen]

Good morning

I'm running calculations on a superlattice with 110 atoms and a U correction on the Ni atoms. For my current calculations, VASP silently fails when it calculates the occupancies and eigenvectors after some ionic relaxation steps, usually it always fails on the atoms close to the interface of the cell. I run the GPU version of VASP 6.6.1 and for the attached example, the calculation silently failed after 12 ionic relaxation steps. I have tried:

• How long it takes before it fails depends on the interface distance. But no matter what I choose, it eventually fails.

• With Vasp 6.6.1 and ISEARCH = 1 it runs longer before it fails compared to 6.5.1.

• Choosing more / less nodes or a different KPAR didn't help.

Do you know what this problem could be related to? I haven't figured out if it's related to a problem with VASP/the chosen calculation parameters or if the structure is just not feasible (I'm trying to include a supertetragonal BaTiO3 phase by constraining these atoms).

Thank you already in advance for your help!

Best,
Edith

[christopher_sheldon1]

Dear Edith,

Thank you for your question and your files. I am afraid that I was not able to repeat your issue. The calculation converged in 39 ionic steps. A few things that I changed in the INCAR:

ALGO = Normal
EDIFF = 1e-6 - converges quicker 1E-7 is very tight for this system
LDAUPRINT = 0 - limits the output
POTIM = 0.25 - so that the ionic steps are a little closer together

Unfortunately, the energies between ionic steps do change a lot between ionic steps. This indicates that there is a problem, likely with the DFT+U. I am still looking into this.

I will continue to investigate this. If you have a std.err file, could you provide it, along with your submission script? and I will try to replicate your issue.

Have you been able to repeat this on a smaller example? This would help me to determine where the issue is.

Best wishes,

Chris

[christopher_sheldon1]

Dear Edith,

I suspect that this job was killed by some external problem, possibly an out-of-memory error; then it stopped writing, and the job died. I would need your submission script and any other stdout/ stderr that you might have to confirm this. "sacct -j $job_number" or an equivalent to describe the state would also help say exactly what went wrong. Most likely the issue is more with converging the SCF. I noticed issues with convergence (flipping the magnetic moment of Ni21/ Ni22), which is likely related to the jumps at the interface. You could try constraining the magnetic moments (https://vasp.at/wiki/I_CONSTRAINED_M) to fix this and stop the atoms switching.

Best,

Chris

[edith_simmen]

Dear Chris

Thank you very much for your help. I'm sorry for not responding earlier, I was on vacation and only got around to read your response yesterday.

With regards to your suggestion/questions:

stdout/sterr files:
I did not save all the files, but I reran the job and attached all the files. I included the memory usage during the job execution. To me it doesn't look like an out-of memory error, what do you think? I also included the sacct command below, but I fear it's not really helpful. Since the job freezes I usually cancel it once I see that no file has been updated for a while.

JobID JobName Partition Account AllocCPUS State ExitCode
------------ ---------- ---------- ---------- ---------- ---------- --------
5034804 test_vasp normal lp61 1152 CANCELLED+ 0:0
5034804.bat+ batch lp61 288 CANCELLED 0:15
5034804.ext+ extern lp61 1152 COMPLETED 0:0
5034804.0 vasp_std lp61 192 CANCELLED 0:15

Different ALGO
I'm usually using ALGO=All because I had the problem with spins switching that you describe in similar superlattices to the one I'm calculating now. Back then, I was able to resolve this by changing from ALGO=Normal to All so I kept this ALGO. Now I also tried with ALGO=Normal as you suggested, and after 22 ionic relaxation steps I first get " WARNING: Sub-Space-Matrix is not hermitian in DAV" and then the job fails with the error "FEXCF: supplied exchange-correlation table is too small". I will continue to try and relax the with structure by constraining the magnetic moments.

Best,
Edith

[christopher_sheldon1]

Dear Edith,

I repeated your calculation for the structure that fails. The electron number becomes unstable. This indicates a problem with the calculation itself. The Ti-O atoms are close; normally, this is not something that would kill a calculation. However, combined with +U this seems to be enough to make it unstable. Running with harder O POTCARs (O_h) and increasing the ENCUT to 800 eV allowed the calculation to converge smoothly. It can also converge without +U, but I think that this is important for your system. One thing that I noticed is that the magnetisation continues to change, even as it is converging. I'm still testing this to find a solution. Hopefully using constrained magnetic moments (https://vasp.at/wiki/I_CONSTRAINED_M) should solve this.

Best wishes,

Chris