>> 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. _______________________________________________ Help-glpk mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-glpk
