Very large model files when using equivariance

[quva-lab]

Very large model files when using equivariance

[drewm1980]

Yeah, your explanation was spot on; I was indeed just counting incorrectly. Sorry for the slow reply!

[Gabri95]

Hi @drewm1980 ,

would it be possible to share the code you used to define your models? That would make it easier for me to understand the architecture.

Be careful that if you preserve the number of fields in each layer (e.g. you always write something like ft = FieldType(gs, [gs.regular_repr]*8) regardless of which group is used in gs), the cost of your conv layer will grow quadratically with the group size.
This is because the size of each feature will grow linearly with the group size, but the cost of convolution/linear layer grows quadratically with the feature sizes.

The fact you have ~8 times more params in the FlipRotOnR2(4) model, makes me think your features are actually ~8 times larger.
Is that correct?

In general, it's not usually necessary to scale the feature size linearly with the group size.
Sometimes, if your group is not too large, it is not even necessary to scale up the feature size at all, preserving the original computational cost.
To keep the number of channels more or less fixed, you can do something like this:

# "gs" is your gspace, e.g. FlipRotOnR2(4)

C = 64
c = int(C / gs.fibergroup.order())
ft = FieldType(gs, [gs.regular_repr]*c)

I would try to start with a model where you don't scale up the number of channels, and then gradually increase it if necessary to get better performance.

Let me know if this helps

Best,
Gabriele

[drewm1980]

Thanks for the response! I'll try to work up a minimized example I can share, but it might be week or two before I'm back on the relevant project. This may just be expected behavior; I'll try increasing the non-equivariant network's channels to match (x 8 everywhere), and re-compare the sizes. If they're comparable, then I just wasn't aware enough of the cost of scaling the equivariance group.