Garth, Thanks for the info. It is unlikely we will drop MUMPS but we should likely robustly our interface with PaStiX. In particular with the hybrid threads-MPI PETSc stuff Shri and Jed are working on the hybrid PaStiX fits naturally. So any patches you wish to submit for the PETSc-PaStiX interface or ideas on how to improve/extend it are appreciated. The honest truth is that currently it is pretty much an unattended baby and a little love would help it.
Barry On Nov 9, 2012, at 12:40 PM, Garth N. Wells <gnw20 at cam.ac.uk> wrote: > I've only just joined the petsc-dev list, but I'm hoping with this > subject line my email will join the right thread . . . . (related to > MUMPS). > > I've been experimenting over the past year with MUMPS and PaStiX for > parallel LU, and found MUMPS pretty much useless because it uses so > much memory. PaStiX was vastly superior performance-wise and it > supports hybrid threads-MPI, which I think is essential for parallel > LU solvers to make good use of typical multi-socket multi-core compute > nodes. The interface, build and documentation are a bit clunky (I put > the last point down to developer language issues), but the performance > is good and the developers are responsive. I benchmarked PaStiX for P1 > and P2 3D linear elastic finite element problems against a leading > commercial offering, and PaStiX was marginally faster for P1 and > marginally slower for P2 (PaStiX performance does depend heavily on > BLAS). I couldn't even compute the test problems with MUMPS because it > would blow out the memory. For reference, I tested systems up to 27M > dofs with PaStiX. > > Based on my experience and tests, I'd be happy to see PETSc drop MUMPS > and focus/enhance/fix support for PaStiX. > > Garth
