The current LU and Cholesky solve interfaces of DenseMatrix are essentially:
{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. This fact isn't well-documented, and there are at least
two obvious problems:
1.) The rhs can't be used for anything else after the function call
2.) The user is forced to create and track an extra DenseVector object
for every call to the solve
In looking briefly at typical uses of LU and Cholesky in LibMesh, case
1 (needing to use the rhs later) above seems to be infrequent. This
means that no one has probably been caught by it, but it also means
that that vector should probably just be re-used. In the event that a
user does later need the rhs for something else, he can always make a
copy of it, but again, this should be an infrequent use case. The
second problem isn't a huge issue either, but any extra variable makes
code a bit harder to read.
I'd like to propose that we change this interface to
{lu,cholesky}_solve(DenseVector<T>& x);
where x is an input/output variable equal to the rhs on input and
equal to the solution on output. There are a few places where these
solves are used internally in the library, and they shouldn't be too
hard to find and fix. Since this is an API change, though, I thought
I would send it to the list and see if there were any further
comments.
--
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
