The model I currently use is feasible with conopt3 but not conopt4 “An equation in the pre-triangular part of the model cannot be solved because there are no non-fixed variables left”.
Basically, the concentration of several GHG (let call them HFCxx) depend on the concentration of OH, on the emission level of the timestep, and on past year concentration. We deduce from the HFCxx concentration a radiative forcing RAD, they are linearly related (equation RADHALQ … RAD(T,HFCxx) =e= RHO(HFCxx)*CON(T,HFCxx), RHO beiing a parameter). the emission levels are externally prescribed, as well as initial concentration.
I identified the equation that causes this problem, thanks to the solution reporting : the RADHALQ equation fixes two variables at once, and I do not know why, as both variables are far from their bound.
Variable CON(2002,HFC245ca) is forced to its current value = 0.47563
Variable RAD(2002,HFC245ca) is forced to its current value = 0.0109395
Equation RADHALQ(2002,HFC245ca) acting as binding =G= has forced the above variables
Did someone ever encountered this problem with conopt4?
I have not seen this behavior in recent versions of Conopt4. It could be a scaling issue but without more details it’s hard to say. You might want to send the point/solution found by Conopt3 through Examiner (https://www.gams.com/latest/docs/S_EXAMINER.html) and check externally the feasiblity/optimality of the point/solution. If that is indeed a good solution, you might want to restart Conopt4 from that point and see how it acts. The message about infeasiblity indicates that the infeasiblity is found point independent, but it’s worth a try. If you feel that Conopt4 behaves incorrectly, you might want to send the model with data to support@gams.com (so they can reproduce the issue), they will check and if required forward this to the Conopt developer.
I used examiner and the solution found by conopt3 is feasible. What could be the role of scaling in this case ? I sent the model with data to support@gams.com
We heard already back from the Conopt developer. He acknowledges this as a true bug (which is already fixed in his development version). We will get this version next week and make it part of the next (minor/maintenance) release of GAMS 37. In the meantime, you can turn off the buggy part of the code by providing the option “Dointv = false” in a conopt4.opt option file.
Best,
Michael
PS Perhaps you can conclude the thread in gamsworld with these findings.