On 31 July 2015 at 08:50, Garth N. Wells <gn...@cam.ac.uk> wrote:

>
> On 31 July 2015 at 08:42, Mikael Mortensen <mikael.morten...@gmail.com>
> wrote:
>
>>
>> On 30 Jul 2015, at 17:13, Garth N. Wells <gn...@cam.ac.uk> wrote:
>>
>>
>> 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  ;).
>>
>>
>> Yes, I see that one.
>>
>> 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.
>>
>>
>> Ok, so do you suggest removing additive_schwarz then and keeping the
>> other two, or keep also additive_schwarz until 1.7? In case schwarz is
>> removed we need to do a bit of cleaning up, since schwarz has a parameter
>> (in Krylovsolver::default_parameters()). I can make a PR either way.
>>
>>
> Leave additive_schwarz  out - my implementation was half-baked.
>
>
I'd like block Jacobi left out too since it's equivalent to additive
Schwarz with no overlap. Both are incompletely defined since one can't pick
the solver for each block.

Garth




> Garth
>
>
>> Mikael
>>
>>
>> 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

Reply via email to