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@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@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.
>