Feasible with conopt3 but not conop4

Solver related questions
Post Reply
yanngaucher
User
User
Posts: 3
Joined: 1 week ago

Feasible with conopt3 but not conop4

Post by yanngaucher » 6 days ago

Dear all,

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?

Thanks,

Yann

User avatar
bussieck
Moderator
Moderator
Posts: 663
Joined: 5 years ago

Re: Feasible with conopt3 but not conop4

Post by bussieck » 6 days ago

Yann,

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.

Good luck.
-Michael

yanngaucher
User
User
Posts: 3
Joined: 1 week ago

Re: Feasible with conopt3 but not conop4

Post by yanngaucher » 6 days ago

bussieck wrote:
6 days ago
Yann,

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.

Good luck.
-Michael
Thank you Michael.

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

yanngaucher
User
User
Posts: 3
Joined: 1 week ago

Re: Feasible with conopt3 but not conop4

Post by yanngaucher » 5 days ago

Yann,

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.

Post Reply