Root Node / Solving Stage

[LovisAnderson]

Hello,

I am currently developing a probing/diving environment in ecole. So far, I only use pyscipopt through the as_pyscipopt() function in ecole. In order to use pyscipopt's model.startProbing(), I need to be in SCIP_STAGE_SOLVING . To be more precise, I would like to be in this stage at the root node. Preferably, but not necessarily, before the root lp is solved.

If i understand correctly, you interact with SCIP in the solving stage through the function solve_iter (or for branching also solve_iter_branch). When solve_iter is called in the reset_dynamics, the solving is initialized and the root node lp is solved. Calling this function could do the trick for me. This function seems not callable from python though. Is it possible, and would it suffice to expose solve_iter and solve_iter_done, s.t. they can be called from python.
Or is there a better way? So far I tried from pyscipopt's side, but without success.

Any help would be very much appreciated!

Best,
Lovis

[AntoinePrv]

It sounds that you are getting into the same problem as us, which is that we want to iteratively go from one node to the next (in Branching.step()), while SCIP relies on a branching rule callback which execution we do not control.

Our solution is currently in these solve_iter methods that pauses SCIP every time SCIP call our Branch-rule.
This is subject to changes, as it will need to be adapted for other environments, so I would prefer not exposing it to Python.
However, you can still use it by reusing our ecole.dynamics.BranchingDynamics, which do just that.

model = ...
# Put model on the first branchrule call
dyn = ecole.dynamics.BranchingDynamics()
_, done = dyn.reset_dynamics(model)
# keep using Model

The downside (I don't know if it applies for you) you may need to finish solving the model with step_dynamics, and therefore having to provide your own branching variables.

We would like to extend on this, to let environment developpers more easily customize where SCIP should pause during solving.
As for SCIPstartProbing, I'm not sure what it does.

[AntoinePrv]

There is small discrepancy between the doc and the latest version on conda, but nothing much. We do keep the conda recipe up to date, right now v0.4.5. You can update with

conda update -c conda-forge -c scipopt ecole

One gotcha with our doc, is https://doc.ecole.ai/, redirects to https://doc.ecole.ai/master/index.html which is the doc generated in master.
The latest doc for version v0.4 is at https://doc.ecole.ai/v0.4.x/index.html. Ideally we should redirect to the latest version, not master, but we would need to automate it.

[LovisAnderson]

I have another question regarding BranchingDynamics.reset_dynamics as it has side effects that I have not expected. When I call reset_dynamics(model), the bounds of a variable in my model change. The code snippet at the bottom leads to the printouts:
Before reset_dynamics y(5): lower bound: -0.0, upper bound: 1.0
After reset_dynamics y(5): lower bound: -0.0, upper bound: 0.0
I do not think the bound should change here, especially since for the optimal solution holds y(5)=1. Have you observed similar behavior? I assume this would also be a problem for your feature extractor, as it probably extracts these bounds. A wild guess from my side would be, that branching on y(5) is already initialized somehow.

Any help, as before, is greatly appreciated! I attached a complete example script minimal_example.zip

## Disabling presolve to make sure bound changes are not caused by presolve
scip_parameters = {'presolving/maxrestarts': 0,  'presolving/maxrounds': 0}

model_pyscipopt = gcp_low()  # Initializing a pyscipopt model
model_pyscipopt.setParams(scip_parameters)
var = model_pyscipopt.getVars()[80]  # variable for which bounds unexpectedly change
model = ecole.scip.Model.from_pyscipopt(model_pyscipopt)
print(f'Before reset_dynamics {var.name}: lower bound: {var.getLbGlobal()}, upper bound: {var.getUbGlobal()}')
dyn = BranchingDynamics()
done, _ = dyn.reset_dynamics(model)
model_pyscipopt = model.as_pyscipopt()
print(f'After reset_dynamics {var.name}: lower bound: {var.getLbGlobal()}, upper bound: {var.getUbGlobal()}')```

[AntoinePrv]

BranchingDynamics.reset_dynamics should do nothing more than:

• Adding the "ReverseControl" branch rule;
• Call SCIPSolve
• Extract branching candidates

Could this come from SCIP presolving cuts that are run in SCIPSolve before getting to the root node?

I do not think the bound should change here, especially since for the optimal solution holds y(5)=1

Have you tried in your code (say from line 60) optimizing using pyscipopt only, and check that this assumptions holds for the optimal solution given by SCIP? If not there may be something there.

[LovisAnderson]

Thanks for the quick reply, it got me a bit closer. I before have only checked the bounds after presolve, where they did not change. Now, I optimized using only pyscipopt and the bounds have changed and do not match the solution value (see bottom). I will therefore continue looking on SCIP side for the error. Thanks!

For the sake of comprehensiveness, here is what I added after creating the pyscipopt model

model_pyscipopt.optimize()
print(f'After optimizing. {var.name}: lower bound: {var.getLbGlobal()}, upper bound: {var.getUbGlobal()}')
print(f'Best solution value for {var.name} {model_pyscipopt.getSolVal(model_pyscipopt.getBestSol(), var)}')

This leads to printing

After optimizing. y(5): lower bound: -0.0, upper bound: 0.0
Best solution value for y(5) 1.0

To me this is a contradiction. As ecole is not yet involved here, I will bring this up with SCIP.

[LovisAnderson]

Just for the interested reader, the reason the bounds seem to contradict the solution, is that var.getUbGlobal() gets the bound of the transformed variable. In my example the bounds of the transformed variable t_y(5) are set to 0 somewhere in solving stage.
The return of var.getUbGlobal() is a bit counterintuitive, especially as model_pyscipopt.getSolVal(model_pyscipopt.getBestSol(), model_pyscipopt.getTransformedVar(var)) returns the solution value of the original variable y(5) (which is 1 instead of 0 for the transformed var t_y(5)).