RuntimeError: The size of tensor a (8) must match the size of tensor b (84) at non-singleton dimension 0.

[Ljiamin195]

Dear the developer of HamGNN,
I encountered an error when training with HamGNN2.0 , ### RuntimeError: The size of tensor a (8) must match the size of tensor b (84) at non-singleton dimension 0. The full error message is in the log.out file. Could you provide some guidance? Additionally, I would like to ask what the meanings of the following two parameters are and how to set them.
irreps_edge_sh and irreps_node_features
log.out.txt

[QuantumLab-ZY]

Hi @Ljiamin195，

Thank you for your feedback and for providing the log files!

Regarding the error you encountered:
RuntimeError: The size of tensor a (8) must match the size of tensor b (84) at non-singleton dimension 0

This error generally indicates a dimension mismatch between two tensors during an operation (such as addition or concatenation). However, since this occurred at the 112th epoch rather than at the beginning of training, it is somewhat unusual and may not necessarily indicate a bug in the code itself. I recommend that you try loading the latest saved model checkpoint and setting resume=True to continue training from where it left off.

Regarding the parameters you mentioned:

• irreps_edge_sh: This describes the spherical harmonics representation or symmetry decomposition associated with edges. It determines how edge directions are represented in 3D space. Common formats look like "1x0e + 1x1o + 1x2e + 1x3o + 1x4e + 1x5o", where the terms represent components of different orders and parities (even/odd).
• irreps_node_features: This describes the irreducible representations of the node features, typically specifying the number of channels and their types. For example, "84x0e" represents 84 scalar (0-order, even) features.

For a more detailed explanation of these parameters, please refer to the relevant section of the README: 'Representation Network Parameters'.

Important Note on Configuration:

I strongly advise against modifying the network parameters unless you have a deep understanding of how they function. It is best to stick to the provided default config.yaml

Currently, your irreps_node_features setting appears to be incorrect. Since your nao_max is set to 19 (corresponding to an atomic orbital basis of 'sssppdd'), the basis requires irreducible representations up to at least 4e. Please check the discussion on "Minimum Irreps for Node and Edge Features" in the README for verification.

If you are unsure about these details, please revert to the default config.yaml to ensure stability.

Let me know if you have further questions

Best,
Yang Zhong

[Ljiamin195]

Dear Professor Zhong,
Thank you very much for your patient reply!

I initially used the default values, but it encountered an error related to insufficient memory. This might be because my structure contains 84 atoms. Therefore, I attempted to modify these two parameters to ensure that it could function properly.

According to the provided "Minimum Irreps for Node and Edge Features," I obtained the minimum irreducible node features for my system as 17x0e+20x1o+8x1e+8x2o+20x2e+8x3o+4x3e+4x4e. Is it sufficient to ensure that each coefficient is greater than or equal to the reference value? For example, setting it like this:

irreps_edge_sh: 0e + 1o + 2e + 3o + 4e
irreps_node_features: 32x0e+32x1o+8x1e+8x2o+32x2e+16x3o+4x3e+16x4e

Best regards,

[QuantumLab-ZY]

Dear @Ljiamin195,

Yes, your proposed setting is valid. As long as the coefficients in your configuration are greater than or equal to the reference values provided by the "Minimum Irreps" guide, the code will function correctly.

However, since you mentioned encountering memory issues with your 84-atom structure, I have a suggestion to help you balance performance and memory usage.

While your proposed setup works, high-order irreducible representations (like 4e) consume significantly more memory and computational resources than low-order ones (like 0e or 1o). To optimize, I recommend increasing the channels for lower orders while slightly reducing the higher orders. This often improves the network's fitting capability while keeping the memory footprint manageable.

Here is a recommended configuration you might try:

irreps_node_features: 64x0e+32x1o+12x1e+12x2o+32x2e+12x3o+8x3e+6x4e

Why this helps:

• More 0e (scalars): These are cheap to compute and essential for capturing basic invariant properties.
• Fewer 4e (high-order tensors): Reducing these saves a lot of VRAM without significantly hurting accuracy for most crystal structures.

Let me know if you have further questions.

Best regards,
Yang Zhong