On Wed, Feb 15, 2012 at 9:14 PM, Sylvain Barbot <span dir="ltr">&lt;<a href="mailto:sylbar.vainbot@gmail.com">sylbar.vainbot@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; R-B has crappy cache performance since you alternately pull data but ignore<br>
&gt; half of it.<br>
<br>
Understood.<br>
<br>
&gt; Why not just use the GMG in PETSc? Its very flexible, scalable,<br>
&gt; and efficient.<br>
<br>
I tried to use Petsc&#39;s implementation of multigrid, cf thread &quot;V-cycle<br>
multigrid with matrix shells&quot;. My concern is performance. I&#39;d like the<br>
whole procedure to use matrix shells, or &quot;matrix-free&quot; matrices,<br>
because my stencil can have up to 21 off-diagonal terms. Petsc 3.1 did<br>
not allow this functionality. I do not know what Petsc 3.2 has to<br>
offer in that regard.<br></blockquote><div><br></div><div>So you want to calculate the action to avoid the memory bandwidth limit? If so,</div><div>you can still use MG by specifying the coarse operators as MatShells, rather than</div>
<div>using Galerkin. You might want to tweak the interpolator later if it is inadequate.</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">

I have a working multi-grid method that uses the low functionality of<br>
Petsc. I would obviously prefer if I could use something more<br>
advanced.<br>
<br>
Cheers,<br>
Sylvain<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>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<br>