<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Apr 6, 2015 at 3:59 PM, 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">
<div bgcolor="#FFFFFF" text="#000000">
Hi Matt<span class=""><br>
<br>
<div>On 4/6/2015 6:49 AM, Matthew Knepley
wrote:<br>
</div>
<blockquote type="cite">
<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/matrix.c MatMatMatMult
requires A, seqaij, to be compatible with B, mpiaij, C,
seqaij<br>
MatMatMatMult() line 9173 in
/opt/petsc/src/mat/interface/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>
</div>
</blockquote>
<br></span>
Okay, this is what I thought was the problem. It is really a matter
of making sure we have the correct information on each processor. <br><span class="">
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote></span>
It does, but I am unsure how to get the partitioning of the coarser
grids since we don't deal with them directly. Is it safe to assume
that the partitioning on the coarser grid will always overlap with
the same part of the domain as the fine level? In other words, the
current processor will receive the coarse grid that is formed by the
portion of the restriction matrix that it owns, right?<br></div></blockquote><div><br></div><div>You can get the coarse grid by calling DMCoarsen(), just like the AMG will do. Then you can ask the coverage questions</div><div>directly to the DMDA. I don't remember exactly what we guarantee with regard to coverage of the fine grid by the coarse.</div><div>Maybe Jed does since he jsut rewrote this for the HPGMG benchmark.</div><div><br></div><div> Thanks,</div><div><br></div><div> MAtt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
Thanks!<br>
Eric<span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>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>
</blockquote>
<br>
</span><span class="HOEnZb"><font color="#888888"><pre cols="72">--
*************************************
Eric Mittelstaedt, Ph.D.
Assistant Professor
Dept. of Geological Sciences
University of Idaho
email: <a href="mailto:emittelstaedt@uidaho.edu" target="_blank">emittelstaedt@uidaho.edu</a>
phone: <a href="tel:%28208%29%20885%202045" value="+12088852045" target="_blank">(208) 885 2045</a>
<a href="http://scholar.google.com/citations?user=DvRzEqkAAAAJ" target="_blank">http://scholar.google.com/citations?user=DvRzEqkAAAAJ</a>
*************************************
</pre>
</font></span></div>
</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>