On Jul 31, 2012, at 2:36 AM, Jed Brown wrote:

> On Mon, Jul 30, 2012 at 5:40 PM, Todd Munson <tmunson at mcs.anl.gov> wrote:
> > 1. change SNESVI to support general complementarity constraints because 
> > only doing box constraints on state variables is lame
> 
> Okay; and how do you want to do this?  You need to write out the 
> corresponding KT system
> and then you just have a box constrained problem.  One can make it easier to 
> write the
> KT system, but then you have to precondition the KT system.
> 
> Yes, but if the user created the augmented system, they have to inform the 
> linear solver of that structure. I think it is much more convenient for the 
> user to not have to manage those things.

Knowing the constraint structure and forming the augmented system is fine and 
can be
helpful information to know when determining the active set.  I would 
concentrate on
linear constraints and inequalities though; they are nicer to deal with and you 
do
not have to be concerned with constraint qualifications.

Nonlinear constraints are possible, but you need to satisfy a constraint 
qualification
and you need second derivatives of the constraints for the augmented system.  
(In
optimization terms, the Hessian of the Lagrangian.)

> There are some reformulations for polyhedral constraints, but they are, in my 
> opinion,
> a bit unwieldy.
> 
> Why unwieldy?

The standard semismooth formulation using the Fischer-Burmeister function and 
its
cousins works only for bound constraints.  Designing a semismooth reformulation
for general polyhedral constraints is difficult.  It can be done, but its
really not easy.  You can define the normal map using projections, but
then you need to be able to do the projections onto the constraint
set.

Of course, the augmented system results in a box constrained problem and the
standard formulations work.

One thing we should try is adding slacks in the semismooth algorithm for box
constraints and then applying the reformulation to the redefined system.
There is some evidence that this will work better.


> Note that changing the size of the constrained size is also important, and 
> box constraints strike me as even more confusing in that context.

I do not follow this at all.  Are you talking about something like a time 
dependent
problem and the constraints in the VI are a function of time?  That becomes a
somewhat odd problem and I'd have to see an example.  Normally the 
constraint set is fixed for all time and just the activities
change.

Cheers, Todd.

Reply via email to