Embedding CBC to the user's applications
|Reported by:||mserg||Owned by:||somebody|
Embedding CBC to the application is not so easy. I tried to use a “cbcSolve.exe” and dll-library on windows-platform. Maybe I am needed in good advice against the Cbc is is needed in changing…
*Using “exe” schema:
- User application is create the mps-file in the temporary directory.
- User application is starting the cbcSolve.exe with follow parameters:
- -directory [Temporary folder]
- –import [mps-file]
- -message on
- user’s solving options
- –solu [Results file]
The output of cbcSolve.exe is redirected to the log-file.
- User application is waiting when cbcSolve.exe is completed. During this time user application:
- Periodically read the tile of log-file and showing it to user.
- Grepping the the readied log-file rows and finding in its solution bounds and number of nodes and iterations.
- If user want to stop the solving process or halting it then ctrl+c is sended to cbcSolve.exe window. ctrl+c is send one time for stopping and twice for halting.
- User application read the results from file and show its to user.
This scheme has several problems. Some of its can be reproduced by special debugging program (see http://np-soft.ru/downloads/embedding.zip). Unpack this archive and put to the same directory cbcSolve.exe.
- The informing user about solving process is delayed because output in CBC is not flushed. For example run EmbeddedCbc?.exe from archive, open and run “LifeGameCp?.mps“. There is the long output delay after message “Cbc0038I After … seconds - Feasibility pump exiting - took … seconds” is happen…
- Accuracy in result file is too low. For example, run “BigVar?.mps” in EmbeddedCbc?.exe. We have the zeros instead of right digits in x1 and x2 result values. The low accuracy of objective bounds in messages in the log is problem too. As rule I use the objective with the “infeasibility” variables and optimizing variables. “Infeasibility” variables have the big factors and optimizing variables have the relative small factors in objective. So, the optimizing variables part has a chance to be lost because objective value is shown “rounded”.
- The breaking (stopping) and halting of execution of cbcSolve.exe by “ctrl+c” is not stable. It is very nice to have the semaphore-files to breaking and halting executing of cbcSolve.exe. Periodically cbcSolve.exe should check the existence of those files and break or halt if it needed. Also in that case “black window” of cbcSolve.exe can be hided…
Using “dll” schema.
In version 2.0 I have found the dll interface. But I not found how to add cut generators and heuristics by interface. It is nice to have the “dll” interface + “cbcSolve.exe” interface (cut generators and heuristics) + branch and cut part of “cbcSolve.exe”. In other words it is very convenient to have cbcSolve as a dll + model putting, result reading and event handling pointers from current dll interface. It gives the possibility to exchanging between the user application and solver without using the files.