Skip to content
Snippets Groups Projects

Add space group permutations to grid.py

Closed Vicentini Filippo requested to merge github/fork/chrisrothUT/master into master

Created by: chrisrothUT

I added space group permutations to grid.py. I also added a function which takes the translation group permutations and adds the space group on top.

Merge request reports

Closed by avatar (Apr 23, 2025 8:38am UTC)

Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
145 145
146 146 return [translate(el, identity) for el in translation_group]
147 147
148 def space_group(self, identity=None) -> List[List[int]]:
  • Created by: femtobit

    identity is probably no longer the best term here.

    If you pass identity=[[[0, 1, 2, ..., N - 1]]], that is, the actual identity permutation, you would get only the space group, right?

    I'm not sure what a better name is at the moment, though.

  • Created by: chrisrothUT

    Yes, the space group is rotations and reflections. I think a rotation is the coordinate mapping (i,j....)->(-j,i...) which I've accomplished with two reflections. I can do this, just have to think a bit about how do handle ndim > 2.

    I will think about a new name for "identity".

  • Created by: femtobit

    Review: Commented

    Thanks @chrisrothUT, that's very helpful already!

    The space group consists of both rotations and reflections, right? It would be helpful to split space_group into two methods to have both types of symmetries available separately as well.

  • Created by: chrisrothUT

    I will add some tests.

    I think it would be hard to write something general with only access to [edges, nodes] but I'd be happy to know if I'm missing something. The easiest way would be to have common 2D lattices in Netket and implement their symmetry group by hand. I'd be willing to work on this.

  • Created by: femtobit

    Also, how hard would it be to generalize this to arbitrary lattices, or only lattices with point symmetries such as triangular, exhagonal...

    I think it would be great to have a general way of specifying these symmetries. As @chrisrothUT points out, it's hard to get anything for an arbitrary graphs (finding the general symmetry group and its decomposition into subgroups sounds like a cool graph/group theory problem, but is probably way out of scope for NetKet) except for the unstructured data we get from automorphisms. But we can already do a lot for the Grid, and we should definitely have a general interface that in principle works for all lattice types (even though one might need custom implementations).

    This is not necessarily in the scope of this PR; IMHO it would be fine for @chrisrothUT to add the space group symmetries here and then we can make it more general as a next step.

    But let me still brainstorm a bit here: The symmetry groups we are interested in are all direct products of elementary operations like translations, rotations, and reflections. (Right?) For example a 2D grid has FullSymmetries = Translations(dim=0) × Translations(dim=1) × Rotations × Reflections (plus maybe some hidden symmetries like the 4D ones @fabienalet pointed out in #588 (closed)).

    I imagine we could have a general interface like this:

    p1 = g.symmetries("translation")                           # == g.periodic_translations()
    p2 = g.symmetries("rotation", "reflection")                # == g.space_group()
    p3 = g.symmetries("translation", "rotation", "reflection") # == g.lattice_group()

    That is, users could specify a sequence of subgroups and the method returns the permutations corresponding to the direct product (in the desired order). This could even allow more unusual combinations like

    # Only translations by multiples of two sites along first dimension plus reflections
    p4 = g.symmetries(("translation", {"dim": 0, "period": 2}), "reflection")

    This is starting to look a bit over-engineered, but on the other hand, the group product can be realized just like @chrisrothUT is doing it right now in the implementation of lattice_group and the rest is mostly just implementing the elementary operations of each subgroup.

    What do you think?

  • Created by: chrisrothUT

    @femtobit that functionality sounds pretty useful. Frequently the ground state or low lying exciting states have some broken symmetry so it's good to be able to specify a sub-group. This project does seem pretty ambitious, perhaps we could start by implementing this for periodic 2D lattices?

  • Created by: gcarleo

    since we are brainstorming here, but wouldn't it me much easier to implement generic translation symmetries in graph.Lattice instead of grid?

  • Created by: femtobit

    @chrisrothUT Indeed - it's pretty ambitious; the good thing is, it is possible to start with what we have right now - once your PR here is finished - and at first implement symmetries(...) for Grid with support for translations + space group.

    Then, additional symmetries (or finer control over existing symmetries) can be added latter in a backwards-compatible way and also to other graph types.

    @gcarleo Since Lattice is not a superclass of Grid, we'd have to do the work here anyways. So I think it's fine to start here, in particular since implementing symmetries on the grid is comparatively easy. Implementing hexagonal lattices etc. using Lattice is then an option for the future.

  • Created by: PhilipVinc

    @femtobit i aree with you, but I just want to get the API/interface right before merging, so that later work needs only to implement algorithms.

    I'm thinking... might it make sense to make Grid a subclass of Lattice? I know lattice does a lot of other things, but we might come up with some sensible defaults

  • Vicentini Filippo mentioned in merge request !600 (merged)

    mentioned in merge request !600 (merged)

  • Created by: femtobit

    An updated version of the space group code is now part of PR #600 (via femtobit#2), so this one can be closed.

  • Please register or sign in to reply
    Loading