I’m working with the GAMS MOO Library for multi-objective optimization using the Augmented Epsilon Constraint method. I’m solving a nonlinear programming (NLP) model with CONOPT.
During the payoff table calculation, the model halts with the following error:
*** Error at line [LINE_NUMBER]: Execution halted: abort ‘No optimal/integer solution for mod_payoff’
However, just before this abort, CONOPT reports:
** Optimal solution. Reduced gradient less than tolerance.
Additionally, the output values of all three objective functions are zero, which strongly suggests that the solver has found a feasible and potentially optimal solution.
Looking into the MOO library code, I found the error is triggered by this condition:
if (%pre%_modelstat <> %modelStat.optimal% and
%pre%_modelstat <> %modelStat.integerSolution%,
abort ‘No optimal/integer solution for mod_payoff.’);
Has anyone else experienced this issue with CONOPT and the MOO library?
Could this abort be caused by something wrong in my model constraints or formulation?
Is there a better way to verify that my model is well-defined for each objective during the payoff phase?
I would greatly appreciate any help in diagnosing whether the problem is in the model or the library logic.
MOO does not accept locally optimal solutions at the moment which it should. This is a bug, thanks for pointing us to this issue. We will fix this with the upcoming GAMS 50 release. In the meantime, you can adapt the MOO library code yourself so it does not abort. You need to include the model status 2 (Locally Optimal) into the check as follows:
if(%pre%_modelstat <> %modelStat.optimal% and
%pre%_modelstat <> %modelStat.integerSolution% and
%pre%_modelstat <> %modelStat.locallyOptimal%,
[...]
You will need to adjust this for the payoff phase as well as the augmented epsilon constraint phase. Assuming you have a recent GAMS 49 version installed, this should be lines 375-376 and 759-760 in moo.gms (located at /path/to/GAMS/installation/directory/inclib).
After updating the moo.gms status check as you suggested, the original abort message was resolved. However, I encountered another issue during the Augmented Epsilon-Constraint phase.
Initially, the model reported:
** Infeasible solution. There are no superbasic variables.
No optimal or integer feasible solution found for current RHS. Skip all solves for more demanding values of RHS. [LST:1063]
To address this, I reviewed and adjusted my model constraints to improve feasibility. After making some changes, the model began returning feasible solutions again, but I now see a different message:
Feasible solution. Value of objective = -4235355104.11
Iter Phase Ninf Objective RGmax NSB Step InItr MX OK
6 4 6.4978971724E+14 5.0E+13 12 1.0E+00 5 T T
11 4 9.9939919430E+14 6.9E+14 1 2.2E-02 1 F F
16 4 9.9999638941E+14 6.9E+14 1 0.0E+00 1 F F
20 4 9.9999679359E+14 6.9E+14 1
** Feasible solution. The tolerances are minimal and
there is no change in objective although the reduced
gradient is greater than the tolerance.
Despite having a feasible solution, the run aborts with:
*** Error at line 684: Execution halted: abort ‘No optimal/integer solution for mod_payoff.’
It seems the current model status may still not meet the condition in the MOO library.
Additionally, the output values of all three objective functions are zero.
Any recommendations on how to correctly interpret this behavior or refine the model/status checks to prevent unnecessary aborts would be greatly appreciated.
As a follow-up, I noticed that the moo.gms file contains logic similar to:
$ifThenI.moo___modelType %modelType%==LP
$elseifI.moo___modelType %modelType%==RMIP else.moo___modelType
abort Model type %modelType% not allowed. Allowed model types: LP and RMIP.
$endif.moo___modelType
This block appears to explicitly restrict the model type to LP or RMIP. Since my problem is inherently a NLP model, I have set modelType = NLP in my $libInclude moo call. However, due to the above logic, the model aborts immediately, indicating that NLP is not supported in this version or configuration.
However, according to the foundational paper by G. Mavrotas, “Effective implementation of the ε-constraint method in Multi-Objective Mathematical Programming problems” (Applied Mathematics and Computation, 213 (2009), 455–465), the AUGMECON method is indeed applicable to LP, MIP, and NLP problem classes.
My questions are the following:
Is this restriction (to LP and RMIP only) a known limitation of this specific version of moo.gms?
Is there a different version of moo.gms or a recommended configuration that fully supports modelType = NLP for implementing the Augmented Epsilon-Constraint method?
Are there any recommended steps, alternative includes, or known workarounds for applying AUGMECON to NLP models using the GAMS library?
Any clarification or guidance on how to adapt or enable moo.gms for NLP applications would be greatly appreciated.
$ ifThenI.moo___modelType %modelType%==LP
$ elseifI.moo___modelType %modelType%==RMIP
$ else.moo___modelType
$ abort Model type %modelType% not allowed. Allowed model types: LP and RMIP.
$ endif.moo___modelType
are not affecting the EpsConstraint method but only Sandwiching. If you run moo with EpsConstraint you will not run into this block. The EpsConstraint method implemented in moo does support NLP.
That you get an infeasible solution at some point during EpsConstraint is not necessarily an issue but can be an expected outcome of some EpsConstraint iterations. For more than one objective in the constraints there might actually be combinations of grid points that are indeed infeasible.
That you get an abort with a “Feasible Solution” is because moo currently does not accept solutions that are only feasible (and not e.g. locally optimal). You can add %modelStat.feasibleSolution% to the checks (just like for %modelStat.locallyOptimal%) but I am not sure yet if we will add this permanently to moo - just a feasible solution might not be enough for moo to continue in all cases. I would be interested to see your model, so I might be able to reproduce some of the issues you are having. Would you be willing to share your model? If you do not want to upload it into the forum, you can also share it via e-mail with support@gams.com.