<div dir="ltr"><div dir="ltr">On Sat, Mar 27, 2021 at 10:55 AM Fande Kong <<a href="mailto:fdkong.jd@gmail.com">fdkong.jd@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">There are some statements from MUMPS user manual <a href="http://mumps.enseeiht.fr/doc/userguide_5.3.5.pdf" target="_blank">http://mumps.enseeiht.fr/doc/userguide_5.3.5.pdf</a><div><br></div><div>"</div><div>A full 64-bit integer version can be obtained compiling MUMPS with C preprocessing flag -DINTSIZE64 and Fortran compiler option -i8, -fdefault-integer-8 or something equivalent depending on your compiler, and compiling all libraries including MPI, BLACS, ScaLAPACK, LAPACK and BLAS also with 64-bit integers. We refer the reader to the “INSTALL” file provided with the package for details and explanations of the compilation flags controlling integer sizes.<br></div><div>"</div><div><br></div><div>It seems possible to build a full-64-bit-integer version of MUMPS. However, I do not understand how to build MPI with 64-bit integer support. From my understanding, MPI is hard coded with an integer type (int), and there is no way to make "int" become "long" .</div></div></div></div></blockquote><div><br></div><div>We had a long conversation with the MUMPs developers about this and are aware of what it does.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Thanks,</div><div><br></div><div>Fande</div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 23, 2021 at 12:20 PM Sanjay Govindjee <<a href="mailto:s_g@berkeley.edu" target="_blank">s_g@berkeley.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
I agree. If you are mixing C and Fortran, everything is <i>nota
bene. </i>It is easy to miss argument mismatches.<br>
-sanjay<br>
<br>
<div>On 3/23/21 11:04 AM, Barry Smith wrote:<br>
</div>
<blockquote type="cite">
<div><br>
</div>
In a pure Fortran code using -fdefault-integer-8 is probably
fine. But MUMPS is a mixture of Fortran and C code and PETSc uses
MUMPs C interface. The -fdefault-integer-8 doesn't magically fix
anything in the C parts of MUMPS. I also don't know about MPI
calls and if they would need editing.
<div><br>
</div>
<div> I am not saying it is impossible to get it to
work but one needs are to insure the C portions also switch to
64 bit integers in a consistent way. This may be all doable bit
is not simply using -fdefault-integer-8 on MUMPS.</div>
<div><br>
</div>
<div> Barry</div>
<div><br>
<div><br>
<blockquote type="cite">
<div>On Mar 23, 2021, at 12:07 AM, Sanjay Govindjee
<<a href="mailto:s_g@berkeley.edu" target="_blank">s_g@berkeley.edu</a>> wrote:</div>
<br>
<div>
<div> Barry,<br>
I am curious about your statement "does not work
generically". If I compile with -fdefault-integer-8,<br>
I would assume that this produces objects/libraries that
will use 64bit integers. As long as I have not declared<br>
explicit kind=4 integers, what else could go wrong.<br>
-sanjay<br>
<br>
PS: I am not advocating this as a great idea, but I am
curious if there or other obscure compiler level things
that could go wrong. <br>
<br>
<br>
<div>On 3/22/21 8:53 PM, Barry
Smith wrote:<br>
</div>
<blockquote type="cite">
<br>
<div><br>
<blockquote type="cite">
<div>On Mar 22, 2021, at 3:24 PM, Junchao
Zhang <<a href="mailto:junchao.zhang@gmail.com" target="_blank">junchao.zhang@gmail.com</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div dir="ltr"><br>
<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon,
Mar 22, 2021 at 1:39 PM Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank">bsmith@petsc.dev</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div><br>
</div>
Version of PETSc and MUMPS? We fixed
a bug in MUMPs a couple years ago that
produced error messages as below. Please
confirm you are using the latest PETSc
and MUMPS.
<div><br>
</div>
<div> You can run your
production version with the option
-malloc_debug ; this will slow it down
a bit but if there is memory
corruption it may detect it and
indicate the problematic error. </div>
<div><br>
</div>
<div> One also has to be
careful about the size of the problem
passed to MUMPs since PETSc/MUMPs does
not fully support using all 64 bit
integers. Is it only crashing for
problems near 2 billion entries in the
sparse matrix?</div>
</div>
</blockquote>
<div> "problems near 2 billion
entries"? I don't understand. Should not
be an issue if building petsc with 64-bit
indices.</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
MUMPS does not have proper support for 64 bit
indices. It relies on add-hoc Fortran compiler
command line options to support to converting
integer to 64 bit integers and does not work
generically. Yes, Fortran lovers have been doing
this for 30 years inside their applications but it
does not really work in a library environment. But
then a big feature of Fortran is "who needs
libraries, we just write all the code we need"
(except Eispack,Linpack,LAPACK :=-).</div>
<div><br>
<blockquote type="cite">
<div>
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div><br>
</div>
<div> valgrind is the gold
standard for detecting memory
corruption. </div>
<div><br>
</div>
<div>Barry</div>
<div><br>
<div><br>
<blockquote type="cite">
<div>On Mar 22, 2021, at
12:56 PM, Chris Hewson <<a href="mailto:chris@resfrac.com" target="_blank">chris@resfrac.com</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">Hi All,
<div><br>
</div>
<div>I have been
having a problem with MUMPS
randomly crashing in our
program and causing the
entire program to crash. I
am compiling in -O2
optimization mode and using
--download-mumps etc. to
compile PETSc. If I rerun
the program, 95%+ of the
time I can't reproduce the
error. It seems to be a
similar issue to this
thread:</div>
<div><br>
</div>
<div><a href="https://lists.mcs.anl.gov/pipermail/petsc-users/2018-October/036372.html" target="_blank">https://lists.mcs.anl.gov/pipermail/petsc-users/2018-October/036372.html</a></div>
<div><br>
</div>
<div>Similar to the
resolution there I am going
to try and increase icntl_14
and see if that resolves the
issue. Any other thoughts on
this?</div>
<div><br>
</div>
<div>Thanks,</div>
<div>
<div>
<div dir="ltr">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr"><b><br>
</b></div>
<div dir="ltr"><b>Chris
Hewson</b>
<div>Senior
Reservoir
Simulation
Engineer</div>
<div>ResFrac</div>
<div>+1.587.575.9792</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>