Explicit Scaling support on Thyra objects
Created by: rppawlo
CC: @trilinos/thyra
Description:
email discussion below was started on scaling support in Thyra. Need to bring in a larger team and discuss long term design.
Matt,
If you have access to a LOB object that supports the current Thyra::ScaledLinearOpBase mix-in interface, then you can scale a matrix by a constant by first creating a vector set to a constant and then passing it in to the Thyra::ScaledLinearOpBase::scaleLeft() (or scaleRight()) function. Given the expense of explicitly scaling all of the entries of a matrix, that should not be too much more expensive than directly scaling by a constant.
If you don't have access to a LOB object that supports the Thyra::ScaledLinearOpBase interface, then there are other options. But I will need to know more about your use case before I can give you any further guidance. Let’s set up a quick meeting to discuss this if that is the case.
Roger,
I’m fine with renaming, but could we also just add support to the ScaledLinearOpBase object for scaling by a constant as well (so it covers both diagonal and constant)?
After looking at that interface and how it is used (I was not part of the design of that interface or it usage or implementation), it seems this is used for explicitly scaling a matrix and not implicit scaling. Therefore, I think the name of this should be changed to "ExplicitlyScaledLinearOpBase" and then it would be fine and proper to add a function to also scale it by a constant as well as scaling it by diagonals. If that will help Matt's use case, we should do it.
I’m a little worried about the explosion of mix-in interfaces. It makes things harder to find. Just trying to think of ways to simplify thyra usage. Along these lines, maybe we should also look at all these support classes and see if we could wrap some things into the base class object? Having to dynamic cast to do simple things like scaling can be frustrating to users.
This starts to get into some deeper OO design issues. Mike Heroux has asked us to do more careful and deliberate requirements analysis and design going forward. Therefore, should we break down this discussion into a set of appropriate Trilinos GitHub issues and then have these conversations there so other people can participate and we can archive these discussions? And this discussion is starting to touch on the larger issue of how we can go about simplifying Thyra and/or providing better tutorial, training, and references materials for its usage (likely all of these). We have enough concrete use cases implemented now that we can see the impact that changes in the interfaces and design will have on this stack of software and various software clients. We should likely create an Epic (GitHub Milestone) for Thyra refactorings and then start to get started on this some (after I get a few more urgent/critical things out of the way). I have some ideas about how to simplify Thyra and make it easier to develop on and use and input from users and developers would be good.
Thanks,
-Ross
On 2/3/17, 12:24 PM, "Bartlett, Roscoe A" rabartl@sandia.gov wrote: Matt, We have a DECORATOR interface and implementation for scaling (and/or taking the adjoint) for any forward Thyra::LinearOpBase object: * https://trilinos.org/docs/dev/packages/thyra/doc/html/classThyra_1_1ScaledA djointLinearOpBase.html * https://trilinos.org/docs/dev/packages/thyra/doc/html/classThyra_1_1DefaultS caledAdjointLinearOp.html but we don't (yet) have a the equivalent DECORATORS for the Thyra::LinearOpWithSolveBase interface. Developing general decorator subclasses for the LOWSB interface would be a little more complicated due to its impact on the solve criteria and solve status, but it can be done. Can we discuss your use case and see if these LOWSB subclass should be developed, and if so, what priority they should be compared to other important tasks? Roger, The DECORATOR subclass Thyra::ScaledLinearOpBase may be a bit poorly named (or at least is inconsistent with the Thyra::ScaledAdjointLinearOpBase class) in that it is not scaling by a scalar constant, but is scaling by a diagonal matrix. I wonder if we should not rename this Thyra::DiagonallyScaledLinearOpBase to avoid confusing with scaling by just a constant? We can safely keep and deprecate the old name when C++11 support is turned on (using templated typedef/alias) to preserve backward compatibility. Does that sound reasonable? Thanks, -Ross > -----Original Message----- > From: Pawlowski, Roger P > Sent: Thursday, February 02, 2017 8:22 AM > To: Bettencourt, Matthew > Cc: Bartlett, Roscoe A > Subject: Re: thyra matrix scale > > You should be able to do it, but I don’t see it. If it isn’t in a different class, we > can add the method to the derived class: > > Thyra_ScaledLinearOpBase.hpp > > Right now you could scale inefficiently using the current interface and a diagonal > vector by dynamically casting the operator to the ScaledLinearOpBase class. > Cc’ing Ross in case I missed something. > > Roger > > > On 2/1/17, 4:18 PM, "Bettencourt, Matthew" mbetten@sandia.gov wrote: > > is there anyway to take > > RCP<Thyra::LinearOpWithSolveBase > jacobian; > > and scale it by a constant? > > >