> I agree about not tying LibMesh too much to PETSc but since there is a > PetscNonlinearSolver class, I definitely want to use its full potential when > solving nonlinear problems. And hence exposure to the actual snes object > either through a property or function is necessary to have better control of > how the nonlinear system is being solved. And that was my original request ! > There could always be a class for TrilinosNonlinearSolver or > ...NonlinearSolver that could solve the system with Newton or FPI scheme > from the corresponding packages but nevertheless, user needs control of the > base objects. Transparency here could affect performance. Just my 2 cents.
The approach will undoubtedly parallel the linear solver class. Everything that is common & that can be abstracted will be; and it should be accessed through the underlying NonlinearSolver class. I've got no issue exposing the underlying PETSc or Trilinos objects in *an unsupported way*. John has done this in the past with the PetscLinearSolver: he used a specific preconditioner through the PC object. I doubt that will make it into any of the examples, though. -Ben ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
