On 1 September 2013 19:51, Barry Smith <[email protected]> wrote: > > On Sep 1, 2013, at 1:44 PM, "Garth N. Wells" <[email protected]> wrote: > >> On 1 September 2013 19:27, Matthew Knepley <[email protected]> wrote: >>> On Sun, Sep 1, 2013 at 1:07 PM, Satish Balay <[email protected]> wrote: >>>> >>>> I see the errors with valgrind - and I don't know the reason. Perhaps >>>> we should revert the metis/parmetis upgrade.. [unless someone can debug >>>> this..] >>>> >>>> valgrind doesn't give errors with the older metis-5.0.2 >>> >>> >>> This looks like a MUMPS bug. I guess we should report to them that they are >>> not >>> actually compatible with the latest METIS release. >>> >> >> MUMPS releases take place on glacial time scales. METIS is not a >> required dependency for MUMPS, so to move the METIS version forward in >> PETSc and not break MUMPS you could just configure MUMPS with only >> SCOTCH, instead of with METIS and SCOTCH as is presently the case. > > Yes but what if, for some reason, metis does a much better job for MUMPS > on someone's problem than scotch; now we've made it hard for them to use > metis with mumps. >
Then they can build their own METIS ;) Garth > Was there really a strong reason to upgrade metis the last time, beside > "oh they made a release, let's upgrade PETSc to use it"? > > Yes, this is going to be a constant pain if some packages are slow in > upgrading to releases in other packages. > > Barry > >> >> Garth >> >>> Matt >>> >>>> >>>> Satish >>>> ----------- >>>> >>>> >>>> On Sun, 1 Sep 2013, Garth N. Wells wrote: >>>> >>>>> I've been having trouble with MUMPS crashing since METIS was recently >>>>> updated in >>>>> >>>>> https://bitbucket.org/petsc/petsc/commits/67125ba >>>>> >>>>> The problem does not appear for very small problems, but for other >>>>> problems it does. I can reproduce a crash with ex55 >>>>> (src/ksp/ksp/examples/tutorials/ex55.c): >>>>> >>>>> ./ex55 -ksp_type preonly -pc_type lu -pc_factor_mat_solver_package >>>>> mumps -ksp_view -ne 128 >>>>> >>>>> For 'ne' less than about 50 it runs fine but crashes for anything >>>>> bigger. Changing the LU solver to another package it runs fine. >>>>> Backtrace below. The message >>>>> >>>>> http://www.mail-archive.com/[email protected]/msg17695.html >>>>> >>>>> looks to be related. >>>>> >>>>> Garth >>>>> >>>>> ======= Backtrace: ========= >>>>> /lib/x86_64-linux-gnu/libc.so.6(+0x80a46)[0x7f877c6f4a46] >>>>> >>>>> /home/garth/local/src/petsc-test/arch-linux2-c-debug/lib/libmetis.so(gk_gkmcorePop+0x81)[0x7f877be7fcae] >>>>> >>>>> /home/garth/local/src/petsc-test/arch-linux2-c-debug/lib/libmetis.so(gk_malloc_cleanup+0x3f)[0x7f877be6c418] >>>>> >>>>> /home/garth/local/src/petsc-test/arch-linux2-c-debug/lib/libmetis.so(METIS_NodeND+0x6de)[0x7f877be9fa02] >>>>> >>>>> /home/garth/local/src/petsc-test/arch-linux2-c-debug/lib/libmetis.so(metis_nodend_+0x48)[0x7f877be94ba8] >>>>> >>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(dmumps_195_+0x3720)[0x7f877e67ac40] >>>>> >>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(dmumps_26_+0x279c)[0x7f877e553d30] >>>>> >>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(dmumps_+0x2022)[0x7f877e638756] >>>>> >>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(dmumps_f77_+0x16eb)[0x7f877e51a567] >>>>> >>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(dmumps_c+0x12a5)[0x7f877e4f2fed] >>>>> >>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(MatLUFactorSymbolic_AIJMUMPS+0xa88)[0x7f877dc00d11] >>>>> >>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.so(MatLUFactorSymbolic+0xb61)[0x7f877db6a82f] >>>>> /home/garth/local/gcc/petsc-test/lib/libpetsc.soAborted (core dumped) >>>>> >>> >>> >>> >>> >>> -- >>> 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 >
