On 30 July 2015 at 13:19, Mikael Mortensen <[email protected]> wrote:
> > On 30 Jul 2015, at 13:54, Jan Blechta <[email protected]> wrote: > > On Thu, 30 Jul 2015 12:27:47 +0100 > "Garth N. Wells" <[email protected]> wrote: > > On 30 July 2015 at 12:18, Mikael Mortensen > <[email protected]> wrote: > > Hi > > Back from vacation and very pleased :-) to find that I can update my > Fenics installation to version 1.6 in less than 10 minutes! Used to > take at least a few days. > > Now I’m trying to upgrade my applications to 1.6 and I just found > that some of the common preconditioners (jacobi, bjacobi, > additive_schwarz) have gone missing. Any reason for this or is it a > mistake? They seem to have disappeared recently from the map > _methods_descr in PETScPreconditioner.cpp. > > > The code in question was a mess and the wrapping approach > unsustainable, which is why it was removed. > > > Including these three lines in creating _methods_descr in > PETScPreconditioner.cpp seems to work. Why do you consider it messy? > > {"jacobi", "Jacobi iteration"}, > {"bjacobi", "Block Jacobi iteration"}, > {"additive_schwarz", "Additive Schwarz"}, > > Removing the first two was an error by me when stripping out CUSP. They can go back. I'll blame my mistake on some bad indentation of an #ifedf ;). It's not sensible to provide Additive Schwarz since it has a raft of options that should be set on it, but we can't sustainably wrap these. With the forthcoming design clean up, a user will have complete control over an Additive Schwarz PC. Garth > Jacobi and additive_schwarz are the two best preconditioners for a > momentum solve in Navier-Stokes and I don’t think they should have been > removed without even making the ChangeLog. > > > The demand for the wrapping comes from the requirement of having > certain amount of control portable across backends. Is this requirement > getting abandoned, or at least weakened? > > > Another issue is that most users will simply > print list_krylov_solver_preconditioners, and they will then not know that > they can actually create a jacobi preconditioner. If they do find out they > will have to do something (not portable across backends) like > > p = PETScPreconditioner(‘jacobi’) > solver = PETScKrylovSolver(‘cg’, p) > > where they used to be able to do > > solver = KrylovSolver(“cg”, ‘jacobi’) > > Not much more complex, but certainly not very user-friendly to hide > preconditioners like this. > > > > Jan > > > You can control the PETSc preconditioners via PETSc options. This > gives you far greater control, makes DOLFIN code simpler and provides > greater consistency when using PETSc solver. There will be more > changes in DOLFIN 1.7 to give greater control over preconditioning. > > > Ok, what are actually the plans for 1.7? > > Mikael > > > > Garth > > > > > Best regards > > Mikael > > _______________________________________________ > fenics mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics > > >
_______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
