[Ipopt] about filter

[Ruhollah Tavakoli]

Andreas,

Lot of thanks for your commnets.

Cheers

RT




On Tue, May 26, 2009 at 7:44 AM, Andreas Waechter
<andreasw at watson.ibm.com>wrote:

> Hi RT,
>
> What is maximum number of entries in filter (a common value)? Is
>> essentially
>> action of filter function of maximum number of entries?
>>
>
> There is no maximal number of filter entries in the Ipopt implementation.
> It uses a std::list, which can get as long as it needs to.
>
> You also sent a message directly to me - in the future, please send those
> questions to the Ipopt mailing list, since others might want to know about
> the answer as well, and someone else might also be able to answer faster
> than me (I also have a day job, that sometimes limits the amount of time I
> have for answering messages here... :-) ).
>
> Could you please give your opinion
>>
>> What is your idea about multi-dimensional filters?
>>
>> If we have different class of constraint set (e.g. some related to
>> PDE solution, some on PDE coefficient, etc.), is it better to use
>> multi-dim filter (add a dim for each set)?
>>
>
> In my mind, one of the advantages of a filter is that it might accept trial
> points more easily during the line search than a penalty methods does.  But
> in some circumstances, the filter can actually be more restricting, and
> sometimes (e.g., when the steps computed are not always very good, for
> example, when the problem is too nonlinear or one uses a quasi-Newton
> approximation) being too liberal in terms of accepting trial points can lead
> the optimizer to a bad area.
>
> As you might know, some work has been done on looking at higher-dimensional
> filter methods, e.g.,:
>
>
> http://scitation.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=SJOPE8000016000002000341000001&idtype=cvips&gifs=yes
>
> Here, one has one filter entry for not just all constraints combined, but
> for subsets of constraints separately, as you suggest.  For unconstraint
> optimization (here using the gradient entries as the filter components, not
> constraints), they report encouraging results.
>
> I'm not sure how much you would gain in the Ipopt context.  It might make
> sense if you observe that many of the trial steps are rejected in the line
> search.  But then you might want to also understand why that is...
>
> Instead of having more than one filter component for the constraints, you
> might also just want to reset the filter more often (see the
> filter_reset_trigger and max_filter_resets options).  But it probably won't
> help much.
>
> Anyway, a higher-dimensional filter is not implemented in Ipopt, and it
> would not be a trivial change (beside writing the code for having a higher
> dimensional filter, you would also have to define an interface for the user
> to specify the subset of constraints that are to be taken together). But
> Ipopt is open source software, so you can go ahead an change it, and if it
> works great and is a good implementation, and you can contributed to an open
> source project (see
> http://www.coin-or.org/contributions.html#contributions), we could in the
> end add this to the Ipopt distribution... :-)
>
> Regards,
>
> Andreas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/ipopt/attachments/20090526/5af4ceed/attachment.html