[Coin-ipopt] Problem using lapackpp and IPOpt

[Andreas Waechter]

Hi Steve and Sonia,

I don't think any of us Ipopt developers is purposely changing the 
exception settings, certainly not in the code; what you describe sounds 
wrong, we don't want any exceptions (and we check for NaN explicitly in 
our code).

Maybe it has to do with the compiler flags?  I have to admit that I use 
the MSDS only if I really have to, and I don't know what options are 
really set in the project files that are in the Ipopt distribution.

Sonia, did you create the Ipopt project file from scratch (since you are 
not using the Fortran Lapack)?  Are there some choices one can make that 
have an influence on the excpetions?

Cheers

Andreas

On Mon, 18 Dec 2006, Steven Dirkse wrote:

> Sonia Singhal wrote:
>> Hi,
>>  Thanks for this info. I set the cw to the one in which my program was 
>> running properly.
>> Apparently, IPOpt has just the INEXACT flag on, whereas LAPACKPP has all 
>> the flags you mentioned on.
>>  If I turn on all the flags, it doesnt crash in the lapackpp function 
>> calls.
>> But I was wondering if this is ok ? If there was an underflow (or 
>> zerodivide, etc) in the calculations, doesnt it mean something went wrong 
>> in the calculations? Even though I am getting the right answer.
>>  Thanks,
>> ~ sonia 
>
> Interesting that your IPOPT runs with only the INEXACT exception masked.  I'd 
> like to know if and why they expect DENORMAL and UNDERFLOW exceptions to be 
> unmasked.
>
> In general, you can hope that code developers set the exception mask for a 
> reason.  For example, if they want to get +/- infinity when overflow occurs 
> (i.e. their code is written to work with these values) they can just mask 
> OVERFLOW exceptions.  If they don't expect to get reasonable results when 
> working with infinity, they might not mask OVERFLOW.  So I'd say only the 
> code developers (or those reading the code carefully) can say what exceptions 
> ought to be masked.
>
> -Steve
>
>> On 12/16/06, *Steven Dirkse* <sdirkse at gams.com <mailto:sdirkse at gams.com>> 
>> wrote:
>> 
>>     Sonia Singhal wrote:
>>      > Hi,
>>      >
>>      > I am doing development in Microsoft Visual Studio 2003. I have been
>>      > using LAPACK through a C++ interface provided in lapackpp-2.5.0.
>>     I was
>>      > using it for solving linear system of equations and doing SVD. This
>>      > package provides the libs for lapack and blas which I used for
>>     compiling
>>      > their c++ interface package.
>>      > Recently I used IpOpt ( 3.2.3 ) version in the code to solve an
>>      > optimization problem. I havnt written the complete code yet, just
>>     made a
>>      > dummy optimization class just to see if I was able to link the
>>     entire
>>      > ipopt infrastructure with my existing code. I was able to compile 
>> and
>>      > run the Cpp Example given in the IPOpt distribution.
>>      > The problem is that my code crashes in the lapackpp's call to their
>>      > interface to SVD (dgesdd). It crashes giving a "floating point
>>      > underflow" error. This doesnt happen if I remove ipopt's libs and
>>     code.
>>      > I have posted this question on the lapackpp forum too. I am
>>     posting here
>>      > too just in case anyone has any idea of what the problem could be.
>>      >
>>      > Thanks,
>>      > ~ sonia
>>      >
>> 
>>     Sonia,
>> 
>>     Floating point underflow is a hardware exception that can be raised on
>>     most CPUs.  Typically this is masked, so when underflow occurs the
>>     result is stored as a denormal (if it isn't one already) if possible or
>>     silently flushed to zero.  I'd guess that LAPACK is expecting this
>>     setting.  Somehow running with the IPOPT code in there, this exception
>>     is unmasked and you LAPACK behaves differently.
>> 
>>     You can experiment with your code to see what the exception mask is
>>     when
>>     it works and when it aborts.  Here is a snippet of code to get you
>>     started:
>> 
>>     #if defined(_WIN32)
>>     {
>>       unsigned int cw;
>> 
>>       cw = _control87(0,0);
>>       if (cw & _EM_INVALID   ) ADD2MASK(EX_INVALIDOP );
>>       if (cw & _EM_DENORMAL  ) ADD2MASK(EX_DENORMAL  );
>>       if (cw & _EM_ZERODIVIDE) ADD2MASK(EX_ZERODIVIDE);
>>       if (cw & _EM_OVERFLOW  ) ADD2MASK(EX_OVERFLOW  );
>>       if (cw & _EM_UNDERFLOW ) ADD2MASK(EX_UNDERFLOW );
>>       if (cw & _EM_INEXACT   ) ADD2MASK(EX_PRECISION );
>>     }
>> 
>>     I would google _control87 for more info.  FYI, ADD2MASK is a macro of
>>     mine, but _EM_INVALID are defined by some system headers.  If you
>>     replace ADD2MASK by some print statements you should see what the
>>     mask is.
>> 
>>     -Steve
>> 
>> 
>
>
> -- 
> Steven Dirkse, Ph.D.    GAMS Development Corporation
> 1217 Potomac St. NW             Washington DC  20007
> Voice: (202)342-0180              Fax: (202)342-0181
> mailto:sdirkse at gams.com          http://www.gams.com
> _______________________________________________
> Coin-ipopt mailing list
> Coin-ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/coin-ipopt
>