[Ipopt] IpOpt code: Detereministic or Random across various runs?

Mon Dec 17 15:28:27 EST 2012

Thanks Stefan,

I tested the error proposed in the ticket and since I could reproduce it, I
applied the patch. Now it's gone.
Despite this, I still see the deviation in answers to the problem I have.
To clear the way this error is produced, I solve three  very similar
optimization problems in succession (say t=0, t=1 and t=2 problems). I run
this two times, and for each run, I provide Ipopt with the exact answer for
t=0. Since problems at t=1 and 2 are similar, it is expected that answers
are the same, but I see that at t=1 there is a deviation on the order of
1e-4 across the 2 runs and at t=2 it's on the order of 1e-3 (and this error
can propagate larger if i continue this)
As stated, despite this, Ipopt is giving me answers both of which respect
all (non-linear) constraints of the problem, so they are all correct
answers in this sense, although I expect ipopt to follow a determinism path
and arrive at the same correct answer from the same initial point every
time.

I will try to find the differences in the ipopt report of problems and post
them here if I could figure out the reason.

Alireza

On Mon, Dec 17, 2012 at 2:14 PM, Stefan Vigerske
<stefan at math.hu-berlin.de>wrote:

> Hi,
>
> you could also try setting the ipopt.print_level to a high value (like 12)
> and see where two runs that should have the same result start to have
> different behavior.
>
> Also have a look at this issue: https://projects.coin-or.org/**
> Ipopt/ticket/187 <https://projects.coin-or.org/Ipopt/ticket/187>
> This has been fixed with Ipopt 3.10.3, but if you use an older library,
> then you may want to check that your functions that return gradients do not
> report sparse vectors.
>
> Stefan
>
>
> On 12/17/2012 06:46 PM, AliReza Khoshgoftar Monfared wrote:
>
>> Hi,
>> I tried export OMP_NUM_THREADS1=1 and runnig matlab using the
>> "-singleCompThread" option.
>> It still seems like that I have distinct answers for the same problem with
>> the same initial point:(.  But monitoring "top", I can see that sometimes
>> I
>> have one MATLAB process that is always there and another that comes and
>> goes, I'll look into this again to make sure if its still using
>> multi-threading or not.
>> I'm trying to see if there is any MPI settings when building Ipopt or its
>> matlab interface.
>> There is also an mpisettings() function in matlab, but I don't see an
>> option for it to change matlab behavior, it only has a "deadlock detection
>> mode".
>>
>> Alireza
>>
>>
>> On Mon, Dec 17, 2012 at 12:31 PM, Vivek Periaraj
>> <vivek.periaraj at gmail.com>**wrote:
>>
>>  In CPLEX multi-threading environment, there are two modes - deterministic
>>> and opportunistic. In the deterministic mode, the algorithm would follow
>>> the same path between each identical runs, hence the solution vector
>>> would
>>> remain the same. In the other mode, this is not guaranteed. If you use
>>> MPI
>>> for this, then I guess you could manually enforce such similar
>>> deterministic behavior.
>>>
>>>
>>> Regards,
>>> Vivek.
>>>
>>> ----- Original Message -----
>>>
>>> From: "AliReza Khoshgoftar Monfared" <khoshgoftar at gmail.com>
>>> To: ipopt at list.coin-or.org, "jonathan hogg" <jonathan.hogg at stfc.ac.uk>,
>>> "vivek periaraj" <vivek.periaraj at gmail.com>
>>> Sent: Monday, December 17, 2012 10:32:34 PM
>>> Subject: Re: IpOpt code: Detereministic or Random across various runs?
>>>
>>>
>>>
>>>
>>> Thanks Vivek and Jonathan,
>>>
>>>
>>> I also suspect that this issue has something to do with MATLAB (or
>>> settings of BLAS and LAPACK).
>>>
>>> My original MATLAB code should be single-threaded, but I am suspicious
>>> that when I call Ipopt(), which uses the corresponding mex file, there
>>> might be multiple threads involved.
>>> Is there a way to force a single thread in MATLAB though?
>>>
>>>
>>> Alireza
>>>
>>>
>>>
>>>
>>>
>>> Might also be worth seeing if you can force everything to run
>>> single-threaded and seeing if that has any effect. Some parallel
>>> algorithms will produce different results on different runs, and even
>>> small changes in the descend direction can produce different results as
>>> you describe.
>>> Jonathan.
>>>
>>> On 15/12/12 11:52, Vivek Periaraj wrote:
>>>
>>>> Maybe the data structures interfaced from MATLAB to IPOPT are in
>>>>
>>> different orders in each run? Sometimes the order in which the variables
>>> are created affect the solution the algorithm converges to in the end.
>>> Especially true when multiple optimal solutions exists.
>>>
>>>>
>>>> Regards,
>>>> Vivek
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I have been trying to solve an optimization with Ipopt.
>>>>
>>>> I'm using the MATLAB interface of Ipopt, and my optimization problem is
>>>> a
>>>> not so complicated quadratic problem satisfying a number of distance
>>>> inequalities for some points.
>>>>
>>>> I have noticed that in different cases of my problem, whether it is
>>>>
>>> solved
>>>
>>>> (status 0), detected infeasible (status 2) or exceeded maximum
>>>> iterations
>>>> (status -2), even if I run the code with the exact same initial point
>>>> and
>>>> exact same options, I get results that are different.
>>>> Now, I know that my problem does not have a unique solution, e.g. in
>>>> case
>>>> of instances that are solved completely I get different results while
>>>> all
>>>> satisfy the constraints. But still, I expect ipopt to give
>>>> me similar results when I run it with similar conditions.
>>>>
>>>> Is there any option in Ipopt that accounts to randomness. Or is it a
>>>> behavior of MATLAB?
>>>>
>>>> I have noticed that building Ipopt with various versions of BLAS and
>>>>
>>> LAPACK
>>>
>>>> does not affect this in my case (I tried third party versions provided,
>>>>
>>> and
>>>
>>>> also ATLAS implementations of libraries in Liunx), but forcing MALTAB to
>>>> use different BLAS and LAPACK versions (through environment variables
>>>> BLAS_VERSION and LAPACK_VERSION) has an effect (although in no case, I
>>>>
>>> get
>>>
>>>> exactly similar results) .
>>>>
>>>> Has anybody else had such an experience with IpOpt? Should I change a
>>>> setting in Ipopt ot MATLAB?
>>>>
>>>> Thanks
>>>> ALireza
>>>>
>>>>
>>>> PS: If it helps, here is a summary of Ipopt options I have changed:
>>>>
>>>> ipopt.hessian_approximation = 'limited-memory';
>>>>
>>>>> ipopt.mu_strategy = 'adaptive'; > tols = [1e-6; Options.MaxR;
>>>>>
>>>> Options.MaxR]; > ipopt.tol = sum(tols); > ipopt.constr_viol_tol =
>>> tols(1);
>>>
>>>> ipopt.compl_inf_tol = tols(2); > ipopt.dual_inf_tol = tols(3); >
>>>>
>>> hessian_constant = 'yes'; > ipopt.warm_start_init_point = 'yes';
>>>
>>>> ______________________________**_________________
>>>> Ipopt mailing list
>>>> Ipopt at list.coin-or.org
>>>> http://list.coin-or.org/**mailman/listinfo/ipopt<http://list.coin-or.org/mailman/listinfo/ipopt>
>>>>
>>> --
>>> Scanned by iCritical.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Dec 14, 2012 at 7:11 PM, AliReza Khoshgoftar Monfared <
>>> khoshgoftar at gmail.com > wrote:
>>>
>>> <blockquote>
>>>
>>> Hi,
>>>
>>>
>>> I have been trying to solve an optimization with Ipopt.
>>>
>>>
>>> I'm using the MATLAB interface of Ipopt, and my optimization problem is a
>>> not so complicated quadratic problem satisfying a number of distance
>>> inequalities for some points.
>>>
>>>
>>> I have noticed that in different cases of my problem, whether it is
>>> solved
>>> (status 0), detected infeasible (status 2) or exceeded maximum iterations
>>> (status -2), even if I run the code with the exact same initial point and
>>> exact same options, I get results that are different.
>>> Now, I know that my problem does not have a unique solution, e.g. in case
>>> of instances that are solved completely I get different results while all
>>> satisfy the constraints. But still, I expect ipopt to give me similar
>>> results when I run it with similar conditions.
>>>
>>>
>>> Is there any option in Ipopt that accounts to randomness. Or is it a
>>> behavior of MATLAB?
>>>
>>>
>>> I have noticed that building Ipopt with various versions of BLAS and
>>> LAPACK does not affect this in my case (I tried third party versions
>>> provided, and also ATLAS implementations of libraries in Liunx), but
>>> forcing MALTAB to use different BLAS and LAPACK versions (through
>>> environment variables BLAS_VERSION and LAPACK_VERSION) has an effect
>>> (although in no case, I get exactly similar results) .
>>>
>>>
>>> Has anybody else had such an experience with IpOpt? Should I change a
>>> setting in Ipopt ot MATLAB?
>>>
>>>
>>> Thanks
>>> ALireza
>>>
>>>
>>>
>>>
>>> PS: If it helps, here is a summary of Ipopt options I have changed:
>>>
>>>
>>>
>>> <blockquote>
>>> ipopt.hessian_approximation = 'limited-memory';
>>> ipopt.mu_strategy = 'adaptive';
>>> tols = [1e-6; Options.MaxR; Options.MaxR];
>>> ipopt.tol = sum(tols);
>>> ipopt.constr_viol_tol = tols(1);
>>> ipopt.compl_inf_tol = tols(2);
>>> ipopt.dual_inf_tol = tols(3);
>>> hessian_constant = 'yes';
>>> ipopt.warm_start_init_point = 'yes';
>>> </blockquote>
>>>
>>> </blockquote>
>>>
>>>
>>
>>
>> ______________________________**_________________
>> Ipopt mailing list
>> Ipopt at list.coin-or.org
>> http://list.coin-or.org/**mailman/listinfo/ipopt<http://list.coin-or.org/mailman/listinfo/ipopt>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.coin-or.org/pipermail/ipopt/attachments/20121217/d5de303d/attachment-0001.html>