[Ipopt] [ProbableSpam] Re: Why sometimes can solve, but sometimes can't solve with the same problem?

[Lewis I]

Hi Andreas,

But if the algorium performed identially, why the iteration numbers are different?
It also happenz in the example problems in Ipopt.(i used thw windows dll version)


Lewis




----- Original Message ----
From: Andreas Waechter <andreasw at watson.ibm.com>
To: Edson Cordeiro do Valle <edsoncv at enq.ufrgs.br>
Cc: ipopt mailing list <ipopt at list.coin-or.org>
Sent: Sat, March 27, 2010 2:36:56 AM
Subject: Re: [Ipopt] [ProbableSpam] Re:  Why sometimes can solve, but sometimes can't solve with  the same problem?

Hi Edson,

Yes, your observation is correct.  If you reorder the constraints, 
floating point values appear in the numerical computations in a different 
order; e.g., the linear system is given to the linear solver in a permuted 
way, and due to round-off the result returned by the linear solver will be 
different.  The differences are usually first rather small (last few 
significant digits), but over time can accumulate to a considerable 
deviation (depending on how ill-conditioned the problem is) and even make 
a difference between solving the problem and failure.

However, if the input to Ipopt is identical (same values and order of all 
variables, constraints, order and values of non-zero elements of 
matrices), the algorithm should perform identially in two different runs.

Regards

Andreas

On Fri, 26 Mar 2010, Edson Cordeiro do Valle wrote:

>        Hello All
>           Just a little contribution from my experience.
> As stated some time ago in this list, the order which constraints are
> being written can produce this behavior. I mean, if you have a set of 20
> constraints and write them in a different order, this behavior can
> happen, at least with Mumps solver. I don't know if it can happen with
> MA57.
> This happened to me some time ago where the software we were working
> with. In that software (RecoVR - http://www.vrtech.com.br/en_us/recovr)
> the equality constraints are written according to the order of a block
> diagram drawn by the user.
> I don't know if its your case, but it may give you a clue.
> Regards
>
>                                                  Edson C. do Valle
>                                                edsoncv at enq.ufrgs.br
>                                                   Skype: edson.cv
>
>
>>
>> Message: 4
>> Date: Fri, 26 Mar 2010 10:37:00 -0400 (EDT)
>> From: Andreas Waechter <andreasw at watson.ibm.com>
>> Subject: Re: [Ipopt] Why sometimes can solve, but sometimes can't
>>     solve with  the same problem?
>> To: Lewis I <lewis369lewis at yahoo.com>
>> Cc: ipopt at list.coin-or.org
>> Message-ID: <Pine.A41.4.61.1003261035200.430144 at bigopt.watson.ibm.com>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
>>
>> Hi Lewis,
>>
>> The Ipopt code is deterministic.  Potentially, the linear solver is not,
>> but I would think that MA57 is.  Maybe your BLAS library is not
>> deterministic?  Another thing to check is if there is uninitialized memory
>> usage, e.g., in your function evaluations, which might lead to different
>> outcomes (this could easily be checked with a memory checker like
>> valgrind).
>>
>> Andreas
>>
>> On Thu, 25 Mar 2010, Lewis I wrote:
>>
>>
>>> Hi Frank,
>>>
>>> I used the same options, same starting points and same obj function, and all other thing are the same too. (using  linear system solver ma57).
>>> (and  used the hessian approximation). But sometime ipopt can find the
>>> optimal point, but sometime can't.
>>>
>>> I found that ipopt provide different number of iteraitons for the same
>>> problem.
>>> So I guess there are "something" random that existed in the ipopt
>>> method.
>>> Does it relate to my question?
>>> Thx
>>>
>>> Lewis
>>>
>>>
>>>
>>> ________________________________
>>> From: Frank E. Curtis <frank.e.curtis at gmail.com>
>>> To: Lewis I <lewis369lewis at yahoo.com>
>>> Cc: ipopt at list.coin-or.org
>>> Sent: Fri, March 26, 2010 5:08:23 AM
>>> Subject: Re: [Ipopt] Why sometimes can solve, but sometimes can't solve with  the same problem?
>>>
>>>
>>> Hi Lewis,
>>>
>>> I suspect you'll need to answer a few questions before anyone can help you figure out what's really going on here.
>>>
>>> 1.) Naturally, if, say, your function evaluations involve random quantities, than the results can differ from run to run.  (I'm guessing that's not your case, though.)
>>> 2.) If you are changing any of the options, then the results can certainly vary, even for the same problem.
>>> 3.) If you are running different versions of Ipopt, or if you're running even the same version on different platforms, things can change.
>>>
>>> If it's not any of these basic things, we'd probably need to know more about your problem, the options you're using (including the linear system solver), etc.
>>>
>>> On Thu, Mar 25, 2010 at 5:00 PM, Lewis I <lewis369lewis at yahoo.com> wrote:
>>>
>>>
>>>> Dear all,
>>>>
>>>>
>>>>> Why ipopt sometimes can solve, but sometimes can't solve with the same problem?
>>>>> And the number of iteration are different too.why?
>>>>>
>>>>> Regards,
>>>>> Lewis
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> _______________________________________________
>>>>> Ipopt mailing list
>>>>>
>>>> Ipopt at list.coin-or.org
>>>> http://list.coin-or.org/mailman/listinfo/ipopt
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Ipopt mailing list
>> Ipopt at list.coin-or.org
>> http://list.coin-or.org/mailman/listinfo/ipopt
>>
>>
>> End of Ipopt Digest, Vol 63, Issue 11
>> *************************************
>>
>
> _______________________________________________
> Ipopt mailing list
> Ipopt at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/ipopt
>

_______________________________________________
Ipopt mailing list
Ipopt at list.coin-or.org
http://list.coin-or.org/mailman/listinfo/ipopt