Originally posted by: Perth2

I am using CPLEX with Java. In a column generation setting, I am solving an LP restricted master problem to find duals. However, I am observing a behavior of CPLEX that I do not have an explanation for.

I construct the model using IloLPMatrix, adding rows and columns. I then export the model to an .lp file to check and make sure it is correctly formulated. The original model (not the .lp file) is then solved through Java. I get a array of double containing the dual variable values for all the rows (constraints) from my IloLPMatrix object using the cplex.getDuals(lpMatrix) call.

However, these dual values (that is, the non-zero ones) do not correspond to the (non-zero) dual values found using this alternate method: I load (command "read") the exported .lp file into the interactive CPLEX optimiser and solve it (command "opt"), and query the dual values (command "display solution dual *").

The dual values differ by the two methods. Most dual values are the same, but some are different.

The log shows different solution methods (one dual simplex, one primal simplex). Also, I am setting a lot of IP-related parameters in CPLEX in the Java version of the problem (for later processing, e. g. IloCplex.Param.MIP.Tolerances.MIPGap to a higher value than default), but since the described phenomenon is occurring for an LP relaxed version of the problem (relaxed using CPLEX conversion to float), I would not expect that the IP related parameters have any effect.

Since it is the exact same model (in this sense), I would expect the exact same dual values. Would you have any idea why I am not?

Could it have anything to do with multiple optima? That one method finds one optimum, and the other another one?

But then, why does CPLEX choose different methods to solving the exact same problem?

Or is the .lp file format not conveing all information?

(I have not uploaded the .lp file since it is 16 MB.)

First, if the two methods produce the same objective value, then in all likelihood the dual has multiple solutions (the primal has a degenerate optimum), and the two methods are finding different dual solutions. This can happen even if you use the same algorithm, particularly if the constraints appear in a different order in the respective solver instances.

Second, an LP file is okay for visual inspection, but to test the solution you should use a SAV file. The export to LP format and import from LP format operations (binary to ASCII coded to binary again) introduce small rounding/truncation errors that can sometimes cause significant differences in the results. The SAV format is binary, eliminating the conversion round trip.

Originally posted by: Perth2

Thanks, Paul. If it is necessary for me to have the exact same thing going on in the interactive optimizer as via Java, which way would be the best to go? Specify which method should be used to solve, and use an .sav file? Will that be sufficient?  

I'm not sure it's ever possible to make that an iron-clad guarantee, but using a SAV file would be essential, as would specifying all non-default parameter settings (which includes the solution algorithm). For the latter, you can have the Java program write out a parameter file (.PRM extension IIRC) and read that into the interactive solver.