[petsc-dev] Semi-smooth VI solver and matrix-free SNES

[Dmitry Karpeyev]

Todd,

What's the semi-smooth version in TAO that respect the bounds at the
iterates?
Maybe that would be a good place to attempt a unification with SNESVI.

The current implementation could benefit from refactoring to enable more
composability:
could we use a VIRS method inside VISS and allow for a user-defined active
set definition/projection?
Then a bound-respecting VISS would be a combination of the current VISS and
VIRS, potentially
controllable from the command line.

The same goes for the linesearch: Armijo would be another  SNESLineSearch
type that could be turned on on demand.
Finally, perhaps we could enable composition of DM(SNES) objects?  Then
wrapping projection onto bounds around residual/Jacobian evaluation
routines would be a composition of two DM(SNES) objects.  Right now
something along those lines takes place in VIRS where an RS DM is
"composed" with the full space DM, although this composition is
currently ad hoc.

Dmitry.


On Fri, Aug 1, 2014 at 9:35 AM, Munson, Todd S. <tmunson at mcs.anl.gov> wrote:

>
> Possibly it can be taken out; don't have time to go through the details
> today though.
>
> Regarding feasibility, there are feasible versions that respect the bounds
> in TAO
> as well as infeasible versions that only respect the bounds at the
> solution.
>
> Todd.
>
> On Aug 1, 2014, at 10:02 AM, Dmitry Karpeyev <karpeev at mcs.anl.gov> wrote:
>
> > Currently the semi-smooth VI solver (VINEWTONSSLS) doesn't play well
> with the matrix-free SNES (aka JFNK).  This is partly because the
> calculation of the merit function gradient requires the action of the
> transpose of the Jacobian, which isn't implemented for MATMFFD.
>  Presumably, the merit function would be used in a fancy (Armijo?) line
> search as described here: http://arxiv.org/abs/math/0307305.  However, it
> appears that only a basic line search is performed and the merit function
> gradient isn't used.  Should the merit gradient calculation be taken out?
> >
> > This fix might not be enough to make the SS method work with JFNK,
> however: the line search
> > there isn't projected, so MatMFFD might have an infeasible base at some
> iterates.  This might break residual evaluation (e.g., due to negative
> densities). More importantly, however, even if the intermediate iterates
> were feasible, the increments used in the MatMFFD differencing algorithm
> might not be, and there is really no way around it with something like
> projection without breaking the semantics of MatMult.  Is VINEWTONSSLS
> unusable with JFNK in its current form?  In any event, should the Armijo
> line search be implemented?
> >
> > Dmitry.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140801/d8e6c0d9/attachment.html>