[Cbc] Solution callbacks

[John Forrest]

Gleb,

Find attached revised version of interrupt.cpp.

Variable 9 - has correct value in postprocessed solution.

ff_cbc went through correctly.

John


On 26/02/16 06:31, Gleb Belov wrote:
> Hi John,
>
> 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.
>
> 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.
>
> 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.
>
> Moreover, such a callback should also handle the case without 
> preprocessing, which is reflected in the new code.
>
> Finally, on ff_cbc.mps, there is a segfault after 37k nodes. It 
> happens in postProcess().
>
> Gleb
>
> On 26/02/2016 6:23 AM, John Forrest wrote:
>> Gleb,
>>
>> So I don't understand why you get two VALUE messages but only one Cbc 
>> message.
>>
>> John
>> On 25/02/16 18:34, Gleb Belov wrote:
>>>
>>> John,
>>>
>>> Checking for parentModel()==NULL is being done as in interrupt.cpp, 
>>> sorry for not mentioning.
>>>
>>> Gleb
>>>
>>> On Feb 26, 2016 4:15 AM, "John Forrest" <john.forrest at fastercoin.com 
>>> <mailto:john.forrest at fastercoin.com>> wrote:
>>>
>>>     Gleb,
>>>
>>>     On 25/02/16 05:21, Gleb Belov wrote:
>>>>     -- Thank you John,
>>>>
>>>>     a,b) this is not a very clean interface... maybe put this into
>>>>     postProcess so I can access the correct obj from originalModel()?
>>>>
>>>>     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.
>>>
>>>     A cleaner way than checking size would be to pick up
>>>     model->parentModel() and don't report if this is not NULL.
>>>>
>>>>     How is it with cut generators, do they get LP solution for the
>>>>     original model?
>>>>
>>>     Preprocessed model
>>>>     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.
>>>>
>>>     Crude way would be to pass in a print handler - just does as
>>>     normal but checks if message is Cbc0010 and gets open nodes.
>>>>     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.
>>>>
>>>>     Gleb
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20160226/9fceeb7c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interrupt.cpp
Type: text/x-c
Size: 14789 bytes
Desc: not available
URL: <http://list.coin-or.org/pipermail/cbc/attachments/20160226/9fceeb7c/attachment-0001.bin>