<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Gleb,<br>
<br>
Find attached revised version of interrupt.cpp.<br>
<br>
Variable 9 - has correct value in postprocessed solution.<br>
<br>
ff_cbc went through correctly.<br>
<br>
John<br>
<br>
<br>
On 26/02/16 06:31, Gleb Belov wrote:<br>
</div>
<blockquote cite="mid:56CFF15A.7030705@monash.edu" type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=utf-8">
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">
<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">
<div>
<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>
</blockquote>
<br>
</body>
</html>