fix:solveConcurrent did not work correctly

[zengbin5966]

/** returns the number of threads */
int SCIPtpiGetNumThreads(
   void
   )
{
   return _threadpool != NULL ? _threadpool->nthreads : 0;
}

In the multi-threaded version of the SCIP with TPI=TNY, the value returned by the SCIPtpiGetNumThreads function does not match the value we expected to set during initialization, but is always 1. This is because the _threadpool value only changes after the SCIPsolveConcurrent function has been called (this is just my current observation, please correct me if there is an error, thank you). Therefore, in the TNY version, using solveConcurrent will always raise the warning

SCIP was compiled without task processing interface. Parallel solve not possible - using optimize() instead of solveConcurrent()

instead of correctly invoking the solveConcurrent function in SCIP

[Opt-Mucca]

Your observation is correct, but I believe this has recently been fixed in SCIP. If you compile against SCIP master then the current code should work. This means that the issue will naturally resolve itself once we link against a newer SCIP version.

I am also against removing the guardrails from calling solveConcurrent, and like having the fallback for it calling optimize. Open to other opinions still.

[zengbin5966]

Your observation is correct, but I believe this has recently been fixed in SCIP. If you compile against SCIP master then the current code should work. This means that the issue will naturally resolve itself once we link against a newer SCIP version.

I am also against removing the guardrails from calling solveConcurrent, and like having the fallback for it calling optimize. Open to other opinions still.

I agree with your point, the call to solveConcurrent function should indeed have safeguards in place. Perhaps the modification needed is not in the "if SCIPtpiGetNumThreads() == 1:" condition, but rather using SCIPtpiIsAvailable() could be a better alternative?