BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES

jingan-181 commented 2 years ago

After ABACUS completes the scf calculation of the pw basis set, "BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES" appears. like this:

 CG243  -4.97e-01 7.75e+00  -6.431792e+03  1.131020e-04   2.483e-06  2.593e+00
 CG244  -4.97e-01 7.75e+00  -6.431792e+03  -1.326852e-04  2.277e-06  3.743e+00
 CG245  -4.95e-01 7.75e+00  -6.431792e+03  -3.074012e-06  7.418e-07  2.367e+00
 CG246  -4.96e-01 7.75e+00  -6.431792e+03  1.246874e-04   8.012e-07  2.347e+00
 CG247  -4.93e-01 7.75e+00  -6.431792e+03  6.287470e-05   9.806e-07  3.176e+00
 CG248  -4.95e-01 7.75e+00  -6.431792e+03  -2.028726e-04  8.872e-08  3.214e+00
 DONE(5.919e+02  SEC) : cal_overlap_Q
 DONE(6.003e+02  SEC) : cal_overlap_Sq
 DONE(6.012e+02  SEC) : cal_overlap_Q
 DONE(6.094e+02  SEC) : cal_overlap_Sq

===================================================================================
=   BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
=   PID 177624 RUNNING AT cu13
=   EXIT CODE: 139
=   CLEANING UP REMAINING PROCESSES
=   YOU CAN IGNORE THE BELOW CLEANUP MESSAGES
=============================================
======================================

The corresponding test files are here, Fe.zip.

wszhang commented 2 years ago

计算 trimer 结构 pw 与 lcao时，没有问题，计算单晶时出现了问题，看起 PW 与 LCAO 是同样的。

26_Fe_E100_DZP_add_1z1p_BE VE

所用轨道文件见此附件： OrbitalFe.zip

dyzheng commented 2 years ago

@jingan-181 Which ABACUS version did you used? I recalculated your case and get different result as : CG767 8.00e+00 8.10e+00 -6.432034e+03 -5.150284e-06 9.639e-08 9.980e+00 which differ from your result: CG248 -4.95e-01 7.75e+00 -6.431792e+03 -2.028726e-04 8.872e-08 3.214e+00

dyzheng commented 2 years ago

The branch develop in abacusmodeling/abacus-develop has fixed bug reported in your tests, but the consequence different problem mentioned above should be studied. @jingan-181

jingan-181 commented 2 years ago

I use the updated ABACUS version, Fix: setting of k-points in NSPIN=2 has conflict with Pkpoints in numerical_basis.cpp, and now the ABACUS pw basis set self-consistent calculation can pass normally. As mentioned above, I use 1 core, 14 cores, and 28 cores respectively to generate Fe orbitals using the same input file. The iteration steps of the self-consistent calculation are inconsistent, and the calculated total magnetism is also Different. As follows (final self-consistent result for bond length 4.0):

            ITER   TMAG      AMAG      ETOT(eV)       EDIFF(eV)      DRHO       TIME(s)
 1 cores -> CG910  -5.00e-01 7.75e+00  -6.431792e+03  -2.065332e-05  8.526e-08  3.884e+01
14 cores -> CG208  -5.28e-01 7.76e+00  -6.431791e+03  -6.266238e-05  9.077e-08  5.172e+00  
28 cores -> CG248  -4.95e-01 7.75e+00  -6.431792e+03  -2.028726e-04  8.872e-08  3.209e+00

When performing the dpsi calculation, I encountered a problem. I suspect that there is a problem with the file format generated when ABACUS does nspin=2. The problem is reported as follows：

Traceback (most recent call last):
  File "/home/jingan/my_work/2022-9/generate_Fe_orbit/ABACUS-orbitals-main/SIAB/SIAB.py", line 823, in <module>
    mainFunc.main() #!!!
  File "/home/jingan/my_work/2022-9/generate_Fe_orbit/ABACUS-orbitals-main/SIAB/opt_orb_pytorch_dpsi/main.py", line 40, in main
    QI,SI,VI_origin = IO.read_QSV.read_QSV(info_stru, info_element, file_list["origin"], V_info)
  File "/home/jingan/my_work/2022-9/generate_Fe_orbit/ABACUS-orbitals-main/SIAB/opt_orb_pytorch_dpsi/IO/read_QSV.py", line 70, in read_QSV
    qi = read_QI(info_stru[ist+ik], info_element, data)
  File "/home/jingan/my_work/2022-9/generate_Fe_orbit/ABACUS-orbitals-main/SIAB/opt_orb_pytorch_dpsi/IO/read_QSV.py", line 107, in read_QI
    QI[it][il][ib,ia,im,ie] = complex(next(data), next(data))
StopIteration

abacusmodeling / ABACUS-orbitals

BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES #1