Re: gurobipy non-deterministic behaviour

[Ed Rothberg]

I don't know of any sources of non-determinism in what you describe.  In cases where people have reported non-determinism, from what I recall the two main causes have been: (i) time limits in the code, and (ii) using random numbers without setting a constant seed.

Ed

[stefano.gualandi]

Hi Ed, Simon,

I am observing the same behaviour Simon was reporting last year with a basic column generation algorithm implemented in python.

My setting is as follow: OSX 10.8 with gurobi 5.5, using the python wrapper.

The same happen under linux-ubuntu.

Implementing a basic column generation, where the pricing subproblem is a shortest path on a directed acyclic graph,

I am observing a kind of "non determinism". Two different execution of the column generation script, should

give the same exact number of iterations, but this happen only if I use the barrier to solve the continuous restricted master problem

e.g., model.setParam(GRB.Param.Method,     2). Otherwise, using for instance the dual simplex, this does not happen.

It might be an issue on the python wrapper?

If you like, I can send you the python script with a small instance that exposes this issue.

thanks in advance,

Stefano

P.S. The current GRB.param module is missing the parameters "DualReductions" and "LazyConstraints",

even if they can be used as plain string.

[Ed Rothberg]

We're not aware of anything that would cause this.  We'd like to take a look.

> If you like, I can send you the python script with a small instance that exposes this issue.

Please do.  Send it to 'sup...@gurobi.com'.

> P.S. The current GRB.param module is missing the parameters "DualReductions" and 

> "LazyConstraints", even if they can be used as plain string.

Thanks, we'll fix that.

[Ed Rothberg]

> We're not aware of anything that would cause this.

I actually misspoke.  We had already seen this.  It was an issue in how we were using Python dictionaries within the Column() class.  In case you are interested, it turns out that if you create the same dictionary twice, using the exact same key,value pairs, it is possible for d.keys() to be in a different order the second time.

In any case, this is fixed in 5.6.

Ed