# Does this output look like SCIP has fallen into an infinite loop?

**URL:** <https://discourse.julialang.org/t/does-this-output-look-like-scip-has-fallen-into-an-infinite-loop/107061>\
**Category:** Optimization (Mathematical)\
**Created:** [December 2, 2023, 10:01pm UTC](https://discourse.julialang.org/t/does-this-output-look-like-scip-has-fallen-into-an-infinite-loop/107061 "2023-12-02T22:01:39Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [December 2, 2023, 10:01pm UTC](https://discourse.julialang.org/t/does-this-output-look-like-scip-has-fallen-into-an-infinite-loop/107061/1 "2023-12-02T22:01:39Z")

</div>

I’m using SCIP.jl, and the SCIP solver seems like it maybe enters an infinite loop, judging by the output it’s producing:

```julia
  897s|591200 |476649 |685013 | 1.2 | 3574M | 241 |1212 | 651 | 390 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
 time | node | left |LP iter|LP it/n|mem/heur|mdpt |vars |cons |rows |cuts |sepa|confs|strbr| dualbound | primalbound | gap | compl. 
  897s|591300 |476725 |685181 | 1.2 | 3576M | 241 |1212 | 651 | 395 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  897s|591400 |476805 |685246 | 1.2 | 3577M | 241 |1212 | 651 | 437 | 213k| 2 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  897s|591500 |476897 |685374 | 1.2 | 3578M | 241 |1212 | 651 | 403 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  898s|591600 |476977 |685434 | 1.2 | 3578M | 241 |1212 | 651 | 397 | 213k| 2 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  898s|591700 |477055 |685516 | 1.2 | 3579M | 241 |1212 | 651 | 389 | 213k| 2 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  898s|591800 |477139 |685592 | 1.2 | 3580M | 241 |1212 | 651 | 416 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  898s|591900 |477227 |685646 | 1.2 | 3580M | 241 |1212 | 651 | 406 | 213k| 2 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  898s|592000 |477301 |685756 | 1.2 | 3581M | 241 |1212 | 651 | 389 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  898s|592100 |477381 |685828 | 1.2 | 3581M | 241 |1212 | 651 | 389 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  898s|592200 |477465 |685885 | 1.2 | 3581M | 241 |1212 | 651 | 400 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  899s|592300 |477545 |685960 | 1.2 | 3582M | 241 |1212 | 651 | 407 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  899s|592400 |477621 |686102 | 1.2 | 3583M | 241 |1212 | 651 | 400 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  899s|592500 |477701 |686147 | 1.2 | 3583M | 241 |1212 | 651 | 393 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  899s|592600 |477779 |686195 | 1.2 | 3584M | 241 |1212 | 651 | 397 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  899s|592700 |477863 |686266 | 1.2 | 3584M | 241 |1212 | 651 | 417 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
 time | node | left |LP iter|LP it/n|mem/heur|mdpt |vars |cons |rows |cuts |sepa|confs|strbr| dualbound | primalbound | gap | compl. 
  899s|592800 |477935 |686323 | 1.2 | 3584M | 241 |1212 | 651 | 388 | 213k| 2 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  899s|592900 |478015 |686370 | 1.2 | 3586M | 241 |1212 | 651 | 391 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  900s|593000 |478101 |686411 | 1.2 | 3586M | 241 |1212 | 651 | 388 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  900s|593100 |478185 |686482 | 1.2 | 3587M | 241 |1212 | 651 | 409 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  900s|593200 |478263 |686585 | 1.2 | 3587M | 241 |1212 | 651 | 410 | 213k| 2 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  900s|593300 |478353 |686637 | 1.2 | 3587M | 241 |1212 | 651 | 415 | 213k| 2 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  900s|593400 |478433 |686703 | 1.2 | 3588M | 241 |1212 | 651 | 412 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  900s|593500 |478511 |686774 | 1.2 | 3589M | 241 |1212 | 651 | 0 | 213k| 0 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  901s|593600 |478591 |686824 | 1.2 | 3590M | 241 |1212 | 651 | 0 | 213k| 0 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  901s|593700 |478667 |686884 | 1.2 | 3590M | 241 |1212 | 651 | 399 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%
  901s|593800 |478739 |686932 | 1.2 | 3591M | 241 |1212 | 651 | 397 | 213k| 1 | 1 | 21 | 0.000000e+00 | -- | Inf | 18.26%

```

Several of these lines appear per second, with memory usage growing slowly, but the `compl.` column is constant. Anyone seen this before?

If necessary I’ll try providing a reproducer later.

---

<div class="post-metadata">

**Author:** ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)\
**Post date:** [December 2, 2023, 11:21pm UTC](https://discourse.julialang.org/t/does-this-output-look-like-scip-has-fallen-into-an-infinite-loop/107061/2 "2023-12-02T23:21:13Z")

</div>

No, it looks like it is trying to solve a hard problem.

I assume that its [Recommendations for solver and options to solve a MIQP, just looking for a feasible solution - #2 by odow](https://discourse.julialang.org/t/recommendations-for-solver-and-options-to-solve-a-miqp-just-looking-for-a-feasible-solution/107024/2)

So youre probably going to need some modeling improvements to be able to solve this (if at all). Its hard to say what without a reproducible example.