Originally posted by: walterOR

I am using the conflict refiner through docplex in Python. Given an infeasible model, the code looks roughly like this:

from docplex.mp.conflict_refiner import ConflictRefiner as MipConflictRefiner
conflict = MipConflictRefiner().refine_conflict(my_model, log_output=log_output)

On several occasions, I have noticed that the conflict refiner is running really slow. It is usually much faster to export the model as an LP file and using the conflict refiner through the interactive optimizer. Are there any parameters to get the same behavior in both cases? For example, is there a way to set the number of threads? (I tried just passing "threads" as a parameter but that didn't work) What can I do with the preferences and groups attributes? Does it help to add constraints that are somehow related to the same group?

I also noticed that the log output looks very different. For example, if I run the conflict refiner through Python, I might start with a maximum number of members of 45k, but if I run the interactive optimizer, it is showing only 15k members. Not sure if that is just a different way of counting the conflicts or if there is more to this.

In general, I find that the documentation for this is lacking a lot of details. Would be great to enhance it a bit.

Originally posted by: p_couronne

I understand you noticed the docplex conflict refiner is slower than cplex interactive. Could you send a LP or SAV file for us to investigate?

Thanks in advance.

Originally posted by: walterOR

The attached ZIP file contains a model file (model.lp) a test file (test.py) that illustrates how I am using the conflict refiner with docplex and two logs:

log-cplex.txt (found a conflict after about 6500 seconds)

log-docplex.txt (I aborted this after about 3.5 hours since it was still far from finding a conflict)

You can also see in the log that the interactive optimizer starts with 16927 members, while the docplex conflict refiner starts with 44725 members.

I was running this on the same machine and it was not at all taking advantage of the available cores. It was only using 2-4 threads according to the task manager.

Originally posted by: p_couronne

Thanks to your data, we were able to reproduce the issue. The default behavior of the conflict refiner in DOcplex

is consistent with the CPLEX Python API, in that it considers all variable bounds (upper and lower), while CPLEX interactive does

not consider the bounds of binary variables (unless they are bound). We are working to see whether the DOcplex default can be changed, and

also to provide a workaround for you to get the same behavior as CPLEX interactive.

Originally posted by: walterOR

Thank you for getting back to me so quickly. Glad to hear that the example helped. A workaround would be great, while this is being looked at in more detail.

Originally posted by: p_couronne

The behavior of the DOcplex conflict refiner will be modified to replicate how CPLEX interactive works.

In the meantime, here is a workaround code which works with the latest version of Docplex (2.11.176 from Nov 6th)

and should also give you the same output as cplex interactive. On my machine it finds a conflict in 2000 seconds, starting with around 16k element

The main discrepancy  is about how binary variables are handled: DOcplex (along with all other apis) considers two variable bounds per variables,

as cplex interactive does not (except when the variables are bound).\

I also added a flag to drop infinite bounds or not (with True, you get exactly same behavior as interactive, starting at 16927, with False, it starts with even less).

Let me know if this works for you.

Originally posted by: walterOR

Thank you for assistance with this problem. The workaround is working perfectly.