On Jan 20, 2009, at 11:58 AM, John Peterson wrote: > All I was able to finish was checking in Tim's patch, I didn't have a > chance to redo the whole NumericMatrix hierarchy yet. It's on my todo > list but there are day-job things taking up time currently.
Do you want me to stab an interface into LinearImplicitSystem? I would just basically follow what's there for shell matrices... with an attach_shell_preconditioner() function and all the rest. Or should we wait until the whole hierarchy gets redone? > I guess I don't see the need for this, but that's not to say I can't > be convinced. There's nothing like that in PETSc AFAIK. Right... part of the problem here is that I'm trying to write specialized preconditioner code.... but do it in a way that's agnostic of Petsc/Trilinos. In particular I need to be able to partially solve linear systems using multigrid solvers / preconditioners... it would be nice just to be able to instantiate a MultiGridPreconditioner object... having the correct one chose depending on how libMesh was configured and allowing you to set a lot of multigrid only options (for instance smoothing, etc.). Right now it's looking like I'm basically going to have two completely different code paths in my code that do the same thing (but call different solvers in the end).... and I can definitely just add abstractions into my own code for some of this stuff... but some of those abstractions might be useful to others in the community. I honestly don't know right now. Just thought I would get some opinions on this. I suppose I could just add a MultigridLinearSolver object... and concrete implementations of it... but that kind of goes against what we have setup with Petsc where there are a lot of actual solvers to choose from underneath (including multigrid options). The trouble is how to tell a specific PetscLinearSolver object to solve using Hypre... in a completely solver library agnostic way. Currently, when you are just solving one system it's ok to set options on the command line (like -pc_type hypre)... but that doesn't work for the stuff we're doing now... where we have _lots_ of small linear systems and some (not so small) nonlinear systems all being solved simultaneously and all preconditioned / solved differently. Currently we have to get ahold of the KSP object for each system and manually twiddle the options with Petsc calls.... but again... that means we have to do the same with Trilinos........ and that's a lot of duplicated logic. Anyway... at this point I'm rambling. If anyone has ideas, let me know. Derek ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
