On Feb 6, 2009, at 3:47 PM, Roy Stogner wrote: > Supporting old APIs is always good. If you want to stick a > deprecated() warning in there now and plan to get rid of it in the > future, though, that's fine. > > In the near term, I'd like to have a factory method that takes a > PreconditionerType and generates a Preconditioner.
Hmmm... so I think you're thinking of a slightly different (but similar) model to what I've implemented. The way it is currently you can call Preconditioner::build() to get a Preconditioner object appropriate for the current active solver type (just like with NumericVector, etc.). This means that when you do Preconditioner::build() you will get back a PetscPreconditioner object. This object has the ability to use any of the built in PetscPreconditioner types. This way we don't have ILUPreconditioner, AMGPreconditioner, LUPreconditioner, etc. classes... just the one. I think you were suggesting we actually bust out those seperate classes (unless I'm misunderstanding). Or maybe that we might still have monolithic Preconditioner classes for all the common stuff... and separate ones for the more involved (like AMG preconditioners). This is actually where I'd like to go in the future. So I do think your suggestion is a good one. The idea would be to make Preconditioner::build() take an optional PreconditionerType. > Then, when you call set_preconditioner_type it uses that factory to > build a new Preconditioner, or when you call set_preconditioner it > calls set_preconditioner_type(pre.type()) to keep in sync. Agreed... my current version of LinearSolver::set_preconditioner() checks to see if a Preconditioner has been attached... and if it has then it calls preconditioner->set_preconditioner_type(). Similar for get_preconditioner_type, etc. > I'd say initialize the LinearSolver with whatever Preconditioner > corresponds to the default ILU_PRECOND type; these things should be > lightweight enough (until they're initialized with a matrix) that > that's convenient and cheap enough. I think the only issue is whether or not using a PetscPreconditioner object with it's type set to ILU_PRECOND is exactly the same as calling PCSetType() and passing in PCILU. The one major difference is that Petsc is going to have to call out to an externed function in libMesh that will then translate to libmesh NumericVectors and call preconditioner->apply(). So each application (and setup) of the preconditioner will incur (probably) more work... but it's unclear if it's going to have any actual impact. This is really going to come down to testing... I'm just going to have to do some. If the speed hit is negligible then I think I'd rather always use Preconditioner objects so everything is consistent. Derek ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
