On Tue, Nov 24, 2009 at 11:10 AM, Roy Stogner <[email protected]> wrote: > > On Mon, 23 Nov 2009, John Peterson wrote: > >> {lu,cholesky}_solve(rhs, soln); >> >> This seems fairly reasonable on the surface, but there is a gotcha in >> that both routines modify the rhs *as well as* the soln vector >> internally. > > That's surprising. Do we need to do this? On first glance: > > It looks like the cholesky back substitution never reuses b(i) outside > of (or at later iterations in) the i loop; surely we can replace that > with a single scalar on the stack. The LU back substitution is > trickier, since that's storing a full vector's worth of temporary > data, but do we need to store said temporary data in b? It looks like > we can probably get away with using the unfinished parts of x instead.
So: keep the same interface and rework the algorithms? Seems like a reasonable approach as well. I was sort of basing my new API on what Lapack does, which is overwrite the input (rhs) vector with the solution. We could still maintain a two-vector input API, but the Lapack implementation would have to make a copy of the RHS before the back substitution step overwrites it internally. -- John ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
