Re: [Help-glpk] OPB output file anomaly

[Andrew Makhorin]

>> You could write your instance also in cplex format specifying the
>> option '--wcpxlp outfile' along with '--wopb' and then check both
>> the files. AFAIK cplex lp format is very similar to opb format.
>> 

> I did as you suggested and it was quite illustrative.  The formats
> are indeed very similar. For my empty LHS constraints in OPB:

> <= 15
> <= 15
> etc.

> The cplex format has:

> Departure_Rate(LAS,3): 0 w(AC12_11,DUMMY_DST,151) <= 15
> Departure_Rate(LAS,4): 0 w(AC12_11,DUMMY_DST,151) <= 15
> etc.

> So it does look like these constraints are trivially satisfied if I
> am interpreting the output correctly.

In cplex format there is the same picture, i.e. it does not permit
empty left-hand side, so the output routine uses a first variable
with zero coefficient to make a fake lhs. I do not know whether opb
format allows zero coefficients or not.

>   So I guess that would be a good
> little patch in the lpx_write_pb() function.  Line 129 looks like this:

> k=glp_get_mat_row(lp, j, ndx, val);

> Immediately following this line I added:

> if( k == 0 ) continue;

> And the empty LHS inequalities went away.  It may have broken
> something else for all I know, but maybe Oscar could let us know if
> adding that line hurts anything else.

There should be a check for infeasible empty rows, i.e. rows like
0 <= -3 or 0 >= +3. If such rows are removed, the routine must issue
at least a warning message that the original instance is infeasible.

> I realized something else I had to do to the output OPB file for
> acceptance by minisat+.  For some reason, minisat+ doesn't like
> brackets or commas.  This is a problem since my binary variables are
> 3-dimensional and all have brackets and commas in there respective
> names.  This is clearly a minisat+ problem though and not a GLPK
> issue.  The reason I bring it up is that maybe I hurt the file when I
> remove/replace these symbols with sed.  I don't think I hurt the
> integrity of the file, but will have to verify that.  The only clue I
> have that I may have damaged the file is the fact that I am still
> getting a different solution out of minisat+.  

> But at least now I am pretty sure the problem isn't with glpk.  If
> I discover anything more regarding this issue, I'll be sure to update
> the thread for posterity.  Thanks for the help Andrew and Oscar.