You should upgrade to the lastest PETSc and that will also upgrade to the latest MUMPS. There may be better error checking and bounds checking now.
Fundamentally until there is solid support for MUMPS with 64 bit indices you are stuck. SuperLU_DIST does fully support 64 bits but I have heard it is slower. Barry > On Nov 4, 2019, at 4:19 PM, Anthony Paul Haas <a...@email.arizona.edu> wrote: > > Hi Barry, > > Thanks for your answer. Integer overflow seems to make sense. I am trying to > do a direct inversion with Mumps LU. The code works for smaller grids but > this case is pretty large (mesh is 12,001x 301). I am also attaching the > output of the code in case that could provide more info. Do you know how I > should proceed? > > Thanks, > > Anthony > > On Mon, Nov 4, 2019 at 1:46 PM Smith, Barry F. <bsm...@mcs.anl.gov> wrote: > > > > > > On Nov 4, 2019, at 2:14 PM, Anthony Paul Haas via petsc-users > > <petsc-users@mcs.anl.gov> wrote: > > > > Hello, > > > > I ran into an issue while using Mumps from Petsc. I got the following error > > (see below please). Somebody suggested that I compile Petsc with > > --with-64-bit-indices=1. Will that suffice? > > Currently PETSc and MUMPS do not work together with --with-64-bit-indices=1. > > > Also I compiled my own version of Petsc on Cray Onyx (HPCMP) but although I > > compiled --with-debugging=0, Petsc was very very slow (compared to the > > version of Petsc available from the Cray admins). Do you have a list of > > flags that I should compile Petsc with for Cray supercomputers? > > No idea why it would be particularly slower. No way to know what compiler > options they used. > > You also have a choice of different compilers on Cray, perhaps that makes a > difference. > > > > > Thanks, > > > > Anthony > > > > INFOG(1)=-51. I saw in the mumps manual that: > > > > An external ordering (Metis/ParMetis, SCOTCH/PT-SCOTCH, PORD), with 32-bit > > default > > integers, is invoked to processing a graph of size larger than 2^31-1. > > INFO(2) holds the size > > required to store the graph as a number of integer values; > > This is strange. Since PETSc cannot when using 32 bit indices produce such > a large graph I cannot explain how this message was generated. Perhaps there > was an integer overflow > > > > > > > > <Case2_240.o2725922>
