COIN-OR::LEMON - Graph Library

Opened 15 years ago

Closed 15 years ago

#255 closed defect (fixed)

Glpk basis must be updated manually

Reported by: Balazs Dezso Owned by: Alpar Juttner
Priority: major Milestone: LEMON 1.1 release
Component: core Version: hg main
Keywords: Cc:
Revision id:

Description

The basis must be computed before calling glp_simplex(). The [fc9e366e6759] contains a solution, which computes a new basis whenever it is necessary.

Attachments (2)

fc9e366e6759.patch (3.4 KB) - added by Balazs Dezso 15 years ago.
21148f69b6c7.patch (1.3 KB) - added by Balazs Dezso 15 years ago.
Silent glp_adv_basis()

Download all attachments as: .zip

Change History (12)

Changed 15 years ago by Balazs Dezso

Attachment: fc9e366e6759.patch added

comment:1 in reply to:  description Changed 15 years ago by Alpar Juttner

Replying to deba:

The basis must be computed before calling glp_simplex(). The [fc9e366e6759] contains a solution, which computes a new basis whenever it is necessary.

Could you give some more details please. Is it a bugfix? Or an improvement?

comment:2 Changed 15 years ago by Alpar Juttner

Status: newassigned

comment:3 Changed 15 years ago by Balazs Dezso

It is a bug fix, but it fixes a problem, which could be raised only if we remove basic columns or rows (the slack variable belongs the row is basic) from the LP.

The "Crashing" message came from GLPK, for more detailed reason see the link: http://www.mail-archive.com/help-glpk@gnu.org/msg02701.html

I will make a fix, which makes silent the GLPK.

Changed 15 years ago by Balazs Dezso

Attachment: 21148f69b6c7.patch added

Silent glp_adv_basis()

comment:4 Changed 15 years ago by Balazs Dezso

The [21148f69b6c7] makes the glpk silent.

comment:5 in reply to:  4 ; Changed 15 years ago by Alpar Juttner

Replying to deba:

The [21148f69b6c7] makes the glpk silent.

Shouldn't we put this

glp_term_out(false);

line somewhere into the messageLevel() function instead?

Btw. Is there any reason why the messageLevel() function is implemented both in GlpkLp and GlpkMip instead of being implemented in GlpkBase?

comment:6 in reply to:  5 ; Changed 15 years ago by Balazs Dezso

Replying to alpar:

Replying to deba:

The [21148f69b6c7] makes the glpk silent.

Shouldn't we put this

glp_term_out(false);

line somewhere into the messageLevel() function instead?

I do not think. There are message levels for control the output of the solvers, but it does not control the output of other functions, like

glp_adv_basis(lp, 0);

But, if we switch off the output in the output globally with

glp_term_out(false);

then the solver will not print message independently from message level.

Btw. Is there any reason why the messageLevel() function is implemented both in GlpkLp and GlpkMip instead of being implemented in GlpkBase?

The reason is rather historical. I think, the message levels and the setting functions can be moved to the GlpkBase?.

comment:7 in reply to:  6 ; Changed 15 years ago by Alpar Juttner

Replying to deba:

But, if we switch off the output in the output globally with

glp_term_out(false);

then the solver will not print message independently from message level.

You probably misunderstood me. I suggested that messageLevel(0) should also imply glp_term_out(false), but higher message levels would use glp_term_out(true)

Isn't it a good idea?

The reason is rather historical. I think, the message levels and the setting functions can be moved to the GlpkBase?.

Let's move it then.

comment:8 in reply to:  7 ; Changed 15 years ago by Balazs Dezso

Replying to alpar:

Replying to deba:

But, if we switch off the output in the output globally with

glp_term_out(false);

then the solver will not print message independently from message level.

You probably misunderstood me. I suggested that messageLevel(0) should also imply glp_term_out(false), but higher message levels would use glp_term_out(true)

Isn't it a good idea?

It isn't.

  GlpkLp lp1, lp2;
  lp1.messageLevel(GlpkLp::MESSAGE_FULL_OUTPUT);
  lp2.messageLevel(GlpkLp::MESSAGE_NO_OUTPUT);

The reason is rather historical. I think, the message levels and the setting functions can be moved to the GlpkBase?.

Let's move it then.

Ok, but I would like to this under other ticket, namely I would like to make message handler function for all solvers under #9.

comment:9 in reply to:  8 Changed 15 years ago by Alpar Juttner

Replying to deba:

Replying to alpar:

Replying to deba:

But, if we switch off the output in the output globally with

glp_term_out(false);

then the solver will not print message independently from message level.

You probably misunderstood me. I suggested that messageLevel(0) should also imply glp_term_out(false), but higher message levels would use glp_term_out(true)

Isn't it a good idea?

It isn't.

I see. This is a global setting. Still it could be done in a way that messageLevel() would set a flag and you use that flag to set glp_term_out() when call glp_adv_basis(). It works, unless we use GLPK in two threads.

Btw. is that possible to use GLPK paralelly? Is GLPK thread safe?

Anyway, making glp_adv_basis() completely silent is acceptable.

comment:10 Changed 15 years ago by Alpar Juttner

Resolution: fixed
Status: assignedclosed

The changesets are in the main branch now, but with changed commit logs and rebased to the tip. See [7ab97e2a0c33] and [e7017ec2d5cd].

Note: See TracTickets for help on using tickets.