On 30 July 2015 at 13:19, Mikael Mortensen <mikael.morten...@gmail.com>
wrote:
>
> On 30 Jul 2015, at 13:54, Jan Blechta <blec...@karlin.mff.cuni.cz> wrote:
>
> On Thu, 30 Jul 2015 12:27:47 +0100
> "Garth N. Wells" <gn...@cam.ac.uk> wrote:
>
> On 30 July 2015 at 12:18, Mikael Mortensen
> <mikael.morten...@gmail.com> 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
> fenics@fenicsproject.org
> http://fenicsproject.org/mailman/listinfo/fenics
>
>
>
_______________________________________________
fenics mailing list
fenics@fenicsproject.org
http://fenicsproject.org/mailman/listinfo/fenics
