Hello all,

I am trying to implement rotational symmetry for an SOS problem. In particular, I followed the example problem here: Dihedral symmetry of the Robinson form · SumOfSquares.

My goal is to use a cyclic group instead for a simple rotation symmetry, I don’t need to implement the rotation piece, and this resulted in the following code.

```
using DynamicPolynomials
using SumOfSquares
using Mosek
using MosekTools
using PermutationGroups
using GroupsCore
using SymbolicWedderburn
include("/Users/elizabethc/Documents/Code/JULIA_SOS_Couette/CyclicGroup.jl")
struct CyclicAction <: Symmetry.OnMonomials end
SymbolicWedderburn.coeff_type(::CyclicAction) = Float64
@polyvar a[1:6]
poly3 = sum(a.^2)
function SymbolicWedderburn.action(::CyclicAction, el::CyclicGroupElement, mono::AbstractMonomial)
var_a3, var_a4 = a[4], a[3]; var_a5, var_a6 = a[6], a[5]
sign_aodd = 1 <= el.residual <=2 ? -1 : 1
sign_aeven = 2 <= el.residual ? -1 : 1
return mono([a[1], a[2], a[3], a[4], a[5], a[6]] => [a[1], a[2], sign_aodd*var_a3, sign_aeven*var_a4, sign_aodd*var_a5, sign_aeven*var_a6])
end
G = CyclicGroup(4)
pattern3 = Symmetry.Pattern(G, CyclicAction())
model3 = SOSModel(Mosek.Optimizer)
@variable(model3, α3)
con_ref3 = @constraint(model3, poly3 >= α3, symmetry = pattern3)
optimize!(model3)
@show termination_status(model3)
@show objective_value(model3)
```

This yields an infeasible result using the optimization toolbox Mosek, and an empty constraint result using the optimization toolbox CSDP, which makes no sense since polynomial `poly`

is sum-of-squares by definition But, if I check that the symmetry is being correctly implemented using the following for loop

```
for g in G
@show SymbolicWedderburn.action(CyclicAction(), g, poly)
end
```

it shows that the polynomial is invariant under the claimed rotation, as it should be. We can check the proper symmetry is being imposed with `lin = sum(a)`

.

To see if I understood some structure incorrectly, I went back to the dihedral Robinson from example from the JuMP/SumOfSquares documentation, and thought to implement the exact same method, but instead of the polynomial being the Robsinson form p(x,y), I generalized it so that we have the new polynomial P(x_1, x_2,y_1,y_2) = p(x_1,y_1) + p(x_2,y_2). The Wedderburn action should be the same but now adjusted to make sure that the rotations and reflections are happening to (x_i,y_i), a very easy adjustment, and easily checked again by the for loop. If I then attempt to run the optimization model, I receive the following error, with a corresponding stacktrace:

` ERROR: No permutation can make [[0.0 1.0; -1.0 0.0], [0.0 -1.0; -1.0 0.0]] and [[0.0 1.0; -1.0 0.0], [0.0 1.0; 1.0 0.0]] match`

If I change the polynomial to a sum-of-squares, it declares feasibility and then gives me an optimal value t=-7.740740..., which is completely incorrect it should be 0. I can’t make heads nor tails of these errors, and the only person I know in my group who has experience with this is hypothesizing that it is actually a symmetry package compatibility issue with SOS. Any insight on what the issue might be would be greatly appreciated.