Slight inconsistensies between groups.

[LVeefkind]

When using the groups for an implementation which is supposed to work regardless of the group, but does need to adapt a few things depending on certain characteristics of the group, I noticed an inconsistency with the 'rotation_order' attribute between the groups ,which can make it a bit convoluted to code up some parts of the logic. Namely: The O(2) and the Dihedral groups have the rotation_order attribute, but the O(3) group, SO(2) group and the Cyclic Group do not (in the case of the cyclic group this rotation order is sort of stored as the N attribute. I think it might make more sense to have all of these have the 'rotation_order' attribute.

Additionally, I am working with the Fourier transform on different groups and as far as I can tell there's no nice way to retrieve which grid types are supported by which group from the code. It would be nice to have this as some stored property for each group, such that it can easily be obtained.

Finally, I also noticed that certain groups, such as the octahedral and the Directproduct groups do not have the bl_irreps method, which is also something. I am not sure if it would be possible to have this for these groups, since I am not too familiar with these groups.

[LVeefkind]

Another thing which might be nice is to have a property for each group denoting whether it contains reflections or not.

[Gabri95]

Hi @LVeefkind

I've included the rotation_order attribute for the cyclic group and for the so(2) group.

Your idea about the list of available grids is nice! I need to think a bit about how to implement it, though.
Indeed, different groups have different kind of grids and some require additional parameters (e.g. SO(3) has a few fixed grids like 'ico', 'cube' or 'tetra' but also some parameterized grids like 'thomson' which requires an additional parameter N).

I also noticed that certain groups, such as the octahedral and the Directproduct groups do not have the bl_irreps method

This is also something hard to build over general groups, since the concept of "band limitation" implies at least a certain ordering of the irreps, such that we can pick only the irreps below a certain maximum frequency. This makes sense for most rotation groups, but it is not really well defined for all irreps of all groups (e.g. for the last irreps of the icosahedral group or the octahedral group).

Once could also combine two groups via a DirectProduct. (approximatively) The resulting group will have an irrep for each pair of irreps of the two initial groups, i.e. the resulting irreps will have 2 separate frequency indexes. As a result, there is some ambiguity on the choice of the frequency index to use to bandlimit (this is worse when one takes the direct product of more than 2 groups).

Another thing which might be nice is to have a property for each group denoting whether it contains reflections or not.
I think this kind of question is better answered via the GSpace abstraction rather than the Group abstraction, since the concept of reflection only makes sense when we think of the group acting on the Euclidean space.

In this case, for example, if you have an instance gs of GSpace3D, you can check if gs.fibergroup contains reflections by looking at gs.sg_id, which tells us which subgroup of O(3) the group gs.fibergroup is.
Check the subgroup table of O(3) here: the subgtroup contains reflections if sg_id[0] == True or sg_id[0] == "fulltetra" or sg_id[0] == "cone"

Hope this helps!
Gabriele

[LVeefkind]

Yes that definitely helps, thanks!