Any thoughts on how to handle non-serializable Structure.properties?

[Andrew-S-Rosen]

Recently, a .properties attribute was added to the Structure/Molecule objects in #3264. However, since the user can provide any data they want here, it has the potential to break serialization (same thing with the pre-existing .site_properties, technically, but .properties is more open-ended).

We should think about how we best want to handle this (e.g. do we raise a warning to the user, do nothing at all, sanitize the data, something else?). It's possible that "do nothing at all" is the best approach, as the user will get an error when they try to dump the object if there is something non-serializable in it, but I wanted to open this up for broader discussion anyway.

---

On a related note, in the ASEAtomsAdapter, I have the following line:

pymatgen/pymatgen/io/ase.py

Line 221 in a5b82b5

properties = jsanitize(getattr(atoms, "info", {}))

The jsanitize part was added because oftentimes the atoms.info dictionary contains an entry that is not serializable, like the ASE Spacegroup object when you read in a CIF. By using jsanitize, it ensures that things are always clean. However, it makes me slightly uncomfortable because if someone converts back and forth between Atoms and Structure/Molecule, it's possible that the starting object is not the same due to jsanitize being called on some aspect of the data. Given how often there is non-serializable data in atoms.info, I felt it necessary to not simply ignore it, but I am not convinced that the current approach is ideal and am open to suggestions.

[shyuep]

I would assume properties must be something that can be handled by MontyEncoder. This can be made explicit in the doc.