<div>Andreas,</div>
<div> </div>
<div>Lot of thanks for your commnets.</div>
<div> </div>
<div>Cheers</div>
<div> </div>
<div>RT</div>
<div> </div>
<div> </div>
<div><br> </div>
<div class="gmail_quote">On Tue, May 26, 2009 at 7:44 AM, Andreas Waechter <span dir="ltr"><<a href="mailto:andreasw@watson.ibm.com">andreasw@watson.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi RT,
<div class="im"><br><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">What is maximum number of entries in filter (a common value)? Is essentially<br>action of filter function of maximum number of entries?<br>
</blockquote><br></div>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.<br><br>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... :-) ).<br>
<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Could you please give your opinion<br><br>What is your idea about multi-dimensional filters?<br><br>If we have different class of constraint set (e.g. some related to<br>
PDE solution, some on PDE coefficient, etc.), is it better to use<br>multi-dim filter (add a dim for each set)?<br></blockquote><br>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.<br>
<br>As you might know, some work has been done on looking at higher-dimensional filter methods, e.g.,:<br><br><a href="http://scitation.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=SJOPE8000016000002000341000001&idtype=cvips&gifs=yes" target="_blank">http://scitation.aip.org/getabs/servlet/GetabsServlet?prog=normal&id=SJOPE8000016000002000341000001&idtype=cvips&gifs=yes</a><br>
<br>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.<br>
<br>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...<br>
<br>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.<br>
<br>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 <a href="http://www.coin-or.org/contributions.html#contributions" target="_blank">http://www.coin-or.org/contributions.html#contributions</a>), we could in the end add this to the Ipopt distribution... :-)<br>
<br>Regards,<br><font color="#888888"><br>Andreas<br></font></blockquote></div><br>