Originally posted by: glebB

The attached model is reported infeasible when solved in a linked application with thread count 4, and feasible otherwise. It is created with C++ Concert and solved directly. Actually, the virtual machine has only 3 CPU cores allowed.

I failed to reproduce this in the interactive optimizer on the exported file. Using 12.6.2 under 64-bit Ubuntu Linux.

I'm trying to reproduce with the 12.6.2 interactive, but this model is taking awhile to solve.  Can you reproduce the behavior consistently from the application?  Can you reproduce with a smaller model?

If I understand correctly, you get this behavior when the global thread count parameter is set to 4, but not when it is set to 1.  Is that correct?  Are any other parameters being set from within the application?  If so, can you attach the parameter file?  Are you using any callbacks (or something that can affect the behavior dynamically)?

Originally posted by: glebB

From the Interactive Optimizer, or with ilolpex2.cpp modified to change thread count, this model is usually solved in a minute with nThreads >= 3. For 1 or 2 threads it really takes half an hour or so. (Such a great variability! The model has a good-conditioned matrix I believe). I tried more with that version of ilolpex2.cpp but could not reproduce.

No I have not tried to reduce the example. Yes from the application the behavior is consistent, either using the CPLEX examples' CFLAGS or not, debug or release. No other parameters changed, no callbacks. I notice that when called from the application with 4 threads, Presolve finishes with 4999 columns, while with other N threads it is sometimes 4995 or 5007.

Attaching the source archive. The cursed command is

     mzn-cplex --verbose -p4  amaze_2012-03-09.fzn

which results in infeasibility report in 63 seconds. With -p1 there is an optimum in 78 sec (i7-4770 in XUbuntu in Virtualbox). The same happens with CPLEX 12.6.1. The executable was compiled under XUbuntu 15.04 with gcc 4.9.2 64-bit from the build subdirectory by typing ../BUILD.sh. You can set HAS_GUROBI to FALSE in CMakeLists.txt.

I was able to reproduce this.  I'll get back to you after investigating.