Geometry collections -- trajectories about sisl

[tfrederiksen]

Seeing sisl also as a generic tool to interact with different DFT codes, and as a parser between file formats, I think it would be good to have a container for multiple geometries. A new GeometryCollection would naturally allow for a write function, e.g., to the xyz and ani formats. Note that the number of atoms (and types) may not need to be the same in the most general case.

[pfebrer]

Hmm I see your point. It seems like implementing MD trajectory algorithms in sisl is a bad idea. However, we could pick one of those packages and interface nicely with it. I agree that trajectory analysis tools seem to be a bit outside sisl's scope, but perhaps there are functionalities that can be built on top of those algorithms that are more related to electronic structure.

I guess the reason I wanted this functionality is because I use sisl for everything so it felt odd that I couldn't use it when I started to be interested in trajectories. But it makes sense that I have to use different tools for different parts of science. Perhaps in that case you could add a section on sisl's README stating "what sisl is not" after the "features" section. Or somehow set the bounds on what sisl should be able to deal with so that it is clear for everyone and there is less divergence moving forward.

[pfebrer]

Note that the number of atoms (and types) may not need to be the same in the most general case.

I also thought about a more general GeometryCollection, but in that case there is no shared data between geometries, so I don't see a clear advantage vs a simple list of Geometry objects.

[tfrederiksen]

Perhaps a simple advantage from the user perspective would be to have a single write_geometry method to a single file (xyz/ani).

[pfebrer]

Does it make sense that an ANI/xyz file contains coordinates of different structures?

[tfrederiksen]

Does it make sense that an ANI/xyz file contains coordinates of different structures?

Good question. As far as I can see there is no limitation on these file formats. Maybe users simply want to concatenate different systems to a single file for storage and retrieval?

[zerothi]

I basically agree on all your points. My main worry is that it will be hard to not implement somethings related to MD, and the border between supporting something or nothing is vague in this case.

I'll revisit @pfebrer 's PR for the collection, that could fit in nicely.

Seeing sisl also as a generic tool to interact with different DFT codes, and as a parser between file formats, I think it would be good to have a container for multiple geometries. A new GeometryCollection would naturally allow for a write function, e.g., to the xyz and ani formats. Note that the number of atoms (and types) may not need to be the same in the most general case.

I agree, this would be ideal.

Hmm I see your point. It seems like implementing MD trajectory algorithms in sisl is a bad idea. However, we could pick one of those packages and interface nicely with it. I agree that trajectory analysis tools seem to be a bit outside sisl's scope, but perhaps there are functionalities that can be built on top of those algorithms that are more related to electronic structure.

True, lets first get the collection in, then lets see.

I guess the reason I wanted this functionality is because I use sisl for everything so it felt odd that I couldn't use it when I started to be interested in trajectories. But it makes sense that I have to use different tools for different parts of science. Perhaps in that case you could add a section on sisl's README stating "what sisl is not" after the "features" section. Or somehow set the bounds on what sisl should be able to deal with so that it is clear for everyone and there is less divergence moving forward.

Yeah, that is also difficult. If it is not on the "not" list, then it must be "in", or it was just forgotten to be written on the "not" list. Hmm.. I don't see a big win there. I think adding a dispatcher to the GeometryCollection to convert to MDanalysis or the likes would be the easiest solution (although not the fastest).

Does it make sense that an ANI/xyz file contains coordinates of different structures?

Good question. As far as I can see there is no limitation on these file formats. Maybe users simply want to concatenate different systems to a single file for storage and retrieval?

I think it could make sense if you are doing multi stuff with MD for a molecule and a molecule + X, then merging them together could be useful in some circumstances. I see no reason to enforcing the same atoms for all elements.

I have one problem though, in Geometry I have long wanted a way to attach attributes to the Geometry for instance velocity, magnetic moment, forces etc. But I have yet to come up with a simple way to store details that will automatically allow changes to the structure to automatically process the contained data, for instance .sub, .tile, .rotate etc.

[pfebrer]

I have one problem though, in Geometry I have long wanted a way to attach attributes to the Geometry for instance velocity, magnetic moment, forces etc. But I have yet to come up with a simple way to store details that will automatically allow changes to the structure to automatically process the contained data, for instance .sub, .tile, .rotate etc.

That would be very nice if everything is treated automatically! I think the most robust way would be to define how data types behave with those operations and then specify the data type of your stored data (scalar, vector, matrix, ...).

I could help with the specification of how matrices transform with the rotate method, since I know understand most of it :)

[zerothi]

Thanks, the problem is mostly that I don't think it is a good way to do this for all methods that change something, we would need some Geometry._internal_changer class which can take into account everything... but I haven't had a chance to really dig into this...

[pfebrer]

How can you expect that things are modified appropriately if you don't specify it for every method? I don't understand 😅

[zerothi]

How can you expect that things are modified appropriately if you don't specify it for every method? I don't understand sweat_smile

Exactly :) it is just a nightmare to do this for all methods that changes something... I think it would be error-prone!!! The same problem I have with the names, I think they are a good idea, but the code will be cluttered with names handlings... ARGH

[pfebrer]

Hmm yes but for quantities that are atom-wise or orbital-wise I think it would not be so difficult, no?. The names thing is more difficult of course. Unless what you have is an atom-wise value specifying the group of each atom.

[pfebrer]

You could also do something similar to what xarray does with dataset attributes. If the behavior of the attributes with the operation is well defined, it keeps them in the new dataset, otherwise it doesn't.