Originally posted by: SystemAdmin

Hi everybody,

I have an iterative solution method where in each iteration invokes IloCPlex::Solve() to solve of a problem. The problem makes use of the same cplex object and modifies the objective function.
The problem works fine in Debug mode but of course a bit slow.
When I switch to the release mode, in VS2010, my code crashes in the second iteration of invoking solve() with the following message:
---
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
---

Again if I go step by step (F10) then it invokes and passes from the solve(), successfully.

Anybody has an idea what is going on here?
Any comment is highly apreciated.

kind regards,
Shahin
#DecisionOptimization
#MathematicalProgramming-General

Originally posted by: SystemAdmin

Maybe this strange behavior is caused by parallelism. What happens if you set the "threads" parameter of CPLEX to 1?

Can you post the stack trace for the crash? You will probably see not much (because the internal CPLEX function names are stripped), but maybe we have luck and some public CPLEX method appears close to the top of the stack trace.
Tobias
#DecisionOptimization
#MathematicalProgramming-General

Originally posted by: SystemAdmin

Tobias, thanks for your attention. Setting threads to 1 does not solve the problem, I have tried it before.
In the release mode while debugging I can pass the solve as mentioned earlier and can get the stack of calls as follows:

before solve():

>      circ-hlp-capacity-decomp-lrbb.exe!Oracle::Solve(

const 

double * uVector, 

double & fValue, 

double * sgVector, std::vector<double,std::allocator<double> > & xVector)  Line 923    C++ circ-hlp-capacity-decomp-lrbb.exe!CSubgradient::subgradient()  Line 92      C++ circ-hlp-capacity-decomp-lrbb.exe!main(

int argc, 

char * * argv)  Line 65  C++ circ-hlp-capacity-decomp-lrbb.exe!__tmainCRTStartup()  Line 582 + 0x17 bytes        C kernel32.dll!7c817077() [Frames below may be incorrect and/or missing, no symbols loaded 

for kernel32.dll]

after solve():

> circ-hlp-capacity-decomp-lrbb.exe!Oracle::Solve(

const 

double * uVector, 

double & fValue, 

double * sgVector, std::vector<double,std::allocator<double> > & xVector)  Line 924    C++ circ-hlp-capacity-decomp-lrbb.exe!CSubgradient::subgradient()  Line 92      C++ circ-hlp-capacity-decomp-lrbb.exe!main(

int argc, 

char * * argv)  Line 65  C++ circ-hlp-capacity-decomp-lrbb.exe!__tmainCRTStartup()  Line 582 + 0x17 bytes        C kernel32.dll!7c817077() [Frames below may be incorrect and/or missing, no symbols loaded 

for kernel32.dll]

seems quite similar.

if I let it run without completely I am not sure know how to catch any info about the stack.
#DecisionOptimization
#MathematicalProgramming-General

Originally posted by: SystemAdmin

I export the lp file both in release with steps and also release with normal run.
a part of the objective in the step-wise run is :
- 7.09154956979319e-7 y(0)(6)#915 - 3.54577478489659e-7 y(3)(8)#944

while when I compile and run the exe in release mode and print the expression in the console I see the following:

1.#QNAN * y[0][6] + 1.#QNAN * y[3][8]

also when I open the lp file I get

\Problem name: IloCplex   Minimize obj: ? z(0)(1)(0)#10 End

while the coeffs of this variable is 12500000 in the earlier lp file.

In the debug mode every thing is fine no matter I go stepwise or single run.
#DecisionOptimization
#MathematicalProgramming-General

Originally posted by: SystemAdmin

Interesting, so in release mode you produce some NANs while in debug mode you don't. Are you sure that you are compiling exactly the same code? Can you check/verify that you feed the exact same data to CPLEX in both cases?
It might also be helpful to turn on parameter DataCheck to have CPLEX check all data passed to it and catch these NANs as early as possible.
#DecisionOptimization
#MathematicalProgramming-General

Originally posted by: SystemAdmin

Hi Daniel

I am quite sure that that every thing is the same. I even hard-coded some input fine etc to avoid any thin uncontrollable.

I will check again however and will also test the datacheck param you mentioned. it will just take a while (few hours to 1-2 days)until I get back.
#DecisionOptimization
#MathematicalProgramming-General

Originally posted by: SystemAdmin

tried. DataCheck does not provide any more info.
There is no error code only a message saying to contact the ....

As also said earlier, if I go stepwise it works fine.
I also changed the scale of data. now there is no NAN in the lp file but still solver goes crazy.
#DecisionOptimization
#MathematicalProgramming-General

Originally posted by: SystemAdmin

some progress but...
when I change the run-time library to Multi-threaded Debug DLL (/MDd) in release mode., it words but again this is debug mode and very slow.
#DecisionOptimization
#MathematicalProgramming-General

Originally posted by: SystemAdmin

Maybe, you are doing calculations in double precision that lead to numbers that are zero or close to zero, and then you divide by these numbers? Then, it could happen that in debug compiles the doubles are intermediately stored in memory (and thereby truncated to 64 bit) while in optimized mode the whole calculation is done in a register (thus using 80 bit). This would explain the differences between debug and optimized mode, and dividing by zero or very small numbers gives the NANs or the crazy solver behavior.
#DecisionOptimization
#MathematicalProgramming-General

Originally posted by: SystemAdmin

Thank you very much.
#DecisionOptimization
#MathematicalProgramming-General