The cone to be appended has one variable which is already member of another cone-MOSEK solver

[GrayLee]

Dear all,

I encountered a confusing problem. I programmed a mixed integer second order cone problem in GAMS and used MOSEK to solve it. The SOC constraint is the equation (24a) in the following figure. The literature including this equation is attached as well.

I knew that the SOC constraint should be in the standard format of SOC when I used the MOSEK solver. I then used auxiliary variables in the SOC constraint, and set the lower bound of all variables in the SOC constraint. However, the solver reminded me with:

Variable 'aux_BS(1)' (1729) is a member of cone '' (0). (*1307*)
*** mosekgms.c: 3258: MSK_GAMS_readtask: Error code MSK_RES_ERR_CONE_OVERLAP_APPEND (1307). The cone to be appended has one variable which is already member of another cone.

I am very confused that variable aux_BS(1) belongs to which cone except for the mentioned SOC constraint? How can I resolve this error?

My code and necessary excel files are attached. Thanks in advance for your kindly help!

Best regards,
Gray Lee

Chance Constrained Scheduling and Pricing for Multi-Service Battery Energy Storage.pdf

(1.86 MiB) Downloaded 98 times

DRCC.zip

(31.64 KiB) Downloaded 96 times

[bussieck]

Hi, I did not compare your GAMS model with the model in the PDF but showed how to overcome the issue with the disjoint cone requirement in MOSEK. Basically you have to create copies of the aux_BS(k) and make sure that the copies have the same value. I did this in the attached model. After my change, Mosek accepts the model, but declares it infeasible. This has little to do with the SOCP constraint. I took this constraint (and the helper constraint defaux_bs_t) out of the model and even that is inefasible (even as an RMIP). You find plenty of topics of how to deal with infeasible models in the forum. Good luck!

-Michael

DRCC.gms

(13.51 KiB) Downloaded 91 times

[GrayLee]

Hi, I did not compare your GAMS model with the model in the PDF but showed how to overcome the issue with the disjoint cone requirement in MOSEK. Basically you have to create copies of the aux_BS(k) and make sure that the copies have the same value. I did this in the attached model. After my change, Mosek accepts the model, but declares it infeasible. This has little to do with the SOCP constraint. I took this constraint (and the helper constraint defaux_bs_t) out of the model and even that is inefasible (even as an RMIP). You find plenty of topics of how to deal with infeasible models in the forum. Good luck!

-Michael

DRCC.gms

Dear Bussieck,

Many thanks for your reply and valuable suggestion! I find my problem is perfectly resolved in your updated code. I can handle the infeasibility by myself. Thanks!

Best regards,
Gray Lee