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 <knep...@gmail.com> wrote: > On Wed, Nov 15, 2017 at 10:57 PM, Mark Lohry <mlo...@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." <bsm...@mcs.anl.gov> wrote: >> >>> >>> >>> > On Nov 15, 2017, at 9:40 PM, Jed Brown <j...@jedbrown.org> wrote: >>> > >>> > "Smith, Barry F." <bsm...@mcs.anl.gov> writes: >>> > >>> >>> On Nov 15, 2017, at 6:38 AM, Mark Lohry <mlo...@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/> >
