<div dir="auto">What are the limitations of ILU in parallel you're referring to? Does Schwarz+local ILU typically fare better?</div><div class="gmail_extra"><br><div class="gmail_quote">On Nov 15, 2017 10:50 PM, "Smith, Barry F." <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Nov 15, 2017, at 9:40 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
> "Smith, Barry F." <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> writes:<br>
><br>
>>> On Nov 15, 2017, at 6:38 AM, Mark Lohry <<a href="mailto:mlohry@gmail.com">mlohry@gmail.com</a>> wrote:<br>
>>><br>
>>> 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.<br>
>>><br>
>>> Is there any way to recover classical ILU(k) from pilut?<br>
>>><br>
>>> 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?<br>
>><br>
>>  Not unless someone outside the PETSc team decides to put it back in.<br>
><br>
> PETSc used to have a Euclid interface.  My recollection is that Barry<br>
> removed it because users were finding too many bugs in Euclid and<br>
> upstream wasn't fixing them.  A contributed revival of the interface<br>
> won't fix the upstream problem.<br>
<br>
   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.<br>
<br>
<br>
</blockquote></div></div>