Opened 7 years ago
Closed 3 months ago
#51 closed defect (fixed)
Incorrect mipStatus for infeasible continuous problem
Reported by: | jonnyz007 | Owned by: | pbonami |
---|---|---|---|
Priority: | trivial | Component: | Bonmin |
Version: | 1.5 | Keywords: | |
Cc: |
Description
Hi,
Johan (from YALMIP) has been integrating BONMIN into his software via the OPTI toolbox, and noticed that when solving an infeasible continuous problem, BONMIN would mistakenly report the mipStatus to be 0 (FeasibleOptimal?). I have confirmed the issue and I have seen the same behaviour on a couple of my test problems. I realise these are continuous problems, but may be worth fixing?
Jonathan
Attachments (1)
Change History (13)
comment:1 Changed 7 years ago by pbonami
- Resolution set to fixed
- Status changed from new to closed
comment:2 Changed 6 years ago by jonnyz007
Hi Pierre,
The same problem appears to be present in v1.7, did the change not make it into the latest release? It was certainly fixed in 1.6.
Jonathan
comment:3 follow-up: ↓ 4 Changed 6 years ago by stefan
As far as I see, the change made it. I believe you refer to r2014 and I can see exactly this code in Bonmin/1.7: https://projects.coin-or.org/Bonmin/browser/stable/1.7/Bonmin/src/CbcBonmin/BonCbc.cpp#L600
comment:4 in reply to: ↑ 3 Changed 6 years ago by jonnyz007
Hi Stefan,
You are correct the code has made it across, but a problem still exists. Bonmin is returning "FeasibleOptimal?" when it fails solving an infeasible continuous problem with a failed initial point.
Try solving the problem min -x with 0 <= x <= Inf and x0 = 0 (no integer vars). I get:
Cbc3007W No integer variables - nothing to do
NLP0010I Ipopt return (for initialSolve): status -8, iter count 15, time 0.008 NLP0012I
Num Status Obj It time Location
NLP0014I 1 FAILED -1.2580052e+018 15 0.008
NLP0010I Ipopt return (for initialSolve): status -8, iter count 15, time 0.007
NLP0014I 2 FAILED -1.2580052e+018 15 0.007
Cbc3007W No integer variables - nothing to do
Cbc0006I The LP relaxation is infeasible or too expensive
But still returns FeasibleOptimal?...
Jonathan
Replying to stefan:
As far as I see, the change made it. I believe you refer to r2014 and I can see exactly this code in Bonmin/1.7: https://projects.coin-or.org/Bonmin/browser/stable/1.7/Bonmin/src/CbcBonmin/BonCbc.cpp#L600
comment:5 Changed 6 years ago by stefan
Hi,
the problem (min -x with 0 <= x <= Inf) is not infeasible, but unbounded.
When I run Bonmin on this (via the GAMS interface), it ends with
EXIT: Iterates diverging; problem might be unbounded. NLP0014I 2 UNBOUNDED -2.020204e+28 6 0.002 Cbc3007W No integer variables - nothing to do Cbc0034I The LP relaxation is unbounded!
and also Bonmin reports the problem to be unbounded (status TMINLP::CONTINUOUS_UNBOUNDED in TMINLP::finalize_solution).
Stefan
comment:6 Changed 6 years ago by jonnyz007
Hi Pierre,
Talking with Stefan via email he can also reproduce my problem in GAMS. I have attached a C++ example to this ticket which reproduces the problem, and wondered if you can take a look.
Regards,
Jonathan
comment:7 follow-up: ↓ 8 Changed 6 years ago by pbonami
Hi Jonathan, I can try.
In your example, I suppose it only fails if you use the limited_memory for the hessian approximation option of Ipopt (then Ipopt goes to iteration limit and status is not recognized). Is this correct? (i.e. when I disable the option everything seems fine to me).
Best, Pierre
comment:8 in reply to: ↑ 7 ; follow-up: ↓ 10 Changed 6 years ago by jonnyz007
Hi Pierre - that is correct, only with the limited memory hessian update does this problem occur. Jonathan
Replying to pbonami:
Hi Jonathan, I can try.
In your example, I suppose it only fails if you use the limited_memory for the hessian approximation option of Ipopt (then Ipopt goes to iteration limit and status is not recognized). Is this correct? (i.e. when I disable the option everything seems fine to me).
Best, Pierre
comment:9 Changed 6 years ago by stefan
- Resolution fixed deleted
- Status changed from closed to reopened
I tried to find out where the difference between Ipopt standalone and Ipopt in Bonmin comes. I think I'm running both with the same parameter settings (i.e., Ipopt with the parameter changes that Bonmin does on Ipopt) and print level 12.
The first time that there is a considerable difference is in the update of the barrier parameter. Note the Term 0 of KKT[0][0], one time it's 0, the other time it's 1.
In Ipopt, it says:
************************************************** *** Update Barrier Parameter for Iteration 0: ************************************************** Setting mu_max to 1.000000e+01. Staying in free mu mode. The current filter has 1 entries. phi theta iter 1 -9.9999999000000006e-03 0.0000000000000000e+00 0 Solving the Primal Dual System for the affine step Solving system with delta_x=0.000000e+00 delta_s=0.000000e+00 delta_c=0.000000e+00 delta_d=0.000000e+00 CompoundVector "RHS[ 0]" with 4 components: Component 1: DenseVector "RHS[ 0][ 0]" with 1 elements: RHS[ 0][ 0][ 1]=-1.0000000000000000e+00 Component 2: DenseVector "RHS[ 0][ 1]" with 0 elements: Component 3: DenseVector "RHS[ 0][ 2]" with 0 elements: Component 4: DenseVector "RHS[ 0][ 3]" with 0 elements: CompoundSymMatrix "KKT" with 4 rows and columns components: Component for row 0 and column 0: SumSymMatrix "KKT[0][0]" of dimension 1 with 2 terms: Term 0 with factor 1.0000000000000000e+00 and the following matrix: DiagMatrix "Term: 0" with 1 rows and columns, and with diagonal elements: DenseVector "Term: 0" with 1 elements: Term: 0[ 1]= 0.0000000000000000e+00 Term 1 with factor 1.0000000000000000e+00 and the following matrix: DiagMatrix "Term: 1" with 1 rows and columns, and with diagonal elements: DenseVector "Term: 1" with 1 elements: Term: 1[ 1]= 1.0000000000000000e+02 Component for row 1 and column 0: This component has not been set. Component for row 1 and column 1: DiagMatrix "KKT[1][1]" with 0 rows and columns, and with diagonal elements: DenseVector "KKT[1][1]" with 0 elements: Component for row 2 and column 0: GenTMatrix "KKT[2][0]" of dimension 0 by 1 with 0 nonzero elements: Component for row 2 and column 1: This component has not been set. Component for row 2 and column 2: DiagMatrix "KKT[2][2]" with 0 rows and columns, and with diagonal elements: DenseVector "KKT[2][2]" with 0 elements: Homogeneous vector, all elements have value -0.0000000000000000e+00 Component for row 3 and column 0: GenTMatrix "KKT[3][0]" of dimension 0 by 1 with 0 nonzero elements: Component for row 3 and column 1: IdentityMatrix "KKT[3][1]" with 0 rows and columns and the factor -1.0000000000000000e+00. Component for row 3 and column 2: This component has not been set. Component for row 3 and column 3: DiagMatrix "KKT[3][3]" with 0 rows and columns, and with diagonal elements: DenseVector "KKT[3][3]" with 0 elements: Homogeneous vector, all elements have value -0.0000000000000000e+00
In Bonmin, it says
************************************************** *** Update Barrier Parameter for Iteration 0: ************************************************** Setting mu_max to 1.000000e+01. Staying in free mu mode. The current filter has 1 entries. phi theta iter 1 -9.9999999000000006e-03 0.0000000000000000e+00 0 Solving the Primal Dual System for the affine step Solving system with delta_x=0.000000e+00 delta_s=0.000000e+00 delta_c=0.000000e+00 delta_d=0.000000e+00 CompoundVector "RHS[ 0]" with 4 components: Component 1: DenseVector "RHS[ 0][ 0]" with 1 elements: RHS[ 0][ 0][ 1]=-1.0000000000000000e+00 Component 2: DenseVector "RHS[ 0][ 1]" with 0 elements: Component 3: DenseVector "RHS[ 0][ 2]" with 0 elements: Component 4: DenseVector "RHS[ 0][ 3]" with 0 elements: CompoundSymMatrix "KKT" with 4 rows and columns components: Component for row 0 and column 0: SumSymMatrix "KKT[0][0]" of dimension 1 with 2 terms: Term 0 with factor 1.0000000000000000e+00 and the following matrix: DiagMatrix "Term: 0" with 1 rows and columns, and with diagonal elements: DenseVector "Term: 0" with 1 elements: Homogeneous vector, all elements have value 1.0000000000000000e+00 Term 1 with factor 1.0000000000000000e+00 and the following matrix: DiagMatrix "Term: 1" with 1 rows and columns, and with diagonal elements: DenseVector "Term: 1" with 1 elements: Term: 1[ 1]= 1.0000000000000000e+02 Component for row 1 and column 0: This component has not been set. Component for row 1 and column 1: DiagMatrix "KKT[1][1]" with 0 rows and columns, and with diagonal elements: DenseVector "KKT[1][1]" with 0 elements: Component for row 2 and column 0: GenTMatrix "KKT[2][0]" of dimension 0 by 1 with 0 nonzero elements: Component for row 2 and column 1: This component has not been set. Component for row 2 and column 2: DiagMatrix "KKT[2][2]" with 0 rows and columns, and with diagonal elements: DenseVector "KKT[2][2]" with 0 elements: Homogeneous vector, all elements have value -0.0000000000000000e+00 Component for row 3 and column 0: GenTMatrix "KKT[3][0]" of dimension 0 by 1 with 0 nonzero elements: Component for row 3 and column 1: IdentityMatrix "KKT[3][1]" with 0 rows and columns and the factor -1.0000000000000000e+00. Component for row 3 and column 2: This component has not been set. Component for row 3 and column 3: DiagMatrix "KKT[3][3]" with 0 rows and columns, and with diagonal elements: DenseVector "KKT[3][3]" with 0 elements: Homogeneous vector, all elements have value -0.0000000000000000e+00
Later, there is in Ipopt:
************************************************** *** Update HessianMatrix for Iteration 1: ************************************************** In limited-memory update, s_new_max is 0.000000e+00 Number of successive iterations with skipping: 1
but in Bonmin:
************************************************** *** Update HessianMatrix for Iteration 1: ************************************************** In limited-memory update, s_new_max is 9.900990e-03 Limited-Memory test for skipping: s^Ty = 0.000000e+00 snrm = 9.900990e-03 ynrm = 0.000000e+00 Skip the update. Number of successive iterations with skipping: 1
However, I don't know where these differences come from.
comment:10 in reply to: ↑ 8 ; follow-up: ↓ 11 Changed 6 years ago by pbonami
Hi Jonathan, I have modified the status codes for continuous problems so that your problem should get the right status (unsolved).
Let me know if you agree this is the correct status now (it is in trunk).
Best, Pierre
Replying to jonnyz007:
Hi Pierre - that is correct, only with the limited memory hessian update does this problem occur. Jonathan
Replying to pbonami:
Hi Jonathan, I can try.
In your example, I suppose it only fails if you use the limited_memory for the hessian approximation option of Ipopt (then Ipopt goes to iteration limit and status is not recognized). Is this correct? (i.e. when I disable the option everything seems fine to me).
Best, Pierre
comment:11 in reply to: ↑ 10 Changed 6 years ago by jonnyz007
All fixed from my end - thanks for sorting this! Also sorry for the delay, thesis writing is rather time consuming.
Replying to pbonami:
Hi Jonathan, I have modified the status codes for continuous problems so that your problem should get the right status (unsolved).
Let me know if you agree this is the correct status now (it is in trunk).
Best, Pierre
Replying to jonnyz007:
Hi Pierre - that is correct, only with the limited memory hessian update does this problem occur. Jonathan
Replying to pbonami:
Hi Jonathan, I can try.
In your example, I suppose it only fails if you use the limited_memory for the hessian approximation option of Ipopt (then Ipopt goes to iteration limit and status is not recognized). Is this correct? (i.e. when I disable the option everything seems fine to me).
Best, Pierre
comment:12 Changed 3 months ago by stefan
- Resolution set to fixed
- Status changed from reopened to closed
Hi,
Indeed this was incorrect. I hope it is fixed now (in trunk and stable 1.6). Best regards, Pierre