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

[Jason Sarich]

The ssfls and asfls solvers respect feasibility, ssils and asils do not
(the 'f' stands for feasibility, 'i' for infeasibility)

ssfls - semismooth, feasible, with line search
asfls - active set semismooth, feasible, with line search




On Fri, Aug 1, 2014 at 10:45 AM, Karpeyev, Dmitry Aleksandrovich <
karpeev at mcs.anl.gov> wrote:

>  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/c0eb102c/attachment.html>