Originally posted by: EdKlotz
>
> Hi
> Do you know how to do debugging in CPLEX IDE studio.Because currently
> i am getting unreliable values for some constraints only for some conditions.
> So my idea is to stop the code each time and
> check what are the values pickup by the constrains.
>
> Do you have any good documentation how to do debugging in CPLEX studio
>>>>>>>
Here are a few general debugging tips regarding the OPL/CPLEX IDE that I gathered from a thread I was involved in on another list.
debugging involves three fundamental tasks.
1) Figuring out OPL error messages that relate to individual modeling language statements. Since the OPL IDE embraced the Eclipse style, the error message handling has become much easier to use. The error messages are more precise and easier to diagnose than they used to be. Still, sometimes that is not enough. I find that systematically commenting out portions of the statements that get the error message
often helps isolate the source of the error message. Similarly, try commenting out large segments of the modeling statements that aren't involved in the problem.
2. Your OPL model doesn't get any syntax errors, but the optimization results on your model are unexpected in some way, or you just want to confirm that your model is the one you intended. In this case, my comments about interactive CPLEX in my previous post on this thread still apply. OPL can export an LP file that you can use
to examine the model (from the IDE select Language->Run->Export format). For starters, use a small dataset, export the LP file, then
have a look at it and make sure you don't see any obvious mismatches between the exported model and one you intended (e.g. set covering constraints instead of set packing constraints appear in the model). On larger instances, read the LP file into interactive CPLEX and make use of the summary statistics it provides. Here's some sample output:
Problem name: /ilog/models/lp/all/pilots.mps.gz
Variables : 3652 [Nneg: 2320, Fix: 203, Box: 1040,
Other: 89]
Objective nonzeros : 53
Linear constraints : 1441
Less: 1191, Greater: 17, Equal: 233 Nonzeros : 43167
RHS nonzeros : 282
Variables : Min LB: 0.000000 Max UB: 1372.000
Objective nonzeros : Min : 0.002430000 Max : 0.02623900
Linear constraints :
Nonzeros : Min : 1.000000e-06 Max : 145.6000
RHS nonzeros : Min : 0.0005000000 Max : 6000.000
You can use this to verify that the model is as intended. For example, if you know that your model is not supposed to have any >= constraints, the 17 >= constraints in the above output would merit investigation. Or, if you know that some matrix coefficients are supposed to be large than 1000, the fact that the maximum matrix
coefficient is listed as 145.6 would raise a red flag.
Note that you can get a lot of this info from the Statistics tab in the OPL IDE as
well.
3) Your model is error free and the model appears as intended, but performance is slower than expected or consumes more memory. In this case, make use of the various logs available to you from the OPL IDE. For example, the OPL IDE profiler
provides info about time and memory consumption of the individual steps OPL takes.
This can help you isolate a modeling language statement that consumes too much memory and time (for example, one that treats a sparse dataset as a dense one).
>>>>>>>
And here was a subsequent post from another OPL user:
>>>>>>>>
To add a few things I find useful, assuming you're past the point of dealing with syntax errors ...
1) I virtually always construct a trivial test case as I'm defining the input variables. To start out, zero out anything that can be zeroed out and make input sets and arrays as small as possible. For example if you have input data that's iterated by state, only define data for, say, New York and California (they're the only states that really matter anyway, right?). If the data will eventually be coming from Excel or a database, you can just set values for this trivial test case right in the .dat file. I try to make this test case small enough that I can hand compute what will be generated by each model element.
2) If the trivial test case doesn't solve as expected, you can get info on the constraints generated by the OPL code right in the OPL IDE by naming any constraints of interest; i.e. just put a name and a colon (e.g. "ct_ImportantStates:") before a constraint and details on that constraint will be produced in the "Problem Browser" tab. Seeing details on the final set of constraints formed from the interaction of various iterators can really help in the debug process and is easy to get, since you're still in the OPL IDE.
3) As Ed suggested, don't be shy about commenting out constraints until you get to a reduced model that's feasible and whose result you understand. Then add constraints back into the model one at a time, checking the results as you add constraints.
>>>>>>>
And one more:
>>>>>>
For many models, especially practical ones involving minimizing costs or maximizing profits, you know of an obvious feasible solution. It may be horribly expensive, but it's feasible. So, test your model by fixing the variables to that feasible solution. The resulting fixed model had better be feasible. If it's infeasible, than at least one constraint is not specified as intended. OPL
then allows you to access CPLEX's conflict refiner, which identifies a minimal set of constraints and bounds involved in the infeasibility, and at least one of those constraints is not what you intended.
>>>>>>>>
#DecisionOptimization#MathematicalProgramming-General