[Coin-ipopt] Problem using lapackpp and IPOpt

[Sonia Singhal]

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


On 12/16/06, Steven Dirkse <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/ipopt/attachments/20061218/8b6dac0b/attachment.html