Closed kibaekkim closed 6 years ago
Currently, this is how it's done:
@complements(m, 0 <= F, x >= 0, simple)
will add the following macros
@NLconstraint(m, F*x <= mpec_tol)
@NLconstraint(m, x >= 0)
@NLconstraint(m, F >= 0)
mpec_tol
is a small positive constant. Should we have either of the following two instead?
@NLconstraint(m, F*x == 0)
@NLconstraint(m, F*x <= 0)
I am sorry that I must have misunderstood then. I thought
@NLconstraint(m, F*x == 0)
@NLconstraint(m, x >= 0)
@NLconstraint(m, F >= 0)
will be added, because of the example described in https://github.com/chkwon/Complementarity.jl#mathematical-programs-with-equilibrium-constraints-mpec
Thank you for the quick response!
I understand. No problem! Thanks for your attention!
I have one observation and suggestion for the complementarity condition. There are numerical evidences such that inequality complementarity condition works better than the equality, particularly when solving MPEC as an NLP (e.g., please see Section 2.1 in http://www3.eng.cam.ac.uk/~dr241/Papers/Fletcher-Leyffer-Ralph-Scholtes.pdf). But, I don't know whether the inequality always outperforms or not; for example, when using pivoting-type algorithms. I wonder if this package can have option for switching the signs of the complementarity condition, between == and <=.