coin-or / coinbrew

COIN-OR build and installation script
29 stars 15 forks source link

Osi Unit Test errors #96

Open caelumspace opened 2 months ago

caelumspace commented 2 months ago

using the command ./coinbrew build Cbc@stable/2.10

I get the following notices...

##################################################

Configuring Osi 0.108

##################################################

configure: WARNING: No solver available, examples will not work.

then... ##################################################

Running Osi unit test

##################################################

Testing OsiRowCut with OsiTestSolverInterface Testing OsiColCut with OsiTestSolverInterface Testing OsiCuts Testing OsiTestSolverInterface vol: running common unit tests. Testing row/column name handling ... volSolverInterface testing issue: testNames: switch to lazy names failed: si->setIntParam(OsiNameDiscipline, 1) == true volSolverInterface testing issue: cloning of application data failed: (static_cast< int >(si2->getApplicationData())) == ad Checking that solver can set row and column solutions ... ok. Testing loadProblem and assignProblem methods. volSolverInterface testing issue: testLoadAndAssignProblem: base initialSolve failed: base->initialSolve() threw CoinError: Volume algorithm is unable to handle ranged rows in OsiTestSolverInterface in checkData_ volSolverInterface testing issue: addCol add columns to null Testing writeMps and writeMpsNative. volSolverInterface testing issue: testWriteMps: solving LP failed: si1->initialSolve() threw CoinError: Volume algorithm is unable to handle ranged rows in OsiTestSolverInterface in checkData_ Testing writeLp and writeLpNative. volSolverInterface testing issue: testWriteLp: solving LP failed: si1->initialSolve() threw CoinError: Volume algorithm is unable to handle ranged rows in OsiTestSolverInterface in checkData_ Checked 8 hints x (true, false) at strength OsiForceDo; 16 throws. Skipped Testing of OsiSolverInterface on Netlib problems use -testOsiSolverInterface to run them. Tests completed with 1 unexpected errors. make[1]: [Makefile:693: test] Error 1 make: [Makefile:915: test] Error 2

Error: Build failed, see error output above

I am using Ubuntu 24 server (x64)

Am I missing a step? Thanks in advance!

tkralphs commented 1 month ago

The vol project is not really maintained, so if you don't really need it, then I would just skip building that one. To get past this error, which is probably not consequential, try adding --tests none to your coinbrew arguments. In all likelihood, the build will go through and everything will work fine. If you have problems after that, then feel free to open another issue.

tkralphs commented 1 month ago

Actually, I'm not sure why vol is even being fetched and built, since it is not a dependency of Cbc.

svigerske commented 1 month ago

It's not fetched, but Vol is the solver that is used by the Osi unittests if no other solver is available. There is a copy of Vol+OsiVol in Osi/test/OsiTestSolver. It was chosen because it was small.

The Osi unittests know that vol does not pass all tests and thus some errors are expected. For example,

*** volSolverInterface testing issue: testLoadAndAssignProblem: base initialSolve failed: base->initialSolve() threw CoinError: Volume algorithm is unable to handle ranged rows in OsiTestSolverInterface in checkData_

is expected due to the condition given to OSIUNITTEST_CATCH_SEVERITY_EXPECTED:

    OSIUNITTEST_CATCH_SEVERITY_EXPECTED(base->initialSolve(), return, *base, "testLoadAndAssignProblem: base initialSolve",
      TestOutcome::ERROR, solverName == "vol" && !basePv.isEquivalent(pv));

However, there seems to be one unexpected error. I think it's this one:

 *** volSolverInterface testing issue: cloning of application data failed: *(static_cast< int * >(si2->getApplicationData())) == ad

from https://github.com/coin-or/Osi/blob/22df8195b69530233c964cf54da62392c216162b/src/OsiCommonTest/OsiSolverInterfaceTest.cpp#L4044

tkralphs commented 1 month ago

Ah, thanks for the reminder. I would still try skipping the tests first. I have seen the odd failure like this, but as long as all test are passing on CI, I wouldn't dig into it unless it is causing problems that affect practical usage.