<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 21, 2013 at 6:12 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"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="im">
But there is a local and global size. (You had to pick something to<br>
create the Vec.) Therefore, the global space is _defined_ as the<br>
concatenation of all those contiguous local spaces. You need not store<br>
it that way, but the abstract space exists. If you use interfaces that<br>
ask for ISs, they will be with respect to that abstract space.<br>
</div></div></blockquote>
<br>
Ah, I think I wasn't clear about what I mean here by "wrapper".<br>
<br>
Basically, we have a subclass of Vec that knows how to evaluate vector space operations using the "wrapped" SAMRAI data.  For instance, there is no VecGetArray().</blockquote></div><br><br></div><div class="gmail_extra">
I understand that completely, but you cannot create a valid Vec without setting a size. Internally the PetscLayout has a size of -1 on creation and you will get errors if you try to use it without setting a size. Setting a size of 0 is patently dishonest and PETSc could justifiably short-circuit and not call into your implementation. (I don't think we do this, but it would be correct at the vector space level. PETSc Vec is a finite-dimensional thing, therefore it has a well-defined dimension.) I'm saying that you should be honest about the size even if it's not explicitly used in the functionality you happen to be using now. If you define a size, then you can also (optionally) use IS to refer to pieces, which will make interoperability with other codes, or eventual extensions (such as AMG preconditioning) less intrusive.<br>
</div></div>