<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 6, 2015 at 12:16 AM, Eric Mittelstaedt <span dir="ltr"><<a href="mailto:emittelstaedt@uidaho.edu" target="_blank">emittelstaedt@uidaho.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
   We are working on implementing restriction and prolongation operators for algebraic multigrid in our finite difference (staggered grid) code that solves the incompressible Stokes problem.  So far, the restriction and prolongation operators we have assembled in serial can successfully solve on a simple 2D grid with multiple-level v-cycles.  However, we are running into problems when we attempt to progress to parallel solves.  One of the primary errors we run into is an incompatibility in matrix types for MatMatMatMult and similar calls:<br>
<br>
[0]PETSC ERROR: [1]PETSC ERROR: MatMatMatMult() line 9173 in /opt/petsc/src/mat/interface/<u></u>matrix.c MatMatMatMult requires A, seqaij, to be compatible with B, mpiaij, C, seqaij<br>
MatMatMatMult() line 9173 in /opt/petsc/src/mat/interface/<u></u>matrix.c MatMatMatMult requires A, seqaij, to be compatible with B, mpiaij, C, seqaij<br>
<br>
<br>
The root cause of this is likely the matrix types we chose for restriction and prolongation. To ease calculation of our restriction (R) and prolongation (P) matrices, we have created them as sparse, sequential matrices (SEQAIJ) that are identical on all procs.  Will this matrix type actually work for R and P operators in parallel?<br></blockquote><div><br></div><div>You need to create them as parallel matrices, MPIAIJ for example, that have the same layout as the system matrix.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It seem that setting this matrix type correctly is the heart of our problem.  Originally, we chose SEQAIJ because we want to let Petsc deal with partitioning of the grid on multiple processors.  If we do this, however, we don't know a priori whether Petsc will place a processor boundary on an even or odd nodal point.  This makes determining the processor bounds on the subsequent coarse levels difficult.  One method for resolving this may be to handle the partitioning ourselves, but it would be nice to avoid this if possible. Is there a better way to set up these operators?<br></blockquote><div><br></div><div>You use the same partitioning as the system matrices on the two levels. Does this makes sense?</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thank you,<br>
Eric and Arthur<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">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></div>