<div class="gmail_quote">On Wed, Oct 12, 2011 at 16:26, Vijay S. Mahadevan <span dir="ltr"><<a href="mailto:vijay.m@gmail.com">vijay.m@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":2h9">Not fun, yes, but two different code paths are inevitable. </div></blockquote><div><br></div><div>Nonsense! That's the point of the MatGetLocalSubMatrix() assembly interface.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":2h9">You can<br>
choose to do block solves or monolithic inversions but both do need a<br>
different data structure representation. In your example mat X vs Y.<br>
<br>
Anyway, I was trying to create a simple test case and was stopped<br>
immediately in my progress. I found the hard way that VecCreateNest is<br>
the only way to create a Nest vector ? The usual<br>
VecCreate+SetFromOptions doesn't seem to do the trick.</div></blockquote><div><br></div><div>So we can (and should) change this to be like MatNest where you can MatCreate(), MatSetType(), MatNestSetSubMats(). But even with the update, you will still have to call VecNestSetSubVecs(), so creation is still different. The point of the rest of the interface (e.g. VecGetSubVector() instead of VecNestGetSubVecs()) is that *the rest* of your code never depends on the implementation.</div>
<div><br></div></div>