<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Mar 16, 2010, at 1:12 PM, Matthew Knepley wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Tue, Mar 16, 2010 at 1:51 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></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;"> <div class="im"><br> On Mar 16, 2010, at 11:28 AM, Matthew Knepley wrote:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> There is a request to make a more memory efficient version of ASM for running<br> very large system of equations. They are using LU on small diagonal blocks, and<br> have asked that the blocks be factored, applied, and discarded, rather than being<br> saved for all iterations. Does anyone think this is easy in the current ASM code?<br> Have an alternate proposal?<br> </blockquote> <br></div> I need a better understanding. Is it that after the KSPSolve() they want more memory available for their own use that they will allocate after the KSPSolve and free before the next PCSetUp()? If this is what they want then I think it is trivial to implement, but we will need an API so that they can say when they are done with the solves and want us to free up the memory.<br> <br> Normally ASM is memory intense because<br> 1) it makes copies of the matrix subblocks<br> 2) it factors those subblocks into additional memory.<br> <br> If you use ILU(0) and the inplace option then it only needs one copy of the blocks instead of the two.</blockquote><div><br></div><div>Yes, told them that so 1/2 off memory. I guess the easiest way to give them this might be to put a shell matrix in the KSP</div> <div>that sucks out the submatrix, factors it in place, applies it, and discards it.</div></div></blockquote><div><br></div> For each application of PCApply() you reform the beasty and factor it?</div><div><br></div><div> I've thought a little bit about the case of tiny overlapping blocks before. Then even all the IS's start to be large memory consumers.</div><div><br></div><div> It may be that we want a COMPLETELY different implementation of ASM for tiny blocks; in the same way as for Jacobi/SOR we have separate implementation and don't just use block Jacobi (PCBJACOBI) and have tons of tiny blocks. Also, with tiny block ASM you probably want to do a multiplicative version instead of an additive version to SOR like instead of Jacobi like. I don't see using a shell matrix to do this, just a completely different PC.</div><div><br></div><div> Barry<br><blockquote type="cite"><div class="gmail_quote"><div><br></div><div>Here is the motivation:</div><div><br></div><div> You have a preconditioner which is ASM, but with a LOT of small blocks. You do not save very much by discarding one</div> <div>big block, but if you only ever form each small block, you get a lot of savings.</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;"> <font color="#888888"><br> Barry</font><div><div></div><div class="h5"><br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> Matt<br> <br> -- <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> </blockquote> <br> </div></div></blockquote></div><br><br clear="all"><br>-- <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></blockquote></div><br></body></html>