[petsc-users] Possible to recover ILU(k) from hypre/pilut?

[Mark Lohry]

Good to know, thanks. Maybe plausible that ILU(0) works well here since the
system is much denser than comparable low order methods? ILU(1) gave maybe
10% fewer gmres iterations than ILU(0), so a net loss there.

My system is mostly equivalent to what's used with ILU(0) variants
effectively in Persson & Peraire - "newton-gmres preconditioning for
discontinuous galerkin discretizations of the navier-stokes equations".

I'll have to run comparisons with the sparse direct solvers in the near
future.

On Thu, Nov 16, 2017 at 7:53 AM, Matthew Knepley <knepley at gmail.com> wrote:

> On Wed, Nov 15, 2017 at 10:57 PM, Mark Lohry <mlohry at gmail.com> wrote:
>
>> What are the limitations of ILU in parallel you're referring to? Does
>> Schwarz+local ILU typically fare better?
>>
>
>
> Anecdotally, the sweet spot for ILU(k) k > 0 is extremely small. For
> smaller problems, sparse direct is so good its
> hard to win with ILU(k) since you do at least a few iterates. For larger
> problems, ILU(k) runs out of gas or memory
> fairly fast, and its better to find a method tailored to the problem.
>
>    Matt
>
>
>> On Nov 15, 2017 10:50 PM, "Smith, Barry F." <bsmith at mcs.anl.gov> wrote:
>>
>>>
>>>
>>> > On Nov 15, 2017, at 9:40 PM, Jed Brown <jed at jedbrown.org> wrote:
>>> >
>>> > "Smith, Barry F." <bsmith at mcs.anl.gov> writes:
>>> >
>>> >>> On Nov 15, 2017, at 6:38 AM, Mark Lohry <mlohry at gmail.com> wrote:
>>> >>>
>>> >>> I've found ILU(0) or (1) to be working well for my problem, but the
>>> petsc implementation is serial only. Running with -pc_type hypre
>>> -pc_hypre_type pilut with default settings has considerably worse
>>> convergence. I've tried using -pc_hypre_pilut_factorrowsize (number of
>>> actual elements in row) to trick it into doing ILU(0), to no effect.
>>> >>>
>>> >>> Is there any way to recover classical ILU(k) from pilut?
>>> >>>
>>> >>> Hypre's docs state pilut is no longer supported, and Euclid should
>>> be used for anything moving forward. pc_hypre_boomeramg has options for
>>> Euclid smoothers. Any hope of a pc_hypre_type euclid?
>>> >>
>>> >>  Not unless someone outside the PETSc team decides to put it back in.
>>> >
>>> > PETSc used to have a Euclid interface.  My recollection is that Barry
>>> > removed it because users were finding too many bugs in Euclid and
>>> > upstream wasn't fixing them.  A contributed revival of the interface
>>> > won't fix the upstream problem.
>>>
>>>    The hypre team now claims they care about Euclid. But given the
>>> limitations of ILU in parallel I can't imagine anyone cares all that much.
>>>
>>>
>>>
>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20171116/e4fa8ac5/attachment.html>