On Wed, 26 Mar 2014 17:16:13 +0100 "Garth N. Wells" <[email protected]> wrote:
> > On 26 Mar 2014, at 16:56, Jan Blechta <[email protected]> > wrote: > > > On Wed, 26 Mar 2014 16:29:11 +0100 > > "Garth N. Wells" <[email protected]> wrote: > > > >> > >> On 26 Mar 2014, at 16:26, Jan Blechta <[email protected]> > >> wrote: > >> > >>> On Wed, 26 Mar 2014 16:16:25 +0100 > >>> Johannes Ring <[email protected]> wrote: > >>> > >>>> On Wed, Mar 26, 2014 at 1:39 PM, Jan Blechta > >>>> <[email protected]> wrote: > >>>>> As a follow-up of 'Broken PETSc wrappers?' thread on this list, > >>>>> can anyone reproduce incorrect (orders of magnitude) norm using > >>>>> superlu_dist on following example? Both in serial and parallel. > >>>>> Thanks, > >>>> > >>>> This is the result I got: > >>>> > >>>> Serial: > >>>> > >>>> L2 norm mumps 0.611356580181 > >>>> L2 norm superlu_dist 92.4733890983 > >>>> > >>>> Parallel (2 processes): > >>>> > >>>> L2 norm mumps 0.611356580181 > >>>> L2 norm superlu_dist 220.027905995 > >>>> L2 norm mumps 0.611356580181 > >>>> L2 norm superlu_dist 220.027905995 > >>> > >>> superlu_dist results are obviously wrong. Do we have broken > >>> installations or is there something wrong with the library? > >>> > >>> In the latter case I would suggest switching the default back to > >>> MUMPS. (Additionally, MUMPS has Cholesky factorization!) What was > >>> your motivation for switching to superlu_dist, Garth? > >>> > >> > >> MUMPS often fails in parallel with global dofs, and there is no > >> indication that MUMPS developers are willing to fix bugs. > > > > I'm not sure what do you mean by 'MUMPS fails’. > > Crashes. > > > I also observe that > > MUMPS sometimes fails because size of work arrays estimated during > > symbolic factorization is not sufficient for actual numeric > > factorization with pivoting. But this is hardly a bug. > > It has bugs with versions of SCOTCH. We’ve been over this before. > What you describe above indeed isn’t a bug, but just poor software > design in MUMPS. > > > It can by > > analyzed simply by increasing verbosity > > > > PETScOptions.set('mat_mumps_icntl_4', 3) > > > > and fixed by increasing ' > > work array increase percentage' > > > > PETScOptions.set('mat_mumps_icntl_14', 50) # default=25 > > > > or decreasing pivoting threshold. I have suspicion that frequent > > reason for this is using too small partitions (too much processes). > > (Users should also use Cholesky and PD-Cholesky whenever possible. > > Numerics is much more better and more things are predictable in > > analysis phase.) > > > > On the other superlu_dist is computing rubbish without any warning > > for me and Johannes. Can you duplicate? > > > > I haven’t had time to look. We should have unit testing for LU > solvers. From memory I don’t think we do. Ok, fix is here switch column ordering PETScOptions.set('mat_superlu_dist_colperm', col_ordering) col_ordering | properties -------------------------------------- NATURAL | works, large fill-in MMD_AT_PLUS_A | works, smallest fill-in (for this case) MMD_ATA | works, reasonable fill-in METIS_AT_PLUS_A | computes rubish (default on my system for this case) PARMETIS | supported only in parallel, computes rubish or row ordering PETScOptions.set('mat_superlu_dist_rowperm', row_ordering) row_ordering | properties -------------------------------------- NATURAL | works, good fill-in LargeDiag | computes rubish (default on my system for this case) or both. Jan > > Garth > > > Jan > > > >> > >> Garth > >> > >>> Jan > >>> > >>>> > >>>> Johannes > >>>> _______________________________________________ > >>>> fenics-support mailing list > >>>> [email protected] > >>>> http://fenicsproject.org/mailman/listinfo/fenics-support > > _______________________________________________ > fenics-support mailing list > [email protected] > http://fenicsproject.org/mailman/listinfo/fenics-support _______________________________________________ fenics-support mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics-support
