NAO_MAX=14 vs 13 orbitals for carbon-petadiamond in the model pipeline

[ebarati]

Greetings,

I’m trying to understand why the workflow uses nao_max=14 orbitals for carbon-petadiamond instead of the 13 NAOs produced by ABACUS.

Right now the model predicts tensors with 14×14 (196) blocks, while the raw ABACUS matrices for carbon are 13×13 (169). The NPZ builder crashes because it assumes nao_max=14 and applies a boolean mask sized for 196 entries, but the ABACUS data only has 169. Since ABACUS will not output 14 orbitals unless the basis contains them, modifying the physical matrices does not seem correct.

From debugging, it looks like the network was trained with padded orbital blocks (nao_max=14), so the NPZ generator may need to zero-pad 13×13 → 14×14 before flattening rather than forcing ABACUS output to match.

Can you clarify why nao_max=14 was chosen for carbon and whether padding during data prep is the intended behavior? Also, band_cal seems to only support ABACUS Hamiltonians with 27 or 40 orbitals, so I want to confirm the expected format.

Thank you in advance.

[QuantumLab-ZY]

Hi @ebarati,

Here is a clarification on the design choices and how you can resolve the errors you are seeing:

• Why nao_max=14 and Zero-Padding?
  The nao_max parameter represents the maximum number of atomic orbital bases across the entire system or dataset. Because deep learning frameworks require uniform tensor dimensions to process batches efficiently, we set a global nao_max that may be larger than the actual number of orbitals for a specific element.
  The intended behavior during data preparation is exactly what you guessed: zero-padding the raw 13×13 ABACUS matrices to 14×14 before flattening them into 196-entry blocks. This is purely a structural convention for data storage and network training; it does not alter the underlying quantum mechanical basis components.
• How Padding Affects Downstream Calculations:
  When these padded matrices are used later for physical evaluations—such as calculating energy bands—the padding is strictly structural. The computation scripts are designed to apply a boolean mask and skip those extra zeros, ensuring the physical integrity of the 13 NAOs remains completely intact.
• Fixing band_cal:
  You are correct that band_cal currently only supports 27 or 40 orbitals by default. You can resolve this by adding a new basis_def for 13 and 14 orbitals in the script. This will explicitly tell the parser how to correctly slice and mask the Hamiltonian matrices for this specific structure.

Best,
Yang Zhong