[Scip] Inconsistent solving on different computers

[Stefan Lörwald]

Dear SCIP Developers,

a friend of mine recently discovered that SCIP behaves differently on
different machines.

Although on every tested machine, the solution value is identical, the
solution process differs quite radically. This are the results for the LOP
example with problem ex1.mat

Virtual machine (64 bit)

Solutions found  :         11 (11 improvements)
First Solution   : +2.65100000000000e+03   (in run 1, after 1 nodes, 0.29
seconds, depth 592, found by <shiftandpropagate>)
Solving Time (sec) : 21.39
Solving Nodes      : 506
Root Dual Bound  : +3.10268636989738e+03


Virtual machine (32 bit)

Solutions found  :         10 (9 improvements(null))
First Solution   : +2.65100000000000e+03   (in run 1, after 1 nodes, 0.38
seconds, depth 592, found by <shiftandpropagate>)
Solving Time (sec) : 28.52
Solving Nodes      : 546
Root Dual Bound  : +3.10271332082478e+03

netbook (32 bit)

Solutions found  :         11 (10 improvements(null))
First Solution   : +2.65100000000000e+03   (in run 1, after 1 nodes, 3.17
seconds, depth 592, found by <shiftandpropagate>)
Solving Time (sec) : 245.61
Solving Nodes      : 1093
Root Dual Bound  : +3.10271332082478e+03

Our expectation was that both the number of solutions and the number of
solving nodes should be identical, but they aren't.
The actual solving time is of course irrelevant because it depends heavily
on the hardware.
To my knowledge, on every platform the code was compiled with the newest
version of SCIP / SoPlex available.

Now two possible causes come to my mind:

Undefined behaviour and/or unspecified behaviour.

So the question is: Is this behaviour intended? If so, why? For
comparability it seems logical to me to compare the number of solving nodes
rather than solving time. That's because time measurements are not portable
(practically always scaled). However the number of logical steps the
algorithm takes (if deterministic) should be the same.
Asked provocatively: How can I ever make statements about the performance
if it's not reproducible (at least up to scaling)?


Thanks in advance for clarification,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.zib.de/pipermail/scip/attachments/20131120/3e1ac784/attachment.html>