Closed informarte closed 2 years ago
To investigate this issue we will need the models and data files. It would be great if you would be able to actually create a minimal example of the issue.
yumi-dynamic is a 2021 MiniZinc challenge problem, so see https://www.minizinc.org/challenge2021/mznc2021_probs.tar.gz for all the files.
I am not the author of yumi-dynamic, so I think I would have a hard time to create a minimal example. As a software engineer, I would rather start by looking for use of uninitialized memory using a tool like Google's MemorySanitizer.
Although uninitialised memory might be the cause. The compiler also makes use of many unordered map structures that uses pointers as keys. It wouldn't be unlikely that these will be the issue when it comes to these types of ordering differences.
Currently in implementation MiniZinc is mostly deterministic, but I'm not sure if we can invest the time to guarantee that this is the case.
@Dekker1, the first diff looks to me like one variable turned is_defined_var
while the other lost this status, but maybe it's just an ordering problem. However, the second diff shows clearly that a variable lost the is_defined_var
status which, of course, affects solvers which consider this status.
I ran
10 times on Linux and I obtained three different FlatZinc outputs and these are the diffs to the most common version:
Occurred two times:
Both X_INTRODUCED1033 and X_INTRODUCED1034 could be functionally defined and, btw, X_INTRODUCED1032, too.
Occurred two times: