Discrepancies between Cbc C interface and CbcSolver

[spoorendonk]

It is unclear for me if the behavior of the C interface is similar to that of using CbcSolver?

From the C interface it seems like using CbcModel with CbcMain0 and CbcMain1 is the way to go with a messageHandler to do callbacks? It appears one would have to redo the C interface flow to get a C++ version with the same features?

Intuitively it would be nice to have a C++ solver that is thinly to C. Maybe this is related to #309 ?

Am I missing something?

[h-g-s]

Hi @spoorendonk , CbcMain0 and CbcMain1 are the recommended way of calling Cbc. In these two methods the parameters are well tuned by @jjhforrest . The C interface uses them to call CBC.

You should use a messagehandler in CbcMain0 and CbcMain1 to callbacks (mostly monitoring).

[tkralphs]

@spoorendonk You're suggesting a C++ wrapper around a C wrapper around a C++ interface :)? It doesn't look like it should be that difficult to untangle things and make it possible to call Cbc in the same way from OsiCbc, the C interface, and CbcSolver, but I honestly haven't looked that deeply into it. This would be great if we could do it. It could make sense just to call the C interface itself from OsiCbc, which would then essentially be a C++ wrapper around a C wrapper around a C++ interface.

[spoorendonk]

thanks for answer @h-g-s and @tkralphs

I think I was looking for a C++ interface (CbcSolver) that is then wrapped in C (Cbc_C_Interface) and wrapped in OsiCbc. See also #309

It could be by untangling the C interface code and put it into CbcSolver and then use CbcSolver instead. Then OsiCbc would call CbcSolver.

[tkralphs]

Yes, ideally, we could get everything into CbcSolver and then both the C interface and OsiCbc would just thinly wrap that.

[h-g-s]

Some additional code in the C interface will probably always be necessary: some customizations in CBC involve creating specialized classes (e.g. cut generators), in C everything should be available in callbacks.

[spoorendonk]

@h-g-s seems right. Perhaps the custom classes could be added to CbcSolver or the C interface could implement a simple derived version CbcSolver that embeds the callbacks in inherited user methods? Just to have an (almost) single point of entry.

What does the cbc_callback do? The other are self explainable - incumbent, progress, cuts.

[h-g-s]

Another important thing that I remembered.

When I was using directly the OsiClpSolverInterface, adding variables/constraints one by one was terribly slow. I implemented a buffer in the C interface that automatically flushes the added variables/constraints only when necessary, in a batch. There are even some queries that can be performed without flushing. This makes these incremental problem creation much faster. Ideally this buffer should be implemented in Osi, I think...

[tkralphs]

Yes, I believe some similar tricks are used in some of the Cbc interfaces. Those kind of things could be added over time, once the basic functionality is there.

[spoorendonk]

Is this similar to what is done with the CoinModel from CoinUtils? Would it be an option to wrap the CoinModel and CbcModel inside CbcSolver to get this functionality?