Mixed Complementarity problem with PATH returns solution that is infeasible

Problems with modeling
Post Reply
Posts: 1
Joined: 2 weeks ago

Mixed Complementarity problem with PATH returns solution that is infeasible

Post by ryanpent »

I am using PATH to solve a Mixed Complementarity Problem(MCP). After formulating the problem, GAMS returns a solution that violates one of the complementary slackness constraints in the model.

To be more specific, I am modeling two electric generators that are participating in a day ahead market with reserve as well as a real time market. There are four different linear optimization problems solved simultaneously as an MCP. The four LPs are generator 1 profit maximization, generator 2 profit maximization, DA economic dispatch, RT economic dispatch. The full formulation of the MCP is attached below as well its implementation in GAMS, however the details of the model are not very relevant. What is relevant is that when I solve this problem, the solution it returns violates the complementarity condition that appears in the GAMS problem as Eq6.g1_DA, and is the 1st constraint in the attached MCP formulation. The solution variables for Eq6 are 0<= 5 - 8 - 2 - 0 \perp 40 >= 0.
(89.89 KiB) Downloaded 10 times
Even with the condition violated, GAMS recognizes this solution as feasible and returns it.

I am unsure why this is happening, so any help with this problem would be of great help. Thank you in advance.

(89.89 KiB) Downloaded 10 times
(1.67 KiB) Downloaded 10 times
User avatar
Posts: 204
Joined: 6 years ago
Location: Fairfax, VA

Re: Mixed Complementarity problem with PATH returns solution that is infeasible

Post by dirkse »


The solution PATH is returning is a valid solution. With complementarity models, the type of inequality you use when defining the function (Equ6 in your case) does not play a role in defining the problem. It is essentially ignored.

Consider the matched pair f() perp-to L <= x <= U. In your case. f() = c_1 - lda - rho - d1 perp-to 0 <= x <= 40. When x is at the upper bound, the matched function f() is allowed to be negative, which it is in this case.

A couple items to note:
1. The definition of MCP includes a _function_ f(), not an inequality. To avoid losing sight of this important detail, I like to use the =N= when defining equations for MCP.
2. The listing file includes the REDEF marker to warn you about cases like this. Essentially, it warns you that the inequality you used to define the function in the MCP is not satisfied. Using =N= avoids this warning, because there is no inequality to satisfy.

I could write lots more on the subject to explain this all more clearly and more fully. In fact, I have: you can read it here:

https://gams.com/latest/docs/UG_ModelSo ... Models_MCP

Post Reply