<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 21, 2013 at 6:22 PM, Boyce Griffith <span dir="ltr"><<a href="mailto:griffith@cims.nyu.edu" target="_blank">griffith@cims.nyu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3j4">For better or for worse, the "size" of the wrapped data can change dynamically. </div></blockquote>
<div><br></div><div>Then your operators are not linear.<br><br></div><div>If you are in a Vec implementation, you should be able to PetscLayoutSetSize(vec->map,newN).<br><br></div><div>Changing the size dynamically without telling anyone is dangerous in the sense that it violates the API so you're totally on your own if it's breaking. Many things will work, but when I write software, I like to write it so that it works because it's correct, not just so that it works on my machine with a specific compiler, etc. If you want your code to work because it's correct, then you should only change the size at well-defined places,  call KSPReset() or whatever, and generally follow the API.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3j4"> Somehow it seems less dishonest to set the size to 0 instead of, e.g., 1.  At least when you get 0 you know that the size is bogus!  :-)  We've been using this stuff for ... a while now, and it hasn't caused any problems.<br>

<br>
That said, I would prefer to have tighter integration with PETSc.  I think that DMComposite is what I was thinking might work.</div></blockquote></div><br></div><div class="gmail_extra">DMComposite is sort of tied to contiguous memory. In its current form, you'd have to implement VecGetArray() and VecPlaceArray().<br>
</div></div>