Page 1 of 1

LDMATRIX get different values for vasp_std and vasp_gam

Posted: Thu Apr 24, 2025 8:47 am
by xin_zhao

Hi, VASP developers!
Serveral months ago, I report the LDMATRIX error in this post. I'm glad to see this was fixed in VASP 6.5.0 according to the kown issues page. While testing the fix, I found that vasp_std and vasp_gam now give consistent results for simple systems like NV centers in diamond and divacancies in 4H-SiC.

However, I've discovered a new serious problem with LDMATRIX when studying a slightly distorted NV center in diamond. Using identical input files and parameters, vasp_gam and vasp_std produce completely different zero-field splitting parameters - the differences are on the order of GHz, which is far too large to be numerical error.

Here are the key results:

the output of vasp_gam in OUTCAR is

Code: Select all

 Spin-spin contribution to zero-field splitting tensor (MHz)
 ---------------------------------------------------------------
      D_xx      D_yy      D_zz      D_xy      D_xz      D_yz
 ---------------------------------------------------------------
    214.365   -84.370  -129.995  2018.320  1100.951   872.224
 ---------------------------------------------------------------

 after diagonalization
 ---------------------------------------------
     D_diag          eigenvector (x,y,z)
 ---------------------------------------------
   -798.606      -0.261    -0.358     0.897
  -1967.792       0.698    -0.711    -0.081
   2766.398       0.666     0.605     0.436
---------------------------------------------

the output of vasp_std in OUTCAR is:

Code: Select all

 Spin-spin contribution to zero-field splitting tensor (MHz)
 ---------------------------------------------------------------
      D_xx      D_yy      D_zz      D_xy      D_xz      D_yz
 ---------------------------------------------------------------
     78.951    30.932  -109.884  1017.022  1183.335  1004.487
 ---------------------------------------------------------------

 after diagonalization
 ---------------------------------------------
     D_diag          eigenvector (x,y,z)
 ---------------------------------------------
   -931.181       0.507    -0.818     0.271
  -1208.601      -0.616    -0.124     0.778
   2139.782       0.603     0.561     0.568
---------------------------------------------

The differences are huge - both in the tensor components and diagonalized values. This suggests there may still be significant problems with the LDMATRIX implementation in VASP 6.5.0.

For reference, these calculations were done on a dual-socket AMD EPYC 9654 system using VASP 6.5.0 compiled with AOCC and AOCL 4.2.0. I've attached all input files and the OUTCAR file so you can reproduce and compare these results.

Could you please look into this issue? Such large discrepancies in the zero-field splitting parameters make the results unreliable for spin-defect studies.


Re: LDMATRIX get different values for vasp_std and vasp_gam

Posted: Fri Apr 25, 2025 7:55 pm
by fabien_tran1

Hi,

Thanks for reporting this problem. This seems to be due to the array POTFAK that is not properly set to zero in SET_GFAC_DAB (dmatrix.F). The fix is to replace

Code: Select all

               POTFAK(NI,1:3)=0._q

by

Code: Select all

               POTFAK(NI,1:6)=0._q

Could you please test this fix and report if it works for you, too?

Besides, you mentioned that VASP.6.5.0 was used, however the first line of your OUTCAR files indicates that VASP.6.4.3 was used.


Re: LDMATRIX get different values for vasp_std and vasp_gam

Posted: Sat Apr 26, 2025 7:49 am
by xin_zhao

Thanks!

I rechecked my calculations and found that I was using the wrong version of VASP. After switching to VASP 6.5.0, the mismatch between vasp_std and vasp_gam disappeared. It seems I encountered a known bug in VASP 6.4.3. I apologize for the confusion and appreciate your time and help.


Re: LDMATRIX get different values for vasp_std and vasp_gam

Posted: Sat Apr 26, 2025 9:52 am
by fabien_tran1

Ok, but by chance the tests that I have done revealed a new bug in version 6.5.0. You should really include the fix for this bug for your calculations. According to my tests, this bug may randomly lead to wrong results, especially with the GNU compiler.