Use configuration's driver to instantiate Solver

MiniZinc / mzn-bench

A framework to performing benchmark testing on MiniZinc models, solvers, and/or the compiler itself.

https://www.minizinc.org

5 stars 5 forks source link

Use configuration's driver to instantiate Solver #16

Closed hbierlee closed 3 years ago

hbierlee commented 3 years ago

Otherwise, the default driver (on the user's PATH) might not have that particular solver configuration.

I'm not 100% sure how to solve this except setting the default driver for each instance. The load function does not support a driver argument.

Dekker1 commented 3 years ago

Yes, I believe you are right that this is necessary. This problem likely originates from when I changed the system to not always send the full configuration in the environmental variable.

There is two things that I'm left wondering:

Should we set the default driver in a deserialisation function? I probably would prefer that there just is a requirement to set it beforehand.
Are we actually using the Driver system correctly to begin with? Just having a quick look I don't see its usage in when running the actual instances. That would be a big problem to begin with and then things would be broken even after the correct solver is selected.

hbierlee commented 3 years ago

To the first problem, the deserialisation function is a weird place, but we do have to account for the correct driver for each instance, because different instances could require different drivers. The user can't select just the correct one from the schedule.py, because there's not one correct one. Although perhaps we could searialize the Solver itself, so it becomes independant of the driver?
To the second problem, I see just see instance = minizinc.Instance(config.solver, minizinc.Model(model), driver). So it's first used to create the Solver object and then the Instance object. I guess both fundamentally need a driver, right?

hbierlee commented 3 years ago

Oh wait, I see now that you are probably right that we're not done yet, because on my system where my PATH's minizinc is different from my selected driver, it's using both now:

DEBUG:minizinc:CLIDriver:run -> command: "/usr/bin/minizinc --allow-multiple-assignments --version", timeout None
DEBUG:minizinc:CLIDriver:run -> command: "/home/hbierlee/Projects/libminizinc/release --allow-multiple-assignments --version", timeout None

Dekker1 commented 3 years ago

No, I think you are right. We do run using the right version of MiniZinc. The initial use of the other MiniZinc is merely to initial the MiniZinc Package, this will always use the version on the PATH. You then use set_default to change it.

Dekker1 commented 3 years ago

Okay, so it look like you are right that this is the only real solution that currently works. There is a remaining problem that if one configuration uses the system default and another is set explicitly, then by setting default, it would be unable to find the system default.

I'll add a quick fix for this and then merge that back

Dekker1 commented 3 years ago

Hey! I think I found a better workaround (#17). Could you give that one a quick try? Then I'll merge that into the repository