<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Karli,
<div class=""><br class="">
</div>
<div class="">Thank you for offering help to clean up. I have no objection.</div>
<div class=""><br class="">
</div>
<div class="">We have thought about subclassing long before. As Barry suggested, an ideal solution is to make a base class (XAIJ ?) for <span style="color: rgb(23, 43, 77); font-family: -apple-system, system-ui, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-variant-ligatures: normal; letter-spacing: -0.07px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255);" class="">AIJ,
BAIJ, SBAIJ, and SELL. The base class will have diagonal and off diagonal parts without binding their storage format to CSR-type. This requires a lot of efforts to refactor the current AIJ. But I think we should eventually do it.</span></div>
<div class=""><span style="color: rgb(23, 43, 77); font-family: -apple-system, system-ui, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-variant-ligatures: normal; letter-spacing: -0.07px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255);" class=""><br class="">
</span></div>
<div class=""><span style="color: rgb(23, 43, 77); font-family: -apple-system, system-ui, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-variant-ligatures: normal; letter-spacing: -0.07px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255);" class="">Thanks,</span></div>
<div class=""><span style="color: rgb(23, 43, 77); font-family: -apple-system, system-ui, "Segoe UI", Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif; font-variant-ligatures: normal; letter-spacing: -0.07px; orphans: 2; widows: 2; background-color: rgb(255, 255, 255);" class="">Hong
(Mr.)</span></div>
<div class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Mar 4, 2018, at 4:58 AM, Karl Rupp <<a href="mailto:rupp@iue.tuwien.ac.at" class="">rupp@iue.tuwien.ac.at</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hi all,<br class="">
<br class="">
I'm getting increasingly concerned about SELL not being a subclass of AIJ. As such, we have to deal with all these fallback operations now, whereas as a subclass of AIJ we could just selectively make use of the SELL format where we really benefit from it. "Use
AIJ by default unless we have something optimized for SELL" is just much more appropriate for the few use cases of SELL than the current "SELL has to implement everything and usually this means to manually convert back to AIJ".<br class="">
<br class="">
If there are no objections I'd like to clean this up. (Subclassing AIJ was unfortunately not available at the time Hong started his great work on SELL)<br class="">
<br class="">
Best regards,<br class="">
Karli<br class="">
<br class="">
<br class="">
<br class="">
On 03/03/2018 07:52 AM, Richard Tran Mills wrote:<br class="">
<blockquote type="cite" class="">Resurrecting a few weeks old thread:<br class="">
Stefano, did you get around to coding something up to do an automatic conversion to SeqAIJ for operations unsupported by SELL format? I did some hacking the other day to try to get PCGAMG to use SELL inside the smoothers and this turns out to be way more complicated
than I'd like and very bug prone (I haven't found all of mine, anyway). I think it may be preferable to be able to pass a SELL matrix to PCGAMG and have an internal conversion happen in the SELL matrix to AIJ format for doing the MatPtAP and LU solves. Support
for this would certainly make it easier for users in a lot other cases as well, and might make the use of SELL much more likely. If no one has already done some work on this, I'll take a stab at it.<br class="">
--Richard<br class="">
On Mon, Feb 12, 2018 at 10:04 AM, Richard Tran Mills <<a href="mailto:rtmills@anl.gov" class="">rtmills@anl.gov</a> <<a href="mailto:rtmills@anl.gov" class="">mailto:rtmills@anl.gov</a>>> wrote:<br class="">
On Mon, Feb 12, 2018 at 8:47 AM, Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov" class="">bsmith@mcs.anl.gov</a><br class="">
<<a href="mailto:bsmith@mcs.anl.gov" class="">mailto:bsmith@mcs.anl.gov</a>>> wrote:<br class="">
> On Feb 12, 2018, at 10:25 AM, Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com" class="">stefano.zampini@gmail.com</a> <<a href="mailto:stefano.zampini@gmail.com" class="">mailto:stefano.zampini@gmail.com</a>>> wrote:<br class="">
><br class="">
> Barry,<br class="">
><br class="">
> for sure Amat,Pmat is the right approach; however, with complicated user codes, we are not always in control of having a different Jacobian matrix.<br class="">
> Since Mat*SELL does not currently support any preconditioning except PCSOR and PCJACOBI, we ask the user to put codes like<br class="">
><br class="">
> if (type is SELL)<br class="">
> create two matrices (and maybe modify the code in many other parts)<br class="">
> else<br class="">
> ok with the previous code<br class="">
I don't disagree with what you are saying and am not opposed<br class="">
to the proposed work.<br class="">
Perhaps we need to do a better job with making the mat,pmat<br class="">
approach simpler or better documented so more people use it<br class="">
naturally in their applications.<br class="">
I wrote some code like that in some of the Jacobian/function<br class="">
routines in PFLOTRAN to experiment with MATSELL, and it works, but<br class="">
looks and feels pretty hacky. And if I wanted to support it for all<br class="">
of the different systems that PFLOTRAN can model, then I'd have to<br class="">
reproduce that it in many different Jacobian and function evaluation<br class="">
routines. I also don't like that it makes it awkward to play with<br class="">
the many combinations of matrix types and preconditioners that PETSc<br class="">
allows: The above pseudocode should really say "if (type is SELL)<br class="">
and (preconditioner is not PCSOR or PCJACOBI)". I do think that<br class="">
Amat,Pmat is a good approach in many situations, but it's easy to<br class="">
construct scenarios in which it falls short.<br class="">
In some situations, what I'd like to have happen is what Stefano is<br class="">
talking about, with an automatic conversion to AIJ happening if SELL<br class="">
doesn't support an operation. But, ideally, I think this sort of<br class="">
implicit format conversion shouldn't be something hard-coded into<br class="">
the workings of SELL. Instead, there should be some general<br class="">
mechanism by which PETSc recognizes that a particular operation is<br class="">
unsupported for a given matrix format, and then it can (optionally)<br class="">
copy/convert to a different matrix type (probably default to AIJ,<br class="">
but it shouldn't have to be AIJ) that supports the operation. This<br class="">
sort of implicit data rearrangement game may actually become more<br class="">
important if future computer architectures strongly prefer different<br class="">
data layouts different types of operations (though let's not get<br class="">
ahead of ourselves).<br class="">
--Richard<br class="">
Barry<br class="">
><br class="">
> Just my two cents.<br class="">
><br class="">
><br class="">
> 2018-02-12 19:10 GMT+03:00 Smith, Barry F.<br class="">
<<a href="mailto:bsmith@mcs.anl.gov" class="">bsmith@mcs.anl.gov</a> <<a href="mailto:bsmith@mcs.anl.gov" class="">mailto:bsmith@mcs.anl.gov</a>>>:<br class="">
><br class="">
><br class="">
> > On Feb 12, 2018, at 9:59 AM, Stefano Zampini<br class="">
<<a href="mailto:stefano.zampini@gmail.com" class="">stefano.zampini@gmail.com</a> <<a href="mailto:stefano.zampini@gmail.com" class="">mailto:stefano.zampini@gmail.com</a>>><br class="">
wrote:<br class="">
> ><br class="">
> > FYI, I just checked and MatSOR_*SELL does not use any<br class="">
vectorized instruction.<br class="">
> > Why just not converting to SeqAIJ, factor and then use the<br class="">
AIJ implementation for MatSolve for the moment?<br class="">
><br class="">
> Why not use the mat, pmat feature of the solvers to pass in<br class="">
both matrices and have the solvers handle using two formats<br class="">
simultaneously instead of burdening the MatSELL code with tons<br class="">
of special code for automatically converting to AIJ for solvers etc?<br class="">
><br class="">
><br class="">
> ><br class="">
> > 2018-02-12 18:06 GMT+03:00 Stefano Zampini<br class="">
<<a href="mailto:stefano.zampini@gmail.com" class="">stefano.zampini@gmail.com</a> <<a href="mailto:stefano.zampini@gmail.com" class="">mailto:stefano.zampini@gmail.com</a>>>:<br class="">
> ><br class="">
> ><br class="">
> > 2018-02-12 17:36 GMT+03:00 Jed Brown <<a href="mailto:jed@jedbrown.org" class="">jed@jedbrown.org</a><br class="">
<<a href="mailto:jed@jedbrown.org" class="">mailto:jed@jedbrown.org</a>>>:<br class="">
> > Karl Rupp <<a href="mailto:rupp@iue.tuwien.ac.at" class="">rupp@iue.tuwien.ac.at</a><br class="">
<<a href="mailto:rupp@iue.tuwien.ac.at" class="">mailto:rupp@iue.tuwien.ac.at</a>>> writes:<br class="">
> ><br class="">
> > > Hi Stefano,<br class="">
> > ><br class="">
> > >> Is there any plan to write code for native ILU/ICC etc<br class="">
for SeqSELL, at least to have BJACOBI in parallel?<br class="">
> > ><br class="">
> > > (imho) ILU/ICC is a pain to do with SeqSELL. Point-Jacobi<br class="">
should be<br class="">
> > > possible, yes. SELL is really just tailored to MatMults<br class="">
and a pain for<br class="">
> > > anything that is not very similar to a MatMult...<br class="">
> ><br class="">
> > There is already MatSOR_*SELL. MatSolve_SeqSELL wouldn't<br class="">
be any harder.<br class="">
> > I think it would be acceptable to convert to SeqAIJ,<br class="">
factor, and convert<br class="">
> > the factors back to SELL.<br class="">
> ><br class="">
> > Yes, this was my idea. Today I have started coding<br class="">
something. I'll push the branch whenever I have anything working<br class="">
> ><br class="">
> ><br class="">
> ><br class="">
> > --<br class="">
> > Stefano<br class="">
> ><br class="">
> ><br class="">
> ><br class="">
> > --<br class="">
> > Stefano<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> --<br class="">
> Stefano<br class="">
</blockquote>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>