<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 31, 2020 at 10:33 AM Drew Parsons <<a href="mailto:dparsons@debian.org">dparsons@debian.org</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">On 2020-05-27 22:00, Junchao Zhang wrote:<br>
> On Wed, May 27, 2020 at 12:09 AM Drew Parsons <<a href="mailto:dparsons@debian.org" target="_blank">dparsons@debian.org</a>><br>
> wrote:<br>
> <br>
>> On 2020-05-24 10:01, Drew Parsons wrote:<br>
>>> On 2020-05-23 23:45, Satish Balay wrote:<br>
>>>> <br>
>>>> One more issue: Most externalpackages don't support<br>
>> 64bit-indices.<br>
>> ...<br>
>>>> We haven't tried using MUMPS in this mode with PETSc<br>
>>> <br>
>>> This will be the interesting test. I'll start with the 64-bit<br>
>> build of<br>
>>> MUMPS and see how tests hold up.<br>
>> <br>
>> The PETSc mumps tests seem to be robust with respect to 64 bit.<br>
>> (64 bit MUMPS in the form of -DPORD_INTSIZE64, not all-integer<br>
>> -DINTSIZE64)<br>
>> <br>
>> That is, 32 bit PETSc passes its tests with 64 bit (PORD) MUMPS<br>
>> and 64 bit PETSc passes its tests with 32 bit MUMPS.<br>
>> <br>
>> The test in question that's passing is src/snes/tutorials/ex19, run<br>
>> with<br>
>> 'make runex19_fieldsplit_mumps'<br>
>> Perhaps it's not stress-testing 64 bit conditions.<br>
> <br>
> Could you provide more details, e.g., the error stack trace?<br>
<br>
<br>
<br>
Hi Junchao, PETSc's mumps test runs fine, there is no error to trace as <br>
such, just a diff with the reference output.<br>
<br>
With 32-bit PETSc and 64-bit [PORD] MUMPS,<br>
<br>
$ mpirun -n 2 ./ex19 -pc_type fieldsplit -pc_fieldsplit_block_size 4 <br>
-pc_fieldsplit_type SCHUR -pc_fieldsplit_0_fields 0,1,2 <br>
-pc_fieldsplit_1_fields 3 -fieldsplit_0_pc_type lu -fieldsplit_1_pc_type <br>
lu -snes_monitor_short -ksp_monitor_short  <br>
-fieldsplit_0_pc_factor_mat_solver_type mumps <br>
-fieldsplit_1_pc_factor_mat_solver_type mumps<br>
<br>
returns the result:<br>
<br>
lid velocity = 0.0625, prandtl # = 1., grashof # = 1.<br>
   0 SNES Function norm 0.239155<br>
     0 KSP Residual norm 0.235858<br>
     1 KSP Residual norm < 1.e-11<br>
   1 SNES Function norm 6.81968e-05<br>
     0 KSP Residual norm 2.30906e-05<br>
     1 KSP Residual norm < 1.e-11<br>
   2 SNES Function norm < 1.e-11<br>
Number of SNES iterations = 2<br>
<br>
<br>
where output/ex19_fieldsplit_5.out has<br>
<br>
lid velocity = 0.0625, prandtl # = 1., grashof # = 1.<br>
   0 SNES Function norm 0.239155<br>
     0 KSP Residual norm 0.239155<br>
     1 KSP Residual norm < 1.e-11<br>
   1 SNES Function norm 6.81968e-05<br>
     0 KSP Residual norm 6.81968e-05<br>
     1 KSP Residual norm < 1.e-11<br>
   2 SNES Function norm < 1.e-11<br>
Number of SNES iterations = 2<br>
<br>
<br>
So the diff in this case is<br>
<br>
$make runex19_fieldsplit_mumps<br>
3c3<br>
<     0 KSP Residual norm 0.239155<br>
---<br>
>     0 KSP Residual norm 0.235858<br>
6c6<br>
<     0 KSP Residual norm 6.81968e-05<br>
---<br>
>     0 KSP Residual norm 2.30906e-05<br></blockquote><div>I tested it with both 32-bit and 64-bit. They had the same result as yours. It seems we need to update the output file in the repo. I will do it. Thanks.</div><div> </div></div></div>