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