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