embotech/ecos

ECOS hangs and fails to solve a problem, while other solvers work

Closed this issue · 17 comments

I am experiencing a bug with ECOS where the solver just hangs as soon as it is called by CVX. This does not happen in the same situation with SeDuMi, for example.

The code that I have built around the particular piece of CVX code is quite substantial, and I do not feel comfortable distributing it on this side. How should I handle this bug? Is there still a way for me to report it and contribute to its solution?

Can you dump the solver input? Type "cvx_solver_settings" and look at the "dumpfile" option. This will give you the ability to dump the raw input to SeDuMi to a file. Even though SeDuMi hangs, it should at least dump the input to the file.

If that does not work, go into cvx_sedumi.m, set a breakpoint on the line with the "cvx_run_solver" call, and manually save the inputs to a file.

On Mar 12, 2014, at 8:18 AM, "Ingo Gerth" <notifications@github.commailto:notifications@github.com> wrote:

I am experiencing a bug with ECOS where the solver just hangs as soon as it is called by CVX. This does not happen in the same situation with SeDuMi, for example.

The code that I have built around the particular piece of CVX code is quite substantial, and I do not feel comfortable distributing it on this side. How should I handle this bug? Is there still a way for me to report it and contribute to its solution?


Reply to this email directly or view it on GitHubhttps://github.com//issues/38.

Okay, I have successfully solved the problem – that fails with ECOS – with SeDuMi and SDPT3.

You can download the SeDuMi 'dumpfile' here:* https://www.dropbox.com/s/l0nnxlxg9fclo2y/cvx_input_sedumi.mat
And the SDPT3 'dumpfile' here: https://www.dropbox.com/s/7a24eta6o45tw7l/cvx_input_sdpt3.mat

Hope this helps, please let me know if there is anything more I can do to help.

[*] NB: It could be that the SeDuMi dumpfile is incomplete because it might have crashed prematurely. The following error popped up in Matlab:

Error using cell2struct
Number of field names must match number of fields in new structure.

You weren't able to get a dumpfile for ECOS itself? I know it fails to solve but I thought I had designed the dumpfile facility to save before running, just in case. I could be wrong.
On Mar 12, 2014, at 9:45 AM, Ingo Gerth <notifications@github.commailto:notifications@github.com> wrote:

Okay, I have successfully solved – that fails with ECOS – with SeDuMi and SDPT3.

You can download the SeDuMi 'dumpfile' here:* https://www.dropbox.com/s/l0nnxlxg9fclo2y/cvx_input_sedumi.mat
And the SDPT3 'dumpfile' here: https://www.dropbox.com/s/7a24eta6o45tw7l/cvx_input_sdpt3.mat

Hope this helps, please let me know if there is anything more I can do to help.

  • NB: It could be that the SeDuMi dumpfile is incomplete because it might have crashed prematurely. The following error popped up in Matlab:

Error using cell2struct
Number of field names must match number of fields in new structure.


Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-37416407.

My bad. Here you go:
https://www.dropbox.com/s/fcq3syykv6vyyya/cvx_input_ecos.mat

ECOS starts hanging at this point:


Calling ECOS unknown: 3120 variables, 1569 equality constraints
------------------------------------------------------------
Saving output to: cvx_input.mat
------------------------------------------------------------

I've let Matlab run for quite a while but the solver won't finish. Ctrl+c fails to close the program.

Platform: Windows 7 x86

echu commented

Ill take a look too. It could be something we introduced on the solver side.

On Wednesday, March 12, 2014, Ingo Gerth notifications@github.com wrote:

My bad. Here you go:
https://www.dropbox.com/s/fcq3syykv6vyyya/cvx_input_ecos.mat

ECOS starts hanging at this point:

Calling ECOS unknown: 3120 variables, 1569 equality constraints

Saving output to: cvx_input.mat

I've let Matlab run for quite a while but the solver won't finish. Ctrl+c
fails to close the program.

Platform: Windows 7 x86

Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-37419052
.

I'm actually not working on this at all, so thanks... if it does look like a CVX issue let me know, but the fact that it gets into the shim suggests otherwise.

On Mar 12, 2014, at 11:06 AM, Eric Chu <notifications@github.commailto:notifications@github.com> wrote:

Ill take a look too. It could be something we introduced on the solver side.

On Wednesday, March 12, 2014, Ingo Gerth <notifications@github.commailto:notifications@github.com> wrote:

My bad. Here you go:
https://www.dropbox.com/s/fcq3syykv6vyyya/cvx_input_ecos.mat

ECOS starts hanging at this point:

Calling ECOS unknown: 3120 variables, 1569 equality constraints

Saving output to: cvx_input.mat

I've let Matlab run for quite a while but the solver won't finish. Ctrl+c
fails to close the program.

Platform: Windows 7 x86

Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-37419052
.


Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-37427092.

My suspicion is that it's a huge problem and ECOS does not converge. To see the prints while ECOS is solving, activate

#define MATLAB_FLUSH_PRINTS

in include/glblopts.h

This makes sure MATLAB flushes the printf buffer correctly, but makes the solver slower for small/medium problems. This way we can see whether the solver is iterating at all.

On Mar 12, 2014, at 9:06 AM, Eric Chu notifications@github.com wrote:

Ill take a look too. It could be something we introduced on the solver side.

On Wednesday, March 12, 2014, Ingo Gerth notifications@github.com wrote:

My bad. Here you go:
https://www.dropbox.com/s/fcq3syykv6vyyya/cvx_input_ecos.mat

ECOS starts hanging at this point:

Calling ECOS unknown: 3120 variables, 1569 equality constraints

Saving output to: cvx_input.mat

I've let Matlab run for quite a while but the solver won't finish. Ctrl+c
fails to close the program.

Platform: Windows 7 x86

Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-37419052
.


Reply to this email directly or view it on GitHub.

I would recommend making this the default. If someone wants speed, they should just shut the output off altogether.

On Mar 12, 2014, at 11:17 AM, Alexander Domahidi <notifications@github.commailto:notifications@github.com> wrote:

My suspicion is that it's a huge problem and ECOS does not converge. To see the prints while ECOS is solving, activate

#define MATLAB_FLUSH_PRINTS

in include/glblopts.h

This makes sure MATLAB flushes the printf buffer correctly, but makes the solver slower for small/medium problems. This way we can see whether the solver is iterating at all.

On Mar 12, 2014, at 9:06 AM, Eric Chu <notifications@github.commailto:notifications@github.com> wrote:

Ill take a look too. It could be something we introduced on the solver side.

On Wednesday, March 12, 2014, Ingo Gerth <notifications@github.commailto:notifications@github.com> wrote:

My bad. Here you go:
https://www.dropbox.com/s/fcq3syykv6vyyya/cvx_input_ecos.mat

ECOS starts hanging at this point:

Calling ECOS unknown: 3120 variables, 1569 equality constraints

Saving output to: cvx_input.mat

I've let Matlab run for quite a while but the solver won't finish. Ctrl+c
fails to close the program.

Platform: Windows 7 x86

Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-37419052
.


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-37428530.

@adomahidi, I am not sure whether this is really the case.

To give a small background on this:
I am solving a finite-time optimal control problem, that is discretized with a certain time step dt and a number of nodes N. This problem occurs for a particular combination of dt and N. However, I am able to solve instances of the problem that are larger, i.e., have large N than the problem that fails.

Thus I doubt that the size is the main problem here—but that's just a layman's guess.

echu commented

i have a hunch it might be the equilibration routine we introduced several
days ago. i'll double-check when i get home (i don't have access to a
matlab machine at work).

On Wed, Mar 12, 2014 at 9:21 AM, Ingo Gerth notifications@github.comwrote:

@adomahidi https://github.com/adomahidi, I am not sure whether this is
really the case.

To give a small background on this:
I am solving a finite-time optimal control problem, that is discretized
with a certain time step dt and a number of nodes N. This problem occurs
for a particular combination of dt and N. However, I am able to solve
instances of the problem that are larger, i.e., have large N than the
problem that fails.

Thus I doubt that the size is the main problem here--but that's just a
layman's guess.

Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-37429136
.

echu commented

hi ingo,

i downloaded the cvx_input_ecos.mat file from you and ran

load cvx_input_ecos
ecos(ecos_c, ecos_G, ecos_h, K, ecos_A, ecos_b, opts)

this ran into numerical errors, but at least it ran:

ECOS 1.0.2 - (c) A. Domahidi, Automatic Control Laboratory, ETH Zurich,
2012-2014.

It pcost dcost gap pres dres k/t mu
step IR
0 -7.183e+01 -6.057e+03 +1e+05 9e+00 3e+00 1e+00 8e+01 N/A
1 1 -
1 -2.273e+02 -1.260e+03 +3e+04 1e+00 5e-01 1e+01 2e+01
0.9790 1 2 2
2 -1.359e+02 -3.893e+02 +1e+04 4e-01 1e-01 2e+00 7e+00
0.6395 1 2 2
3 -1.763e+02 -3.428e+02 +1e+04 2e-01 9e-02 2e+00 5e+00
0.4150 1 1 1
4 -1.960e+02 -2.425e+02 +4e+03 7e-02 2e-02 4e-01 2e+00
0.6914 1 1 1
5 -2.097e+02 -2.133e+02 +4e+02 5e-03 2e-03 2e-02 2e-01
0.9099 1 1 1
6 -2.110e+02 -2.112e+02 +3e+01 3e-04 1e-04 6e-04 2e-02
0.9213 1 2 2
7 -2.112e+02 -2.112e+02 +1e+00 1e-05 4e-06 2e-05 5e-04
0.9676 2 2 2
8 -2.112e+02 -2.112e+02 +2e-02 2e-07 9e-08 4e-07 1e-05
0.9790 2 2 2
9 -2.112e+02 -2.112e+02 +5e-04 5e-09 2e-09 8e-09 3e-07
0.9790 3 3 3
10 nan nan nan nan nan nan nan 0.9790 0 0 0
11 nan nan nan nan nan nan nan 0.9790 0 0 0
12 nan nan nan nan nan nan nan 0.9790 0 0 0
13 nan nan nan nan nan nan nan 0.9790 0 0 0
14 nan nan nan nan nan nan nan 0.9790 0 0 0
15 nan nan nan nan nan nan nan 0.9790 0 0 0
16 nan nan nan nan nan nan nan 0.9790 0 0 0
17 nan nan nan nan nan nan nan 0.9790 0 0 0
18 nan nan nan nan nan nan nan 0.9790 0 0 0
19 nan nan nan nan nan nan nan 0.9790 0 0 0
20 nan nan nan nan nan nan nan 0.9790 0 0 0
21 nan nan nan nan nan nan nan 0.9790 0 0 0
22 nan nan nan nan nan nan nan 0.9790 0 0 0
23 nan nan nan nan nan nan nan 0.9790 0 0 0
24 nan nan nan nan nan nan nan 0.9790 0 0 0
25 nan nan nan nan nan nan nan 0.9790 0 0 0
26 nan nan nan nan nan nan nan 0.9790 0 0 0
27 nan nan nan nan nan nan nan 0.9790 0 0 0
28 nan nan nan nan nan nan nan 0.9790 0 0 0
29 nan nan nan nan nan nan nan 0.9790 0 0 0
30 nan nan nan nan nan nan nan 0.9790 0 0 0
31 nan nan nan nan nan nan nan 0.9790 0 0 0
32 nan nan nan nan nan nan nan 0.9790 0 0 0
33 nan nan nan nan nan nan nan 0.9790 0 0 0
34 nan nan nan nan nan nan nan 0.9790 0 0 0
35 nan nan nan nan nan nan nan 0.9790 0 0 0
36 nan nan nan nan nan nan nan 0.9790 0 0 0
37 nan nan nan nan nan nan nan 0.9790 0 0 0
38 nan nan nan nan nan nan nan 0.9790 0 0 0
39 nan nan nan nan nan nan nan 0.9790 0 0 0
40 nan nan nan nan nan nan nan 0.9790 0 0 0
41 nan nan nan nan nan nan nan 0.9790 0 0 0
42 nan nan nan nan nan nan nan 0.9790 0 0 0
43 nan nan nan nan nan nan nan 0.9790 0 0 0
44 nan nan nan nan nan nan nan 0.9790 0 0 0
45 nan nan nan nan nan nan nan 0.9790 0 0 0
46 nan nan nan nan nan nan nan 0.9790 0 0 0
47 nan nan nan nan nan nan nan 0.9790 0 0 0
48 nan nan nan nan nan nan nan 0.9790 0 0 0
49 nan nan nan nan nan nan nan 0.9790 0 0 0
50 nan nan nan nan nan nan nan 0.9790 0 0 0

Maximum number of iterations reached, exiting.
Runtime: 1.498336 seconds.

i'm not sure what's going on (why it hangs before calling the solver). i
did notice that ecos_G is a 3120 x 1569 matrix, so it has 3120 constraints
and 1569 variables. however, cvx reports that it's solving a problem with
1569 equations and 3120 variables.

also, do a git pull in your ECOS directory just to make sure there isn't
some old change lying around. i'm using the latest ECOS code.

can you try the same? navigate to

/matlab

load the dumpfile and call ecos directly. tell me if that does (or doesn't
work).

eric

On Wed, Mar 12, 2014 at 10:01 AM, Eric Chu eytchu@gmail.com wrote:

i have a hunch it might be the equilibration routine we introduced several
days ago. i'll double-check when i get home (i don't have access to a
matlab machine at work).

On Wed, Mar 12, 2014 at 9:21 AM, Ingo Gerth notifications@github.comwrote:

@adomahidi https://github.com/adomahidi, I am not sure whether this is
really the case.

To give a small background on this:
I am solving a finite-time optimal control problem, that is discretized
with a certain time step dt and a number of nodes N. This problem occurs
for a particular combination of dt and N. However, I am able to solve
instances of the problem that are larger, i.e., have large N than the
problem that fails.

Thus I doubt that the size is the main problem here--but that's just a
layman's guess.

Reply to this email directly or view it on GitHubhttps://github.com//issues/38#issuecomment-37429136
.

Hi Eric,

tested it, ECOS ran this time after it hung for a considerable amount of time. Here is its output:

ECOS 1.0.2 - (c) A. Domahidi, Automatic Control Laboratory, ETH Zurich, 2012-2014.

It     pcost       dcost      gap   pres   dres    k/t    mu     step    IR
 0  -7.183e+01  -6.057e+03  +1e+05  9e+00  3e+00  1e+00  8e+01   N/A    1 1 -
 1  -2.273e+02  -1.260e+03  +3e+04  1e+00  5e-01  1e+01  2e+01  0.9790  1 2 2
 2  -1.359e+02  -3.893e+02  +1e+04  4e-01  1e-01  2e+00  7e+00  0.6395  1 2 2
 3  -1.763e+02  -3.428e+02  +1e+04  2e-01  9e-02  2e+00  5e+00  0.4150  1 1 1
 4  -1.960e+02  -2.425e+02  +4e+03  7e-02  2e-02  4e-01  2e+00  0.6914  1 1 1
 5  -2.097e+02  -2.133e+02  +4e+02  5e-03  2e-03  2e-02  2e-01  0.9099  1 1 1
 6  -2.110e+02  -2.112e+02  +3e+01  3e-04  1e-04  6e-04  2e-02  0.9213  1 2 2
 7  -2.112e+02  -2.112e+02  +1e+00  1e-05  4e-06  2e-05  5e-04  0.9676  2 2 2
 8  -2.112e+02  -2.112e+02  +2e-02  2e-07  9e-08  4e-07  1e-05  0.9790  2 2 2
 9  -2.112e+02  -2.112e+02  +5e-04  5e-09  2e-09  8e-09  3e-07  0.9790  3 3 3
10  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
11  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
12  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
13  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
14  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
15  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
16  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
17  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
18  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
19  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
20  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
21  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
22  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
23  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
24  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
25  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
26  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
27  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
28  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
29  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
30  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
31  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
32  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
33  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
34  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
35  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
36  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
37  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
38  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
39  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
40  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
41  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
42  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
43  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
44  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
45  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
46  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
47  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
48  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
49  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0
50  +1.#QOe+00  -1.#IOe+00  +1e+00  1e+00  1e+00  1e+00  1e+00  0.9790  0 0 0

Maximum number of iterations reached, exiting.
Runtime: 260.430508 seconds.

SeDuMi also runs into numerical issues, but solves the problem and does so much faster:


Calling SeDuMi 1.34: 3120 variables, 1569 equality constraints
------------------------------------------------------------
SeDuMi 1.34 (beta) by AdvOL, 2005-2008 and Jos F. Sturm, 1998-2003.
Alg = 2: xz-corrector, Adaptive Step-Differentiation, theta = 0.250, beta = 0.500
eqs m = 1569, order n = 2341, dim = 3121, blocks = 521
nnz(A) = 3968 + 135656, nnz(ADA) = 8175, nnz(L) = 5050
Handling 248 + 0 dense columns.
 it :     b*y       gap    delta  rate   t/tP*  t/tD*   feas cg cg  prec
  0 :            6.27E+04 0.000
  1 :  -2.92E+02 4.39E+03 0.000 0.0700 0.9900 0.9900   6.18  1  1  3.9E-01
  2 :  -2.98E+02 9.56E+01 0.000 0.0218 0.9900 0.9900   1.06  1  1  3.6E-01
  3 :  -7.21E+01 4.13E+01 0.000 0.4317 0.9000 0.9000   2.00  1  1  3.3E-01
  4 :   2.04E+01 2.62E+01 0.000 0.6352 0.9000 0.9000   0.54  1  1  1.7E-01
  5 :   1.26E+02 1.29E+01 0.000 0.4936 0.9000 0.9000   1.15  1  1  4.9E-02
  6 :   1.95E+02 2.79E+00 0.000 0.2153 0.9000 0.9000   1.42  1  1  6.3E-03
  7 :   2.10E+02 1.73E-01 0.000 0.0620 0.9900 0.9900   1.32  1  1  2.8E-04
  8 :   2.11E+02 5.58E-03 0.000 0.0323 0.9900 0.9900   1.23  1  1  7.2E-06
  9 :   2.11E+02 1.12E-05 0.000 0.0020 0.9990 0.9990   1.02  2  3  1.4E-08
 10 :   2.11E+02 5.47E-21 0.000 0.0000 1.0000 1.0000   1.00  5  6  2.6E-15
Run into numerical problems.

iter seconds digits       c*x               b*y
 10      4.8  11.8  2.1123700000e+02  2.1123700000e+02
|Ax-b| =   2.6e-10, [Ay-c]_+ =   3.4E-20, |x|=  2.1e+04, |y|=  8.1e+00

Detailed timing (sec)
   Pre          IPM          Post
1.720E-01    2.902E+00    4.600E-02    
Max-norms: ||b||=1.273040e+04, ||c|| = 5.000000e-01,
Cholesky |add|=2, |skip| = 1, ||L.L|| = 64.875.
------------------------------------------------------------
Status: Solved
Optimal value (cvx_optval): +211.237

Code should be up-to-date.

@tehingo It seems that a division is not SAFEDIVed somewhere… will investigate on Monday latest. Out of curiosity, do you need SOCP constraints for your MPC problem?

My remark from yesterday that it's a large problem was relating only to the fact that it takes a while until you see the printouts. @mcg1969 is right, we should make MATLAB console printf flushing default at cost of speed.

echu commented

@adomahidi, is this reason to cause ECOS to stall a bit at first?

@adomahidi yes indeed, the problem is posed with several SOCP constraints. Let me know if you want more info on it.

@tehingo The most recent commit should fix this issue. Can you try again?

Problem is fixed indeed. I couldn't thank you more!