Variable data attribute not accessible through Model.getVars()

[networds]

In #268 the .data attribute was added to the Variable class, but this attribute is not accessible via Model.getVars(). See the following MWE:

from pyscipopt import Model, SCIP_RESULT

m = Model()

var1 = m.addVar(vtype = 'C', obj = 2, name='foo')
var1.data = 'foobar'

print(var1.data) # works just fine

print("----")

for var in m.getVars():
    print(var.name)
    print(var.data) # returns "None"

actual output:

foobar
----
foo
None

expected output:

foobar
----
foo
foobar

Note that similar issues might exist for the other classes adapted in #268

[fserra]

yes, the problem here is that every time you get a variable from SCIP, PySCIPOpt creates a new Variable object. Some time ago we discussed how to keep a single variable object but we didn't decide on anything. I guess now is the time for talking again about this.

Since variables have vardata (internally in SCIP) I guess one solution would be to store the python Variable in the vardata.
However, the other objects do not have a data, so then one would need to remember them on the python side.

I guess a more homogeneous solution would be to store a mapping between the SCIP data and the python data. @mattmilten any thoughts?

[mattmilten]

I am definitely in favor of storing a mapping in Python. This could lead to a more expensive lookup whenever you want to get the data, though.

Another solution is to store the variables (including their data) inside the model data:

m.data = vars

Then, when you want to retrieve them you don't need to call getVars() but simply access them in m.data.

[fserra]

the problem with storing it in m.data is what happens when you read a problem from a file. There was an issue about this, but can't find it anymore

[mattmilten]

I just tested reading in a model and storing something in a variable and then storing all variables in the model data. All works fine.

[networds]

If it is stored in m.data one would have to take care to manually delete the info in m.data once a variable object is destructed , but that shouldn't be a problem

[mattmilten]

Well, if you store the variables in m.data they will not be destroyed, because there is always a reference left.

It might happen, that for some reason the SCIP_VAR pointer does not correspond to an existing variable anymore, though.

[networds]

yes, the problem here is that every time you get a variable from SCIP, PySCIPOpt creates a new Variable object. Some time ago we discussed how to keep a single variable object but we didn't decide on anything. I guess now is the time for talking again about this.

I belive the same thing happens when I try to store an attribute in a Node (e.g. node.data and then try to access it via

node = model.getCurrentNode()
print(node.data)

?
A new Node object is created and thus I lose access to the attributes?

[mattmilten]

Yes, unfortunately this is currently the case. I understand that with Nodes my work around from above does not make much sense either. We need to make these objects persistent.

[networds]

Would using a constraint handler as outlined in the SCIP FAQ work for now in PySCIPOpt or are there any further pitfalls?

[fserra]

that should work. I translated the coloring example of SCIP to pyscipopt some time ago. You can have a look in the branch use-probdata-to-store-model the file tests/test_coloring.py. However, do not expect it to work with the current pyscipopt.

[mattmilten]

I don't know what you are trying to implement. In general a constraint handler should work because the entire constraint handler is stored within SCIP itself using the constraint handler data. This should be the case for all the plugins. I suppose we really need to implement this functionality also for the simpler objects, like Node or Variable.