Hi @blegat ,
I have updated JuMP, SumOfSquares, Mosek, and MosekTools, and re-ran the code (after restarting Julia of course), and unfortunately the issue persists. And yes, I have double checked my group structures and generators, they are good, and match up with automatically generated invariant polynomials. The symmetry enforcement works for case where I have no SOS inequality constraints. But, darn, it appears I didn’t state something very important as clearly as I should have. The problem’s feasibility is dependent on a parameter, R. This parameter R tunes the coefficient values for the f in dVdt = f.*differentiate(V,a) + (bounds). For the full system (or even the system with sign symmetries implemented), there is a critical R for which Mosek claims there is a feasible polynomial. If we enforce the stronger symmetry for this R value, Mosek claims the problem is infeasible (while sometimes giving errors that there are nearly zero elements in sparse matrices handed to Mosek), which we know is not true because it is feasible without that symmetry enforcement. If I choose R significantly below the critical R value, feasibility holds. As I said in my original post,
My best intuition is there is some way in which JuMP is formulating the problem to hand to Mosek that causes Mosek to behave much worse numerically than it should. Supporting this intuition, I will sometimes get warnings from Mosek that the matrix ‘A’ is sparse (I meant to say here, that it has near-zero entries in sparse matrices). Indeed, this error also sometimes occurs when I enforce the restriction sparsity=SignSymmetry(), but it does not strongly hamper the feasibility results like my handwritten symmetry.
This near-zero matrix error that JuMP sends me occurs for the enforcement of sign symmetry, but this is not the case for YALMIP’s sign symmetry enforcement in Matlab. I’m not sure why using a different basis for the gram matrices would cause this much grief with how the problem is being sent to Mosek.
I had not responded yet because I have been spending a long time (amidst moving to a new job and international travel) trying to construct a sufficiently minimal case (because I don’t want to post all ~400 lines of code here, that’s egregious), but in the most accessible minimal example I have, the symmetry works for the critical R value. So thank you for reaching out, the last thing I was going to finish doing before reposting was to figure out how the symmetry enforcement + bridges changes the problem sent to Mosek. We have decided to email you the smallest and clearest possible minimal example to illustrate what is happening, as it is too large to post here (over 400 lines). The minimal example we are sending does not have this issue of near-zero matrix entries, but we can send you the script for that version as well if necessary. We will send more details in the email.