Skip to content

[RFC] Representing symmetries

Created by: attila-i-szabo

Space groups

A limitation of the "interpretable" symmetry group implemented in #702 is the kinds of point group that can be easily represented in it. Namely, we are restricted to dihedral groups that act within a Cartesian coordinate plane. This is enough in 2D, but 3D space groups do get more complicated (e.g. on the cubic lattice).

I would recommend to introduce a PointGroup class for point-group symmetries (I think finite translation groups are better handled by the Lattice class that knows how large the lattice is). Its elements would be objects that transform Cartesian coordinates (and maybe calculate preimages too):

class PGSymmetry:
    M: np.ndarray

    def __call__(x: np.ndarray):
        return M @ x

    def preimage(x: np.ndarray):
        return np.linalg.inv(M) @ x # store inv(M) too?

The symmetries of the actual lattice are still better written in terms of permutations of sites (e.g. it makes constructing times tables for DenseEquivariant easier). We could have a method in either PointGroup or Lattice (I think the latter makes more sense because we can have different graphs with different implementations) that turn a PGSymmetry into a permutation. The result could be semidirect-producted [1] with the translation group, which would be generated the same way as it is now, without direct reference to actual geometry.

Once this is done, we could offer a catalogue of ready-made common point groups:

[1] SemiGroup::@ is not a direct product, for we don't check whether the elements commute. I think it would usually be a semidirect product in the cases we care for.

Nice things to potentially add to PGSymmetry

  • Automatic generation of human-readable description from M.
    • In 2D, this could take the form rotation by ...°, reflection across axis at ...°.
    • In 3D, it gets a bit lengthier: rotation by ...° around (x,y,z), reflection across plane (x,y,z), inversion, rotoreflection (not even sure how to describe it)
    • I wouldn't worry about higher dimensions
    • Of course, passing a label should still be an option, but having autogeneration would be nice for bigger, more complicated groups
  • A routine that shows which group elements preserve a wave vector k. This (together with naming them as above) will be very helpful for users who want to pass little-group irreps to build broken-symmetry wave functions. This will probably have to cooperate with Lattice too since it has to check for equality modulo reciprocal lattice vectors...

Non-space-group symmetries

It would also be nice to support symmetries beyond the space group. A good example is parity symmetry in spin systems, which is very useful for calculating spin gaps, etc.

This requires us to generalise SymmGroup beyond permutation groups, as well as DenseSymm to embed input vectors into groups that aren't just permutations. A most general SymmGroup has to provide two things:

  • A times table (or rather a table of g–1h) for DenseEquivariant
  • The logic of DenseSymm. For a general symmetry we need a function that takes care of the all aspects of the convolution in DenseSymm::__call__; in some cases (permutations, permutations+parity), we could get away with tweaking full_kernel.

I'd recommend that we keep SymmGroup as the base class (i.e. we take it to mean "symmetry group of the Hamiltonian" and call the permutation groups that encode graph symmetries GraphGroup, and make it a subclass of SymmGroup

For the specific case of parity, I'd define a ParityGroup that wraps another SymmGroup and doubles its size. I don't think @ing would cut it in this case, because we need to provide a times table and the logic, which is not done by a basic SemiGroup.

Odds and ends

  • We could take this refactoring to collect everything symmetry-related (the space group of Grid, SemiGroup, etc.) into one place, say netket.symm

@chrisrothUT @femtobit @PhilipVinc @fabienalet @gcarleo what do you think?