Thanks, Jason. Dmitry. On Aug 1, 2014 9:52 AM, "Jason Sarich" <[email protected]> wrote:
> 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. >>> > >>> >>> >> >
