Thanks Matt!
It's exactly -6 the reason for failure.
Now I rerun with your workaround and see if the results are reasonable.
I also support your two questions to Steven.
Ciao!
mario
On 15-Oct-11 17:24, Matt wrote:
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
--
Ing. Mario Valle
Data Analysis and Visualization Group | http://www.cscs.ch/~mvalle
Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60
v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82
_______________________________________________
NLopt-discuss mailing list
[email protected]
http://ab-initio.mit.edu/cgi-bin/mailman/listinfo/nlopt-discuss
