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 < [email protected]> 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. <[email protected]> > 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 <[email protected]> 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. >> > >> >> >
