Sites class

[zerothi]

Then there could also be a Sites class and a Geometry would be the combination of Lattice, Sites and Atoms. A combination of only Sites and Lattice could implement the purely geometrical methods that are now implemented in Geometry, which maybe would be useful for other things. The first thing that comes to mind is k points in the reciprocal lattice, but I'm sure it could have other applications e.g. in situations where you have a sparse sampling of space :)

Originally posted by @pfebrer in https://github.com/zerothi/sisl/issues/550#issuecomment-1468848466

[zerothi]

I have some related issues #196 and #11.

What is the purpose of Sites besides having coordinates without lattice information? Where would this be used, and what methods should it provide?

Especially #11 would be great and thus Sites and this feature could co-exist, I have long wanted some way of attaching common data together and make it co-exist with the geometry, forces, velocities, etc. But I am still struggling with the many routines that alter things and what should you then do with the associated data?

[pfebrer]

I like the idea to combine it with the forces! So Atoms would in some sense be also "associated data". Hmm or perhaps it gets too abstract. I have to think about the implications and whether there is some benefit :sweat_smile:

My idea was that methods that depend only on coordinates would be implemented in the base class: translate, rotate, center, close (neighbour finding)... And then Geometry (or whatever other class) would have an interface to use them with the extra arguments (atoms...).

[pfebrer]

But if you think of it as

class PointCloud:
    lattice = Lattice()
    sites = Sites()

    associated_data = [
        Atoms()
    ]

Then PointCloud would implement these methods and the associated data would have the definitions of how it transforms with them. I would say there are not so many methods that would go into PointCloud so I don't see that much of a hassle in specifying the behavior of data with them. I see no option other than specifying behavior if you want it to behave as you wish :sweat_smile:

We could start defining the behavior of SiteProperty (does not depend on the environment -chemical species, orbitals, etc...-), InvariantData (does not change with translations or rotations, with undefined behavior for other changes -number of neighbors...-) and EquivariantData (does not change with translation, rotates with rotations, and undefined behavior for other changes -forces, Hamiltonian, DM...-). Then see how it goes.

[zerothi]

Well, consider a geom.translate(atoms=range(1, 3), the forces/velocities etc. would undeniably be changed in the real calculation, but the associated data will not, so either it should be deleted, or what should it then do?

It would be great if the complexity doesn't get too bad...

[pfebrer]

In that case it is undefined behavior, so the associated data would be removed. It makes no sense to keep forces data in this operation.

Of course the user could add plugins to specify how they WANT the data to behave in this operation, but it is not something that makes sense scientifically.

[zerothi]

All of this is great, -- but it sounds like a complicated implementation :(

[pfebrer]

Hmm I don't see it that complicated to implement, but perhaps I'm too optimistic :sweat_smile:.

I could give it a try when I have time, now I'm finishing the details of the new viz module and the new sisl-gui, which is looking very nice btw, I think you'll be surprised on how useful it can be :)

[zerothi]

I am already quite surprised how good it is ;)