[petsc-dev] Multigrid is confusing

[Jed Brown]

On Thu, May 24, 2012 at 6:26 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

> > So do we manage blocks using internal C++ templates, "templates in C", C
> generated using some other system (m4 anyone?), or something else entirely?
> >
> > Yes! Finally, we acknowledge that this a problem.
> >
> > 1) C++ templates are not a solution to anything. ANYTHING.
> >
> > 2) I am assuming "templates in C" would work somewhat like a templating
> engine.
> >     I tried this for the last TOMS paper with Andy. Its was just not a
> big payoff for
> >     the work put in, and definitely did not justify incorporating
> another package.
> >
> > 3) I prefer C generated from another system, like the one I use for FEM
> (which I am
> >     not attached to). We will definitely need this for GPU kernels, and
> I am guessing
> >     thread kernels if they are going to be worth something.
> >
>
>     For this particular example (and perhaps many others for sparse
> matrices) it is a matter of writing "the same algorithm" for a different
> data structure (the split storage). Perhaps what is needed is a "sparse
> matrix/graph/mesh" language, for which one can write kernels/code fragments
> "independent of the data structure"  from which C/whatever is generated?
> But I don't have a clue what the language would look like.  I think a
> general purpose tool (for example templates) is unlikely to be useful for
> us.


Haven't we already identified most of these primitives? Doesn't it
generally come down to selecting a (block) row (upper, lower, or the entire
thing) and applying a blocked sparse-dense-{minus,plus}-dot?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120524/2fc49e2c/attachment.html>