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