<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 21, 2013 at 6:31 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote>
</div><br><br></div><div class="gmail_extra">The issue here is by stating a size like 0, you're violating the contract, so anything could go wrong. Now perhaps PETSc Vecs should be generalized so that the interface supports a concept of "unknown" dimension. In that case, you would identify your Vecs as having unknown size and we would be obliged to respect it. If we make that conceptual change, we'd need to think carefully about any places in PETSc that would be broken in such circumstances. Such a generalization might involve zero lines of code (though realistically, we'd modify the validation code to find bugs from broken assemptions), but it's something that would have to be decided if you don't want a future release of PETSc to break your implementation.<br>
</div></div>