After playing around with some more complex structures and using starting_ns_eigenvalues constraints, I get reproducible crashes every time the hp.x code emits entries of the form atom_** (e.g. O_** in my case ) in the chi-matrix output.
To my understanding, these should not be parsed as atom indeces -- but the code in aiida_hubbard/parsers/parse_raw/hp.py tries to read them, which leads to a crash later on as O_** are not valid AiIDA link labels.
If my understanding is correct, guarding the parser (in HParallelizeAtomsWorkChain.run_atoms()) against non-numeric indices could fix the problem. To my understanding, outputs with atom_** do not correspond to actual atomic indices and should not be treated as such.
Environment
- aiida-hubbard: 0.3.0
- QE: 7.3.1
- AiiDA: 2.7.1
- Python: 3.12
After playing around with some more complex structures and using
starting_ns_eigenvaluesconstraints, I get reproducible crashes every time thehp.xcode emits entries of the formatom_**(e.g.O_**in my case ) in the chi-matrix output.To my understanding, these should not be parsed as atom indeces -- but the code in
aiida_hubbard/parsers/parse_raw/hp.pytries to read them, which leads to a crash later on asO_**are not valid AiIDA link labels.If my understanding is correct, guarding the parser (in
HParallelizeAtomsWorkChain.run_atoms()) against non-numeric indices could fix the problem. To my understanding, outputs withatom_**do not correspond to actual atomic indices and should not be treated as such.Environment