Unable to instantiate R3IcoConv

[kalekundert]

I'm running into an error when trying to use the R3IcoConv module. Here's some code that generates the error:

from escnn.nn import *
from escnn.gspaces import *

gspace = icoOnR3()

in_type = FieldType(gspace, [gspace.trivial_repr])
out_type = FieldType(gspace, [gspace.regular_repr])

conv = R3IcoConv(in_type, out_type, 3)

And here's the error itself:

________________________________________________________________________________
[Memory] Calling escnn.group.groups.ico._build_ico_irrep...
_build_ico_irrep(Icosahedral, 3)
__________________________________________________build_ico_irrep - 9.3s, 0.2min
________________________________________________________________________________
[Memory] Calling escnn.group.groups.ico._build_ico_irrep...
_build_ico_irrep(Icosahedral, 4)
__________________________________________________build_ico_irrep - 9.2s, 0.2min
Traceback (most recent call last):
  File "/home/kale/research/software/projects/atompaint/tests/foo.py", line 11, in <module>
    conv = R3IcoConv(in_type, out_type, 3)
  File "/home/kale/.pyenv/versions/3.10.0/lib/python3.10/site-packages/escnn/nn/modules/conv/r3_ico_convolution.py", line 99, in __init__
    super(R3IcoConv, self).__init__(
  File "/home/kale/.pyenv/versions/3.10.0/lib/python3.10/site-packages/escnn/nn/modules/conv/r3convolution.py", line 160, in __init__
    super(R3Conv, self).__init__(
  File "/home/kale/.pyenv/versions/3.10.0/lib/python3.10/site-packages/escnn/nn/modules/conv/rd_convolution.py", line 223, in __init__
    self._basisexpansion = BlocksBasisExpansion(in_type.representations, out_type.representations,
  File "/home/kale/.pyenv/versions/3.10.0/lib/python3.10/site-packages/escnn/nn/modules/basismanager/basisexpansion_blocks.py", line 72, in __init__
    block_expansion = block_basisexpansion(basis, points, basis_filter=basis_filter, recompute=recompute)
  File "/home/kale/.pyenv/versions/3.10.0/lib/python3.10/site-packages/escnn/nn/modules/basismanager/basisexpansion_singleblock.py", line 144, in block_basisexpansion
    for b, attr in enumerate(basis):
  File "/home/kale/.pyenv/versions/3.10.0/lib/python3.10/site-packages/escnn/kernels/basis.py", line 247, in __iter__
    for attr in basis:
  File "/home/kale/.pyenv/versions/3.10.0/lib/python3.10/site-packages/escnn/kernels/steerable_basis.py", line 547, in __iter__
    assert idx < self.dim
AssertionError

I tried a few different kernel sizes and both the 'ico' and 'dodeca' samples, but neither had any effect. I'm not sure if this is a bug, or if I'm doing something wrong.

---

On a related note, I'm not totally sure I understand when to use R3IcoConv vs R3Conv. Below are some bullet points outlining my thoughts on this. Can you take a look and let me know if I'm on the right track or not?

• With R3Conv, the kernel parameters are used to make linear combinations of spherical harmonics, so you can think of the parameters as Fourier coefficients.
• With R3IcoConv, the kernel parameters are associated with vertices of a icosahedron/dodecahedron/icosidodecahedron, so they live entirely in the spatial domain and aren't Fourier coefficients.
• Smooth functions don't require many frequencies to represent in the Fourier domain, but "spiky" functions do. So if you want spiky filters, R3IcoConv should work better. If you want smooth filters, R3Conv is fine.
• I also assume that R3IcoConv is more efficient, since it's specialized to the specific case of icosahedral symmetry, but I have no idea if this is true.

This leads to a few follow-up questions:

• Would you ever recommend using R3Conv instead of R3IcoConv with the icoOnR3 gspace?
• I notice that it takes ≈20s to build the icosahedral irreps when instantiating the icoOnR3 gspace. Are these irreps actually used by R3IcoConv? I know that in the 2D case, you can do group convolutions that are C(n)-equivariant with standard, unconstrained kernels by "lifting" the input to a higher dimension. Can R3IcoConv be thought of as a 3D version of this? If so, I'd expect that it wouldn't be necessary to calculate irreps. I suspect that this analogy is just wrong, but I'm not sure.

Thanks for taking the time to help me understand this. I've watched Erik Bekkers' lecture series on equivariant learning, so I feel like I have a some grasp on the fundamentals, but this is all still quite new to me.

[Gabri95]

Hi @kalekundert

Thanks a lot for spotting this issue! I introduced a small bug recently which indeed broke the steerable bases used to construct R3IcoConv. This is fixed now!

Regarding the question:

Would you ever recommend using R3Conv instead of R3IcoConv with the icoOnR3 gspace?

I would generally recommend using R3Conv always. The R3IcoConv is using an unstable steerable basis (it often doesn't pass the equivariance tests) and it was implemented to demonstrate the benefits of the harmonic bases used in R3Conv (see Figure 5 in our paper).

I am realising now that this is not emphasised in the documentation. I'm sorry for the confusion, I'll add a warning about this!

I know that in the 2D case, you can do group convolutions that are C(n)-equivariant with standard, unconstrained kernels by "lifting" the input to a higher dimension. Can R3IcoConv be thought of as a 3D version of this?

Yes, that's correct, as long as you use an output regular representation.

If so, I'd expect that it wouldn't be necessary to calculate irreps. I suspect that this analogy is just wrong, but I'm not sure.
Are these irreps actually used by R3IcoConv?

This library implements general steerable CNNs, of which group convolution is just a special case given by the choice of the regular representation.
Moreover, unless one considers only the discrete group of symmetries of the grid (e.g. C_4 or the octahedral group), lifting unconstrained kernels still requires express them in terms of a steerable basis (as done for C_N equivariance in this paper). Working with a steerable basis implicitly implies working with the group's irreps.

For these reasons, we still need the irreps of the Icosahedral group to implement a GCNN equivariant to this group.

I notice that it takes ≈20s to build the icosahedral irreps when instantiating the icoOnR3 gspace

This should have been fixed thanks to your pull-request ;)

Hope this helps and sorry for the delay in my answer!
Gabriele