<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi John,<br>
<br>
first of all, I'd like to thank you and other contributors. I have
been testing cbc for several months now with various MiniZinc
benchmarks and, thanks to the numerous bug fixes made by you and
others, mzn-cbc (the MiniZinc solver with Cbc backend) runs without
contradicting answers on the 400 instances of the last 4 MZN
Challenges. Wow, I haven't expected that. We compare results to
CPLEX and Gurobi, with various CP->MIP translation options, and
also without pre-processing.<br>
<br>
Continuous printing of new solutions is not essential but has been
requested. I have printed the post-processed solutions from the
callback, they have fractional values, so I am sure they are just LP
solutions. (As opposed to model_->bestSolution() as in the
original interrupt.cpp.) I cannot answer your question why there are
sometimes 2 event calls after a new solution. I have inserted log
messages before each relevant event call in CbcModel.cpp, printing
"event(.....) + line number". Attached file cbcCallbacks_photo.log
has the output of my solver for the example photo.mps.gz. The
callback also prints deduced bounds info + MiniZinc output (if new).
The modified CbcModel.cpp is also attached.<br>
<br>
If you consider it reasonable effort to fix this (is not urgent),
you can use the modified example interrupt.cpp. It prints both
model_->bestSolution() as well as (post-processed)
origModel->getColSolution(). The output on photo.mps is in
photo_interrupt.log. In photo.mps, x[8] is the objective function
value. You see that both model_->getObjValue() as well as
origModel->getObjValue() not always correspond to the Cbc log's
new best obj value.<br>
<br>
Moreover, such a callback should also handle the case without
preprocessing, which is reflected in the new code.<br>
<br>
Finally, on ff_cbc.mps, there is a segfault after 37k nodes. It
happens in postProcess().<br>
<br>
Gleb<br>
<br>
<div class="moz-cite-prefix">On 26/02/2016 6:23 AM, John Forrest
wrote:<br>
</div>
<blockquote cite="mid:56CF54B9.2040405@fastercoin.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">Gleb,<br>
<br>
So I don't understand why you get two VALUE messages but only
one Cbc message.<br>
<br>
John<br>
On 25/02/16 18:34, Gleb Belov wrote:<br>
</div>
<blockquote
cite="mid:CAKSwnJa5ALazcLpxRoasLgpCmzdxAcfPj_Wo2aSiF3gnjybUdA@mail.gmail.com"
type="cite">
<p dir="ltr">John,</p>
<p dir="ltr">Checking for parentModel()==NULL is being done as
in interrupt.cpp, sorry for not mentioning. </p>
<p dir="ltr">Gleb</p>
<div class="gmail_quote">On Feb 26, 2016 4:15 AM, "John Forrest"
<<a moz-do-not-send="true"
href="mailto:john.forrest@fastercoin.com">john.forrest@fastercoin.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Gleb,<br>
<br>
On 25/02/16 05:21, Gleb Belov wrote:<br>
</div>
<blockquote type="cite"> -- Thank you John,<br>
<br>
a,b) this is not a very clean interface... maybe put
this into postProcess so I can access the correct obj
from originalModel()?<br>
<br>
c) what do you mean by size? The preprocessed model has
always smaller NumColumns() than the start model in my
examples and originalModel() has always the same number.
In the meantime I have an example where postProcess()
crashes, probably on a model which is not intended to be
post-processed.<br>
</blockquote>
<br>
A cleaner way than checking size would be to pick up
model->parentModel() and don't report if this is not
NULL.<br>
<blockquote type="cite"> <br>
How is it with cut generators, do they get LP solution
for the original model?<br>
<br>
</blockquote>
Preprocessed model<br>
<blockquote type="cite"> I'd be happy to access the
current number of open (unexplored) nodes by some
interface method. Also in the solution callback,
assuming we get it to work.<br>
<br>
</blockquote>
Crude way would be to pass in a print handler - just does
as normal but checks if message is Cbc0010 and gets open
nodes.<br>
<blockquote type="cite"> I noticed when performing
postprocessing in the callback, the solution way
differs... probably because post-processing calls some
LP resolving procedures? I tried to create a copy of
*cbcCglPreProcess each time but the copy crashes.<br>
<br>
Gleb<br>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>