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.