Closed orthorhombic closed 2 weeks ago
svigerske
commented
3 months ago I only made it compile again.
But also our internal tests started to fail after upgrading to a more recent HiGHS, 1.7.2 in particular. The SCIP/HiGHS link developers @ambros-gleixner @alexhoen @GioniMexi have been made aware of this and I hope they will look into it soon.
You may have to go back to an older HiGHS version for now.
orthorhombic
commented
3 months ago Just following up on this, I tried iterating on a variety of configurations where I iterated on the dockerfile I shared above, but have continued to run into issues getting all the tests to pass. I was able to get more tests working with SCIP 9.1.0 with HiGHS 1.6.0 as long as I did cp ${INSTALLS}/lib/libhighs.a ${INSTALLS}/lib/liblibhighs.a (results below)/
You mention HiGHS 1.7.2 in particular giving you trouble on the internal tests. Are you aware of any "known good" SCIP/HiGHS version pairings that would be recommended as a baseline? How much weight should I put on getting passing tests? Any other details you can shat that might help?
In other words, if a pairing of versions seems to successfully solve problems I throw at it, do you think I should I trust the results?
The following tests FAILED: 800 - MIP-readertest-lp-blend2.mps (Failed) 802 - MIP-readertest-pip-blend2.mps (Failed) 805 - MIP-readertest-rlp-blend2.mps (Failed) 1225 - unittest-sepa-gauge (Failed)
Error (all same):
[lpi_highs.cpp:496] ERROR: HiGHS terminated with model status <Unknown> (15) after simplex strategy <Dual (serial)> (1)
[lpi_highs.cpp:1486] ERROR: Error <-6> in function call
GioniMexi
commented
3 months ago The error happens when solving an LP in strong branching.
The model_status_ of highs changes from kIterationLimit to kNotSet when turning presolve back on after the LP solve
https://github.com/scipopt/scip/blob/master/src/lpi/lpi_highs.cpp#L519
HIGHS_CALL( lpi->highs->setOptionValue("presolve", "on") );
@ambros-gleixner this happens in the codeblock:
/* if basis factorization is unavailable, this may be due to presolving; then solve again without presolve */
HIGHS_CALL( lpi->highs->getOptionValue("presolve", presolvestring) );
assert(presolvestring == "on" || presolvestring == "off"); /* values used in SCIPlpiSetIntpar() */
if( !lpi->highs->hasInvert() && presolvestring == "on" )
{
SCIP_RETCODE retcode;
SCIPdebugMessage("No inverse: running HiGHS again without presolve . . .\n");
HIGHS_CALL( lpi->highs->setOptionValue("presolve", "off") );
retcode = lpiSolve(lpi);
if( retcode != SCIP_OKAY )
{
HighsModelStatus model_status = lpi->highs->getModelStatus();
SCIPerrorMessage("HiGHS terminated with model status <%s> (%d) after trying to recover inverse\n",
lpi->highs->modelStatusToString(model_status).c_str(), (int)model_status);
}
HIGHS_CALL( lpi->highs->setOptionValue("presolve", "on") );
SCIP_CALL( retcode );
}where presolving is turned off and on again.
There was a recent change in highs where the model_status is reset in setOptionValue() if the solution is not primal or dual feasible. In our case, the LP was solved by dual simplex up to the iteration limit and the solution was not primal feasible.
@ambros-gleixner One workaround could be to set the model status to the previous value after calling setOptionValue(), or change the logic in lp.c? which is more involved, or ask Julian if it is really necessary to reset the model_status when changing a parameter.
ambros-gleixner
commented
3 months ago We should not change the logic in lp.c, and I would not count on Highs changing this behavior.
Another workaround, that may be easier to implement and safer:
HIGHS_CALL( lpi->highs->setOptionValue("presolve", ...) ); if necessary in lpiSolve()
Then we can remove the last setOptionValue in the above code block and the model status should be kept by Highs.Sounds good?
GioniMexi
commented
3 months ago Sounds good, I will prepare a MR for this
svigerske
commented
2 weeks ago @GioniMexi implemented the workaround that was suggested by @ambros-gleixner and this has been included in SCIP 9.2.0.
DominikKamp
commented
2 weeks ago ...though MIP-readertest-mps-blend2.mps will still fail as described in https://github.com/scipopt/scip/issues/102#issuecomment-2303570179 since LP errors are handled more verbose than necessary but these LP results are withdrawn safely as usual (you can trust the results).
Summary
I'm unable to get the SCIP tests to pass when compiling SCIP with HiGHS set as the solver. Specifically I tested this with SCIP 9.1.0 and HiGHS 1.7.2 (and 1.7.1). It finished compiling without error, but there are a series of tests that fail when HiGHS is set as the solver. All the HiGHS tests pass, so I figured I'd reach out here first. I didn't have any problem when setting
-DLPS=spx.I'm unsure if this is related to #89, though I didn't see the errors specified there. @svigerske, in the same issue you mentioned being able to compile "the SCIP/HiGHS interface of SCIP 9.1.0 with HiGHS 1.7.1." Is the below configuration what you meant and were you able to successfully get the tests to pass?
I apologize in advance if I'm missing something with how I'm compiling. Solutions or next steps for troubleshooting are welcome.
Tests that fail
Specifically this is the list of failing tests from when I was trying to trying to compile the whole suite and not just SCIP. Just to speed up testing, I randomly selected one of these tests for the Dockerfile.
Error from trying to build the Dockerfile
After spot checking a few of the tests failing above, all seemed to have the same error as below.
Sample Dockerfile to try to compiling:
I saved the below as
Dockerfile_testand tried building it with the command below. The specified test was one randomly selected from the list above.docker build -t build_test --file Dockerfile_test --progress=plain . &> build_test.log