Installation of HONPAS/SIESTA unclear

[kaitrepte]

Hi,

I have been looking at the HamGNN tool for a little bit now.
I have been trying to get my own SIESTA version to be compatible with
this tool, which seems impossible.
However, your documentation on how to use your provided honpas is unclear,
as it does not explain at all how to actually install and use it.
"""
honpas_1.2_H0: This is a modified version of HONPAS used to parse and compute overlap matrices and non-self-consistent Hamiltonian matrices H0, similar to the openmx_postprocess tool. The output is a binary file (overlap.HSX) containing Hamiltonian data.

hsxdump: This is a binary executable that generates Hamiltonian intermediate files, essential for converting HONPAS output to HamGNN-readable format.
"""

As such, I have two questions: Could you please extend your documentation wrt the installation of your provided HONPAS/SIESTA version?
And furthermore, it would be significantly more helpful to be able to connect it to a SIESTA installation which is independent
of your tool, given that you just use it to get the DFT data. SIESTA > 5 has been out for a while, but your in-house honpas
seems to be based on SIESTA 4.X

[QuantumLab-ZY]

Hi @kaitrepte,

Thanks for the feedback! We agree that the SIESTA/HONPAS integration needs better documentation.

We're actively working on a set of preprocessing scripts tailored for SIESTA 5.4.2 that will significantly simplify the data packaging workflow for HamGNN. These scripts will handle the Hamiltonian matrix extraction and format conversion automatically, so users won't need to rely on our in-house modified HONPAS build anymore.

We're testing the scripts internally and plan to release them within the next few days, along with updated installation documentation covering the full SIESTA 5.4.2 → HamGNN pipeline.

We'll update this issue once it's available. Stay tuned!

[kaitrepte]

Hi,

is there any updates on this issue?

[QuantumLab-ZY]

Hi @kaitrepte,

Thanks for following up, and sorry for the delay.

We have now finished the SIESTA 5.4.2 interface for HamGNN and released it here:

https://github.com/QuantumLab-ZY/LCAO-DFT-Interface-to-HamGNN

This new interface is intended to replace the previous workflow based on our in-house modified HONPAS/SIESTA 4.x version. It supports extracting and converting LCAO-DFT data from SIESTA 5.4.2 into the HamGNN-readable format, so users no longer need to rely on the bundled HONPAS build for preprocessing.

Please check the README in the new repository for installation and usage instructions. If you encounter any problems or find anything unclear, feel free to let us know.

Best regards,
Yang Zhong

[kaitrepte]

Thank you for the update!

One question: I want to use our local SIESTA version, which is 5.2.2.
Is this possible? It would be so much easier to do this instead of having to compile the shipped version from you guys.
If I can do it, what kind of keywords would I need to set to write the needed information, i.e. SIESTA output files?

Best,
Kai

[QuantumLab-ZY]

Hi @kaitrepte,

Thanks for the question.

For HamGNN, the workflow requires first generating H0 using our modified *_postprocess tool. Here, H0 is the analytical part of the Hamiltonian matrix in the atomic-orbital basis. For training-data generation, this H0 is then packaged together with the fully self-consistent Hamiltonian H obtained from the original DFT calculation.

If you already have a trained HamGNN model and only want to perform prediction for a material system, then only H0 is required. In that case, you do not need to rerun the full self-consistent DFT calculation; running the modified *_postprocess tool to export H0 is sufficient.

Therefore, installing the siesta_process-5.4.2 package provided in our interface repository is currently necessary. The released interface is based on this modified SIESTA 5.4.2 workflow, and we do not currently guarantee compatibility with an independent, unmodified SIESTA 5.2.2 installation.

Best regards,
Yang Zhong

[kaitrepte]

Hi,

Ok.
What are the changes that were made to SIESTA? Is it some extra postprocessing of SIESTA data, some additional data generation, or something else?

Best,
Kai

[kaitrepte]

I have been trying to get this to run.
I am running a nonSCF and a SCF simulations.
Putting the .HSX files into a folder.
Trying to run the provided script.
I am using graphene as an example.

It keeps telling me

siesta.0.HSX: Orbital index 17 exceeds NAO_MAX=13

This is independent of the basis set used, or whether I run the simulation closed-shell or open-shell.

Any advice?

[kaitrepte]

Any help would be greatly appreciated

[QuantumLab-ZY]

Hi,

Ok. What are the changes that were made to SIESTA? Is it some extra postprocessing of SIESTA data, some additional data generation, or something else?

Best, Kai

Hi @kaitrepte,

Sorry, I had some very important matters to deal with recently, so I didn't reply to you in time.

The main changes we made to SIESTA 5.4.2 in siesta_process-5.4.2 are:

1. H0 Export Functionality (*_post_process tool)

We added a post-processing capability to export the non-self-consistent Hamiltonian matrix H0, which represents the analytical part of the Hamiltonian in the atomic-orbital basis. This H0 is essential for HamGNN because:

• During training, H0 is packaged together with the fully self-consistent Hamiltonian H from the original DFT calculation.
• During prediction (with a trained model), only H0 is needed—you don't need to rerun the full SCF calculation.
  The tool outputs the H0 data in a .HSX binary file format (e.g., <prefix>.0.HSX), which our graph_data_gen_siesta.py script can then convert to HamGNN-readable .npz format.

2. Bug Fix in configured_values_m.F90.in

We fixed a syntax error in the source file Src/configured_values_m.F90.in (around lines 5-14). When ELPA is not enabled, the original code leaves ELPA GPU parameters empty, causing a compilation failure. We added default values for these parameters when ELPA is disabled:

#ifdef SIESTA__ELPA
  use elpa
  character(len=*), public, parameter :: elpa_gpu_string ="@SIESTA_ELPA_GPU_STRING@"
  integer, public, parameter :: SIESTA_ELPA_REAL_GPU_KERNEL = @SIESTA_ELPA_REAL_GPU_KERNEL@
  integer, public, parameter :: SIESTA_ELPA_COMPLEX_GPU_KERNEL = @SIESTA_ELPA_COMPLEX_GPU_KERNEL@
#else
  ! Default values when ELPA is not enabled
  character(len=*), public, parameter :: elpa_gpu_string = "none"
  integer, public, parameter :: SIESTA_ELPA_REAL_GPU_KERNEL = -1
  integer, public, parameter :: SIESTA_ELPA_COMPLEX_GPU_KERNEL = -1
#endif

The installation process is exactly the same as the official original version of Siesta. SIESTA/BUILD_STEPS_EN.md is the installation process on the supercomputer I use, and it can be used as a reference for you.

Best regards,
Yang Zhong

[QuantumLab-ZY]

I have been trying to get this to run. I am running a nonSCF and a SCF simulations. Putting the .HSX files into a folder. Trying to run the provided script. I am using graphene as an example.

It keeps telling me

siesta.0.HSX: Orbital index 17 exceeds NAO_MAX=13

This is independent of the basis set used, or whether I run the simulation closed-shell or open-shell.

Any advice?

Hi @kaitrepte,

Thanks for reporting this issue.

The error Orbital index 17 exceeds NAO_MAX=13 occurs because the basis set you used in SIESTA generates more than 13 orbitals per atom, which exceeds the current limit in graph_data_gen_siesta.py.

Root Cause

The script uses a fixed NAO_MAX = 13 parameter. The predefined basis mapping (basis_def_13_siesta) assumes a DZP-type basis (s1 + s2 + p1 + p2 + d1 = 13 orbitals) for elements like C. If your SIESTA input uses a larger basis (e.g., TZTP, or includes additional polarization shells), the orbital indices in the HSX file will exceed 13.

Solution

To fix this, ensure your SIESTA basis configuration is compatible with the NAO_MAX = 13 limit. For carbon (C), use a basis like:

C  2
  s  2  0.00  1.0   # s1, s2 orbitals
  p  2  0.00  1.0   # p1, p2 orbitals
  d  1  0.00  1.0   # d1 orbital

This gives exactly 13 orbitals per atom (1 + 1 + 3 + 3 + 5 = 13). Avoid using:

• Triple-zeta bases (s3, p3, d2, etc.)
• Additional polarization shells beyond the first d-shell

If you need larger basis sets, modifying NAO_MAX in the script would be required, but this also necessitates corresponding changes to the basis_set_definitions mapping and potentially the output tensor dimensions. We can explore adding support for larger bases if this is important for your workflow.

Additional Note

There's also a basis_def_19_siesta mapping defined in the script (NAO_MAX=19), but it's currently not activated by default. If you're interested in using larger basis sets, let us know and we can work on enabling this option.

Best regards,
Yang Zhong