Re: [Bug-glpk] regarding glpk49

[Andrew Makhorin]

> I would suggest an option that a user can specify, which will
> (over)write the current incumbent solution in a file whenever a new 
> incumbent is found.
> 
> This should not be hard to implement.  It would not have the same 
> information as at the time of termination (since the LP bound may have 
> been decreased since the incumbent was found), but it would not require 
> much I/O in most cases.

Completely agreed.

> 
> A more aggressive option would be to update a file each time the gap was 
> reduced.  This would slow down the code a lot more, and I would not 
> recommend implementing it.
>
> If you like, I could probably write and contribute the necessary code 
> for the incumbent file (or ask a student to do so).

It would be great. On api level there should be a control parameter
which specifies an entry point to the user routine called every time
when the mip solver finds a next integer feasible solution.
Specifying the entry point enables this feature, in which case the
mip solver stores the solution back to LPX before calling the user
routine in order to make the solution components available via
lpx_mip_obj_val, lpx_mip_row_val, and lpx_mip_col_val. Then in glpsol
such routine could print the solution to a file. Should note that in
lpx_intopt (unlike lpx_integer) the mip postsolver needs to be called
in order to build solution of the original problem.

I think the best way is to pass the entry point to lpx_integer and
to lpx_intopt as the second argument. The corresponding routine
could have the following prototype:

int func(LPX *prob, int event, ...);

where depending on event there may be additional arguments (I mean
that other check points can be defined where the routine is called).
Besides, if the routine returns non-zero, this could cause the mip
solver to prematurely terminate the search "by user request".


Andrew Makhorin