Thanks @odow for replying to me! Good to know that this was a bug and that I can use the start keyword.
However it seems to now error when calling optimize! with COSMO here’s what I ran:

MathOptInterface.UnsupportedAttribute{MathOptInterface.VariablePrimalStart}: Attribute MathOptInterface.VariablePrimalStart() is not supported by the model.

However this seems to be the result of using COSMO as it seems to work with SCS. I’m not sure if this is also a bug?

If a solver does not support HermitianPSDCone explicitly, then JuMP will reformulate it into an equivalent PositiveSemidefiniteConeTriangle constraint through a bridge.

When you set the starting value of E1 and E2, the bridge needs to convert those starting values into equivalent starting values for the reformulated variables inside the solver

Since starting values are an optional hint that can improve performance but not correctness, JuMP should silently ignore them if they are not supported by the solver.

COSMO and SCS supports starting values, but the Hermitan to PSD bridge does not, so JuMP should skip copying the starting values.

JuMP correctly skips the values for SCS (even though it doesn’t warn the user, this is a choice we made), but it errors for COSMO.

I don’t know why it errors, which is the bug.

So the conclusion is: don’t use starting values for now if you are using HermitianPSDCone

Thanks @odow and @blegat for all the fast fixes related to this issue, I’m really quite impressed how quickly this has been addressed!

I’ve been trying to follow along the linked github issues and PRs as best I can but I may not be understanding exactly what’s been fixed yet.

The example I’ve posted now works for me with the latest master versions of JuMP and MathOptInterface when using the start = keyword of @variable. I can even get set_start_value working when using real starting values like so: set_start_value.(real.(E2), real.(E_)). However I can’t seem to figure out how to use set_starting_value with a hermitian starting value that has imaginary components. For example

Cannot call set_start_value with 0 because it is not an affine expression of one variable.

Using the start= keyword instead works just fine for this example so I can just use that for now, but I assume for repeatedly solving same problem with different coefficients, it would be more efficient to update the start value of with set_start_value rather than having to remove then re-add the variable?

The issue is that the off-diagonal entries in E1 and E2 are actually the same variable. So there is a problem setting the imag(E2[2, 1]) element, which is actually -imag(E2[1, 2])

I didn’t test, but you could do something like this:

function set_hermitian_start(x, start)
for j in 1:size(x, 2), i in 1:size(x, 1)
set_start_value(real(x[i, j]), real(start[i, j]))
if i < j
set_start_value(imag(x[i, j]), imag(start[i, j]))
end
end
return
end
set_hermitian_start(E2, E_)

The other issue is that there is no imaginary variable associated to the diagonal entries, so imag returns 0 hence the error message saying that you cannot call set_start_value with `0 .