Help needed with some maintenance tasks

[tkralphs]

Hi all, many of you have been waiting for a Cbc 3.0 release and I would like to thank you for your patience. There is a draft PR open (#374) that I could use some help in finishing. What's left to do doesn't require any knowledge of Cbc's inner workings. All the details are described in the PR, but in short summary, what remains at a minimum is

• some debugging (there are still probably a few surface-level bugs hanging around that I haven't had time to track down) and
• some thorough testing to make sure there are no performance regressions.

I would also really like to create a minimal CbcSolver class, rename CbcMain1() and move it into that class, make CbcMain0() the default constructor of the new CbcParameters class, and finally break up the humongous while loop into some smaller pieces so we can reformat the code. Currently, clang-reformat can't even parse the code in CbcSolver.cpp. Emacs also gets lost when trying to find matching braces parentheses. This makes maintenance particularly difficult.

None of this would change any functionality and shouldn't take much time. The heavy lifting is done (there are some nice-to-have things listed in the PR that are a little more difficult, but we could push those off to another release if needed). Let me know if you have some bandwidth to pitch in. The best way to contribute would probably be to create additional PRs based off the refactor branch.

[tosttost]

I'd like to help but unfortunately building the refactor branch fails on my machine:

./coinbrew fetch Cbc@refactor
./coinbrew build Cbc@refactor

gives

/some/path/Cbc/src/CoinSolve.cpp:22:10: fatal error: CbcDebug.hpp: No such fil                                                                                                                                                                     e or directory
 #include "CbcDebug.hpp"
          ^~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:1613: cbc-CoinSolve.o] Error 1
make[1]: *** [Makefile:782: all] Error 2
make: *** [Makefile:457: all-recursive] Error 1

Build failed, see error output above

Some debugging (...)

are there any starting points?

Some thorough testing (..)

I can use some of our models for that, but only comparering against the master branch as our somewhat hacky cmake+coinbrew build system does not really work with 2.10. Of course only after the refactor branch compiles.

[tkralphs]

OK, just committed a few more small fixes, now it seems to solve instances as expected, at least with simple invocations from the command line. I just noticed, though that valgrind is complaining about conditional branch based on uninitialized memory so a few bugs there to track down.

[tosttost]

I already tracked 'conditional branch based on uninitialized memory' down but the PR needs some cleanup - hopefully I find time to finish it tonight.

[tkralphs]

Great!

[tkralphs]

I now rebased the Clp refactor branch on master.

[tkralphs]

Finally, all unit tests are passing, although there are still some failures in the Travis builds due to symbols not being exported properly.

[jhmgoossens]

I looked quite long and hard at the "ProximityNumber" code in CbcSolverHeuristics ("//TODO: There is a bug here."), but couldn't wrap my head around the fakeKeyword, fakeValue, etc. in the old currentOptionAsInteger(..). Anyway, where have the parameter descriptions of old clp's CbcOrClpParam.cpp moved to?

[tkralphs]

The descriptions of parameters can now be found in in CbcParameters.cpp and ClpParameters.cpp respectively, in the functions that set up the parameters from the constructor of the CbcParameters and ClpParameters classes. Here

Cbc/src/CbcParameters.cpp

Lines 1549 to 1562 in 59145ee

	parameters_[CbcParam::PROXIMITY]->setup(
	"proximity!Search", "Whether to do proximity search heuristic", "off",
	getProximityMode(),
	"This heuristic looks for a solution close to the incumbent solution "
	"(Fischetti and Monaci, 2012). The idea is to define a sub-MIP without "
	"additional constraints but with a modified objective function intended "
	"to attract the search in the proximity of the incumbent. The approach "
	"works well for 0-1 MIPs whose solution landscape is not too irregular "
	"(meaning the there is reasonable probability of finding an improved "
	"solution by flipping a small number of binary variables), in particular "
	"when it is applied to the first heuristic solutions found at the root "
	"node. " HEURISTICS_LONGHELP); // Can also set different maxNode
	// cbcSettings by plusnnnn (and are
	// 'on'(on==30)).

)
is the description of PROXIMITY.

[tkralphs]

OK, I sort of figured out what's going on there. The parameter PROXIMITY has a sort of double meaning, but it never seems to have been fully implemented. It is a keyword parameter, which takes values off, on, both, before, like the other heuristics, but it can also take on values 10, 100, and 300 (as strings, not integers). So what we really need is a separate parameter to control the proximityNumber, but I just left as it was for now, except checking to see whether the value is one of 10, 100, and 300 and if so, set proximityNumber appropriately.