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

[Smith, Barry F.]

> On Nov 15, 2017, at 9: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?

  If ILU works fine for scalably in parallel that is great. Most of the PETSc team has an explicit bias against ILU generally speaking.

  Barry

> 
> 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.
> 
>