thanks!
maybe adding in the Analysis doc that "Valences" corresponds to pymatgen's BVAnalyzer output would be a good idea.

and maybe a small note in the Analysis docstring that it can be either instantiated with the file paths or with the pymatgen objects (and the latter if both are given) would add some clarity.
although with the charges it seems that if both are given, the ones from the file instead of the object are processed in LobsterNeighbors (so the other way around)?

thanks! maybe adding in the Analysis doc that "Valences" corresponds to pymatgen's BVAnalyzer output would be a good idea.

and maybe a small note in the Analysis docstring that it can be either instantiated with the file paths or with the pymatgen objects (and the latter if both are given) would add some clarity. although with the charges it seems that if both are given, the ones from the file instead of the object are processed in LobsterNeighbors (so the other way around)?

Fixed the issue with charges and updated the doc-strings as suggested.

Hi @tomdemeyere , @JaGeo . I have added this small update to analysis class that also enables using loewdin charges besides exposing some nested attributes.

Would be great if this can be reviewed/merged.

Also as side note @kaueltzen does not seem to have write access to this repository, would be great if this can be added too.

Hi @tomdemeyere , is there anything else you think needs to be addressed in this PR before it is merged?

A separate major refactor PR will be raise soon to incorporate your previous suggestions. Also feel free to add more stuff in todos in this #410 issue if you spot anything that could be improved.

A final word: I am not sure about FeaturizeLobsterpy as a class:

• There is no state sharing and no inheritance.
• Only one public method, the rest is static, essentially functions wearing a class costume.
• Very simple behavior: input -> process -> output.

Conceptually, this code should be purely functional, no objects are needed. Maybe there are other plans/considerations that I am missing justifying the use of a class, in which case discard this comment :)

A final word: I am not sure about FeaturizeLobsterpy as a class:

• There is no state sharing and no inheritance.
• Only one public method, the rest is static, essentially functions wearing a class costume.
• Very simple behavior: input -> process -> output.

Conceptually, this code should be purely functional, no objects are needed. Maybe there are other plans/considerations that I am missing justifying the use of a class, in which case discard this comment :)

Thanks, @tomdemeyere, for pointing this out. I have noted it. I will also think about it during refactoring. For now, I will keep it as it is. If nothing else needs to be addressed concerning the changes, can it be merged?