On Tue, Dec 21, 2010 at 14:42, Jan Biermann <biermann@tu-harburg.de> wrote:
first, I sent the stuff to Petsc and they want to include it (otherwise it would not make any sense to make the changes in libmesh I guess).

Okay, I asked because I hadn't seen it go by and it's not in the petsc-dev repository yet.

to answer Jed's question (Why is a special interface needed from libmesh?) There are certain petsc functions that need to be included additionally but most important, I chose to handle the recycle space (that will be reused from one solve to the other) at the linear implicit system, so outside from petsc.
This way it is easier to switch between solvers etc. without reallocating memory and the recycle space is easier to manipulate (there is a lot of freedom and potential for optimization)

Without looking at the code, the downside is that this makes the interface more complicated.  It's very likely that Barry wants the basic interface to be that users just call KSPSolve repeatedly and take advantage of a recycled subspace.  Having an interface to manipulate it, or even pull it out as a separate entity may remain, but if I know Barry, he'll likely tweak things so that the basic interface does not involve the user doing anything special with a subspace.  With that in mind, you might want to wait until it goes into petsc-dev before committing the libmesh interface.