On 10/11/2011 06:35, Mario Valle wrote:
I'm happily using NLopt for a computational evolution application I'm
developing. But now for a specific dataset it fails with "nlopt failure"
exception and I'm at a loss to understand why NLopt fails.
I'm using NLopt 2.2.2 on Linux through the C++ interface. The method is
nlopt::LD_LBFGS. My function returns reasonable values and the variables
seems ok at time of crash.
I disabled my try/catch blocks hoping to see where opt.optimize()
crashes, but the debugger always show I'm in mythrow().
Any suggestion on how to debug this?
To compare results with an old application I'm forced to stay with
LBFGS. Today I will upgrade to 2.2.4 and check my gradient function.
Beside these, I have no more ideas on what to check.
Thanks for your help!
mario
I've had a similar problem before with nlopt::LD_LBFGS ("the low-storage
BFGS algorithm written by Prof. Ladislav Luksan") and managed to
implement a workaround to provide more information.
Note that the source code is in "luksan" directory.
The file you're interested in is "plis.c".
Scroll down to the very end and you'll see this:
switch (iterm) {
case 1: return NLOPT_XTOL_REACHED;
case 2: return NLOPT_FTOL_REACHED;
case 3: return NLOPT_MINF_MAX_REACHED;
case 4: return NLOPT_SUCCESS; /* gradient tolerance reached */
case 6: return NLOPT_SUCCESS;
case 12: case 13: return NLOPT_MAXEVAL_REACHED;
case 100: return NLOPT_MAXTIME_REACHED;
case -999: return NLOPT_FORCED_STOP;
default: return NLOPT_FAILURE;
}
It follows that you have to track down what's the value of "iterm" to
see what was the cause of NLOPT_FAILURE.
The way I did that was to printf-it-out just before the switch.
You have to add #include <stdio.h> in "plis.c" (just place it where the
other includes are).
Then, replace the above-mentioned switch part in the source code with
the following part and rebuild the library:
printf("iterm = %d \n", iterm);
switch (iterm) {
case 1: return NLOPT_XTOL_REACHED;
case 2: return NLOPT_FTOL_REACHED;
case 3: return NLOPT_MINF_MAX_REACHED;
case 4: return NLOPT_SUCCESS; /* gradient tolerance reached */
case 6: return NLOPT_SUCCESS;
case 12: case 13: return NLOPT_MAXEVAL_REACHED;
case 100: return NLOPT_MAXTIME_REACHED;
case -999: return NLOPT_FORCED_STOP;
case -6: return NLOPT_SUCCESS; // MAXIMUM NUMBER OF EXTRAPOLATIONS OR
INTERPOLATIONS REACHED
default: return NLOPT_FAILURE;
}
You'll notice a new line other than printf -- this is because in my
case, the problem was -6 (it might be something else in yours!) and I
didn't deem "MAXIMUM NUMBER OF EXTRAPOLATIONS OR INTERPOLATIONS REACHED"
fatal enough to return a NLOPT_FAILURE; my workaround was to return
NLOPT_SUCCESS instead -- it almost never showed up for my objective
function before, so it was easy to track its cause.
Incidentally, two questions to Steven:
1. Is there a reason the above is deemed to be an error? Isn't it
similar to simply having tolerance bounded by available (finite)
numerical precision, conceptually making case 4 similar to case -6 (that
was also part of a rationale for me to work around it like that)?
2. Would it be possible to report iterm along with NLOPT_failure
(perhaps using something along the errno mechanism) so that the client
code has more information than simply "something went wrong"?
Best,
Matt
_______________________________________________
NLopt-discuss mailing list
[email protected]
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/nlopt-discuss
