BUG: trajectory add/get_particle_info() not compatible with strings

[kay-ro]

Description:

When saving particle type info in the trajectory file, a string can be used as ptype. But when trying to get the info, an error occurs due to the reader expecting an int instead of a string.

Code for reproduction:

import amep
traj_particles=amep.load.traj(path_particles, reload=True)
traj_particles.add_particle_info(1, "key", "value")
traj_particles.add_particle_info("asdf", "key2", "value2")
traj_particles.get_particle_info()

Error message:

---

ValueError Traceback (most recent call last)
Cell In[27], line 1
----> 1 traj_particles.get_particle_info()

File ~/Documents/git_amep/amep/trajectory.py:233, in ParticleTrajectory.get_particle_info(self, ptype)
231 p = {}
232 for t in list(root['particles'].keys()):
--> 233 p[int(t)] = dict(a for a in root['particles'][t].attrs.items())
234 elif str(ptype) in list(root['particles'].keys()):
235 p = dict(a for a in root['particles'][str(ptype)].attrs.items())

ValueError: invalid literal for int() with base 10: 'asdf'

Python and AMEP versions:

1.0.2_dev (github version 10.7.2024), python 3.10

Additional information:

traj_particles.add_particle_info(ptype, key, value)

• Allow only int-ptype.
• Fix amep.trajectory.ParticleTrajectory
• traj_particles.get_particle_info(ptype) should only return info for ptype=int.

How did you install AMEP?

None

[kay-ro]

Feature request: allow iterable of ptypes.

[kay-ro]

ptype might be a string ("CH2" for unified-atom models in MD simulations for example).

[kai-luca]

It is not quite straight forward to make the readers work with strings as particletypes. Since strings are variable length we would need to allocate space that might or might not get used. We gonna have to talk this through again.

[kay-ro]

The GSD format stores the atom types as null terminated strings: https://gsd.readthedocs.io/en/stable/schema-hoomd.html#chunk-particles-types
GROMACS has different labels such as atom type, residue name, ... and allows the atom type to be a string as well https://manual.gromacs.org/current/reference-manual/topologies/particle-type.html But this is only stored in the topology (or .tpr/topology files), not the trajectory files.

Discussion points:

• A solution for the h5amep file format might be to import all atom types and allocate the space according to the larges string.
• One further issue is that the ptype functionality should still work with numbers and not just strings. If the atom type is 1, then the user should be able to access it as the integer 1 and not (just?) the string "1".
• Question: should the user be able to access the ptype information in such a case as integer as well as string?