Originally posted by: SystemAdmin

[muhamedaga said:]

Hi All;

I am having difficulties replicating the interactive behaviour/ settings...

Here is the situation I have encountered several times

I run my MIPLP application  with all default settings, encounter problems. I  export the LP file  and read it  back to the interactive in order to see what's going on.

To my surprise, the interactive cplex solves the problem without much difficulty.

I tried exporting  explicitly setting defaults  (setdefaults), exporting and importing .prm files.


I am assuming that the the problem before the export and import are not exactly the same due to the conversions...

Still I am troubled by this. It would be great to be able to use the interactive in this way.

Please let me know if you have some suggestions.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[prubin said:]

This may be an indication that there is some numerical instability in your model.  Exporting and importing loses precision; in an unstable model, that could be the difference between one result and another.

Try relaxing some of the CPLEX parameters that control tolerances (such as EpRHS) and see if that makes a difference.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[muhamedaga said:]

Yes, you are right. I know that there numerical stability issues with this case, and that's what I am trying to resolve. EpRHS tolerance chjanges has helped me to get the two executions closer together..

#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

[jgregory said:]

When exporting a model to a file, we recommend using SAV format, which is a binary representation of what's in memory.  A SAV file has a much better chance of replicating behavior seen inside your application. 

LP format may amount to a perturbation in two ways, because the variables could be read back in a different order than found in the SAV format, and also because the ASCII representation of the data might not precisely match the 64-bit floating point.  It sounds like Paul and you are on the right track about ill-conditioning, and either of these perturbations might affect you.

If the reality you are modeling is indeed ill-posed then there may be nothing you can do about the ill-conditioning.  If the reality is stable, you probably will want to try to determine and correct the cause of such sensitivity that tolerances like EpRHS can even play a role.  Does your MIP involve big-M constraints?  My theme today seems to be Indicator Constraints, and it might be a worthwhile alternative formulation to consider.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: JimDan

I am bringing up a pretty old thread but I am facing a similar problem that will not go away...

I have a price and branch column generation application coded in C++ that uses Concert Libraries...

//Pricing Step
while(good column found){
IloColumn col...
Populate column
IloNumVarArray X.add(col,...)
cplex.solve();//Default Parameters for cplex
update dual values
find column
}
//End Pricing Step

//Convert variables to integer and solve
//Begin Branch Step
Convert IloNumVarArray X to Integer Type
cplex.exportModel("model.lp");
cplex.solve();//Default parameters for cplex

Now, as others in this and other threads have pointed out, the cplex.solve() step above takes forever...while if I go to the interactive optimizer and type:

cplex> read model.lp
cplex> optimize

the IP solves in a few seconds.

As some have pointed out, if I save/export the model as "model.sav" in lieu of "model.lp", I should expect the interactive optimizer to perform just as fast/follow the same sequence as does the cplex.solve() step from within the C++ application. Correct? I have not tried that step yet.

My question is, is there a way I can get the C++ application itself to perform as fast as the interactive optimizer, instead of having the interactive optimizer perform just as slow as the application?

On a related note, could it be that my price and branch application, at the beginning of the branching phase has an incoming LP basis before going through the IloConversion and cplex.solve() steps that somehow slows things down? Interactive Optimizer does not have any starting basis that I feed in and could this be the reason why the Interactive Optimizer runs faster? If both the interactive optimizer and the C++ application go through the exact MIP branching steps when the model is exported as "model.sav" what happens to the incoming LP basis of the C++ application before cplex.solve()? It appears to me that the incoming LP basis would contain some valuable information about variables that cplex.solve() could use. If cplex.solve() does indeed use this incoming LP basis, then unless I save this basis and feed it to the Interactive Optimizer, how will the two (Interactive Optimizer & the C++ application) follow the same steps in converging to the optimal solution?
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Cases where the Interactive Optimizer behaves differently than in an API are a mystery that I usually approach by process of elimination.

First, please do try exporting a model in SAV format rather than LP. That is the most exact representation of the model that was in memory within your program.

You can assure that an advanced start is not being used within your program, by setting the parameter AdvInd to 0.

Does your program contain a callback function? Callbacks can have an impact on what the solver does, in a way that can't always be replicated in the Interactive Optimizer.

In particular, I am wondering if Dynamic Search is being shut off (under the hood) within your program for some reason. You could try turning that off in the Interactive Optimizer via "set mip strategy search 1" and see if you get similarly bad performance in the Interactive solves.

With luck, results from these suggestions will either solve the mystery or else point the way toward further diagnosis.
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: JimDan

I do not have any callback functions that might be causing the optimization to slow down optimization "under the hood" in the C++ application. Unfortunately, I have experienced this problem in the past as well. Once, when I was on vacation, I had to train my "non-tech-savvy" boss to run a Concert application. I had him set IloCplex::Tilim to something like 12 hours or so and the guy had to keep checking ever so often to see if the process had completed as the CPLEX solution was needed before any onward processing could happen. When I was back I was immediately tasked with the job of making the application run faster because the "underlying business problem" was really not that hard and something for which you did not really need a PhD (his words). So, what I did was to have cplex.exportModel("model.lp"). This was then solved (through code) by the Interactive Optimizer (in less than 2 minutes!) which also generated a "solution.sol" xml file. I read back this xml file in my C++ code and everyone was happy.

Maybe that is the way to go...just do not use cplex.solve() at all, simply export the model to have it solved by the Interactive Optimizer and have your code read back the solution using an xml reader...
#CPLEXOptimizers
#DecisionOptimization

Originally posted by: SystemAdmin

Please see the earlier comment about the differences of SAV and LP formats. Could you please rerun your experiment using the SAV format? In this case, the interactive should really give the same performance (in your case the bad performance) as the cplex.solve() call from Concert. If this is the case, then exporting to LP had one or both of the following effects:

1. Exporting to LP and reading the model back permutes the columns of the model. A different permutation of the columns can have random effects on the solving performance (but of course not on the optimal objective value).

2. Exporting to LP may discard some digits of your floating point data. This may change the model in such a way that it is easier or harder to solve than the original model.

If using the SAV format does not give the same performance in interactive CPLEX as with cplex.solve() then something strange is going on that should be investigated.

Tobias
#CPLEXOptimizers
#DecisionOptimization