<div class="gmail_quote">On Tue, Jul 31, 2012 at 5:38 AM, Todd Munson <span dir="ltr"><<a href="mailto:tmunson@mcs.anl.gov" target="_blank">tmunson@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":3f1">Knowing the constraint structure and forming the augmented system is fine and can be<br>
helpful information to know when determining the active set.  I would concentrate on<br>
linear constraints and inequalities though; they are nicer to deal with and you do<br>
not have to be concerned with constraint qualifications.<br>
<br>
Nonlinear constraints are possible, but you need to satisfy a constraint qualification<br>
and you need second derivatives of the constraints for the augmented system.  (In<br>
optimization terms, the Hessian of the Lagrangian.)<br></div></blockquote><div><br></div><div>I would be in favor of making the interface support this more general form. I'm not wild about having the user add a bunch of extra variables because then they have to explain enough about that reformulation to decompose it again for an efficient multigrid solver.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3f1">
<div class="im"><br>
> There are some reformulations for polyhedral constraints, but they are, in my opinion,<br>
> a bit unwieldy.<br>
><br>
> Why unwieldy?<br>
<br>
</div>The standard semismooth formulation using the Fischer-Burmeister function and its<br>
cousins works only for bound constraints.  Designing a semismooth reformulation<br>
for general polyhedral constraints is difficult.  It can be done, but its<br>
really not easy.  You can define the normal map using projections, but<br>
then you need to be able to do the projections onto the constraint<br>
set.<br>
<br>
Of course, the augmented system results in a box constrained problem and the<br>
standard formulations work.<br></div></blockquote><div><br></div><div>I'm not at all opposed to having the library use the augmented system internally, I just don't like making the user reformulate because it's more intrusive to their code and because it locks the library into solving the problem that way.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3f1">
<br>
One thing we should try is adding slacks in the semismooth algorithm for box<br>
constraints and then applying the reformulation to the redefined system.<br>
There is some evidence that this will work better.<br></div></blockquote><div><br></div><div>If you have a reference for a version that you like, I'll implement it when I start messing with that code.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3f1"><div class="im">
<br>
> Note that changing the size of the constrained size is also important, and box constraints strike me as even more confusing in that context.<br>
<br>
</div>I do not follow this at all.  Are you talking about something like a time dependent<br>
problem and the constraints in the VI are a function of time?  That becomes a<br>
somewhat odd problem and I'd have to see an example.  Normally the<br>
constraint set is fixed for all time and just the activities<br>
change.<br></div></blockquote></div><br><div>Suppose we are doing unstructured elastic contact. Any surface point could end up in contact with any other. If we reformulate with bound contstraints, we end up adding N^2 auxiliary variables. If we can use nonlinear constraints where the number of constraints can change each iteration, then we only need to deal with the O(N) viable contact possibilities. I'm happy to differentiate the constraint functions, but I certainly want the flexibility.</div>