<div dir="ltr">I interpreted Danial's question as referring to small block sizes for multi-dof per point/vertex/cell in the mesh, like Satish, but please clarify.<br><div><br></div><div>With that assumption, as you know PETSc does not support explicit variable block sizes, like ML does for instance, but the conventional wisdom has been that inodes do a pretty good job of exploiting block structure for performance as Satish mentioned. </div><div><br></div><div>It would be great to get some data from modern processors to quantify this. If your solver is in fact memory bandwidth bound, as it should be, then if you test a problem with constant block size >= 3 you should see the solver takes almost 50% longer if you turn inodes off. This test would give some sense of how well inodes are working for you.</div><div><br></div><div>Mark</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 24, 2023 at 9:43 AM Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Jul 24, 2023 at 6:34 AM Daniel Stone <<a href="mailto:daniel.stone@opengosim.com" target="_blank">daniel.stone@opengosim.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello PETSc Users/Developers,</div><div><br></div><div>A collegue of mine is looking into implementing an adaptive implicit method (AIM) over</div><div>PETSc in our simulator. This has led to some interesting questions about what can</div><div>be done with blocked matrices, which I'm not able to answer myself - does anyone have</div><div>any insight?</div><div><br></div><div>Apparently it would be ideal if we could find a matrix (and vector) type that supports a kind</div><div>of mixed block size:</div><div><br></div><div>
"For AIM [...] we will have matrix elements of various 
shapes: 1x1, 1xN, Nx1 and NxN. [...]. The 
solution and residual will be a mix of 1 and N variable/cell block"</div></div></blockquote><div><br></div><div>This is not the terminology we would use, since "blocksize" is usually understood as something small</div><div>that is used for vectorization and indexing. These are large, O(N), and require different implementation.</div><div>To build matrices out of these parts, you can use</div><div><br></div><div>  1) MatNest: Very small blocks are not ideal here, so</div><div><br></div><div>  2) MatLRC: This is for low-rank corrections, which is where small matrices tend to arise</div><div><br></div><div>Does this make sense?</div><div><br></div><div>  Thanks,</div><div><br></div><div>    Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>There are ideas for how to implement what we want using the fixed-block-size objects we</div><div>understand well, but if anything like the above exists it would be very exciting.</div><div><br></div><div><br></div><div>Thanks,</div><div><br></div><div>Daniel<br>

</div></div>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><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><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>
</blockquote></div>