Coordinate Mismatch Between Calculated and Output Positions in Overlap Matrix Calculation

[Dengsongquanch]

A significant discrepancy exists between the atomic coordinates actually used during the overlap matrix and Hamiltonian calculations in OpenMX and the final coordinates output in the openmx.out file. This inconsistency particularly affects large structures where only two-center integrals are computed, leading to potential inaccuracies in results.
For older data structures, a conversion method using dockfollowed by a downgrade can avoid this issue. However, the current version of dock lacks:
1.A dedicated program for computing overlaps in large structures (similar to legacy DeepH functionality).
2.A utility to convert legacy overlap-only structures (without scfout) to the new format.
To facilitate debugging, we have modified the core code of the overlap-only OpenMX to output the coordinates used during overlap calculations. The modified file is attached.
Steps to Verify the Issue:
1.Replace the corresponding file in the source folder of your overlap-only OpenMX build with the provided file.
2.Recompile the code using make.
3.Run the program. It will now generate a coordinate .dat file in the output folder alongside the standard results.
4.Compare this generated .dat file with the site_positions.dat obtained from Task 1. Any inconsistencies indicate the bug is present.
Important Notes:
This modified code is provided for debugging purposes only​ and does not fix the underlying bug. If discrepancies are found, the recommended course of action is to strictly adjust the atomic coordinates to the range (0,1) before recalculating. We hope future versions of dock will provide a permanent solution for the coordinate issues in large structures requiring two-center integral calculations.

I don't know why I can't upload code files. I will explain which part needs to be added and where it is located. The file that needs to be modified is Set_OLP_Kin.c in source folder , around line 105：

  OneD_Nloop = 0;
+  if (myid == Host_ID) {
+      FILE *fp;
+      fp = fopen("output/coords_used_in_Set_OLP_Kin.dat", "w");

+      fprintf(fp, "# Coordinates used in Set_OLP_Kin\n");
+      fprintf(fp, "# unit\n");
+      fprintf(fp, "# GA_AN    x            y            z\n");

+      for (int GA_AN = 1; GA_AN <= atomnum; GA_AN++) {
+          fprintf(fp, "%5d  %20.14f  %20.14f  %20.14f\n",
+                  GA_AN,
+                  Gxyz[GA_AN][1]*0.529177249,
+                  Gxyz[GA_AN][2]*0.529177249,
+                  Gxyz[GA_AN][3]*0.529177249);
+      }

+      fclose(fp);
+  }

  for (Mc_AN=1; Mc_AN<=Matomnum; Mc_AN++){
    Gc_AN = M2G[Mc_AN];    
    for (h_AN=0; h_AN<=FNAN[Gc_AN]; h_AN++){
      OneD2Mc_AN[OneD_Nloop] = Mc_AN; 
      OneD2h_AN[OneD_Nloop]  = h_AN; 
      OneD_Nloop++;
    }
  }

[kYangLi]

Thank you for the detailed explanation and precise location. We have received feedback regarding the inconsistency of atomic coordinates in OpenMX, and the case you described along with the debugging method is very clear and highly valuable.

We are currently developing a dedicated module in DeepH-dock for calculating overlap integrals in large structures, which will fundamentally address the coordinate consistency issue in the current two-center integral calculations. We expect this issue to be fully resolved in an upcoming release in the near future. In the interim, if you encounter discrepancies in calculation results, we recommend following the temporary solution you mentioned: strictly adjusting atomic coordinates to the (0,1) range before recalculating to ensure result reliability.

Once again, thank you for your thorough investigation and valuable modification suggestions.