<div class="gmail_quote">On Tue, Oct 11, 2011 at 00:16, 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;">
I understand that the Vec/Mat Nest types in the current release of<br>
petsc are designed to be similar in philosophy to Dave May's petsc-ext<br>
"block" vectors and matrices.</blockquote><div><br></div><div>They have a similar data structure, but have an interface that interoperates better, so they should replace petsc-ext.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I have some existing code based on<br>
petsc-ext and am trying to figure out the amount of work involved to<br>
make a transition from petsc-ext to pure petsc (>=3.2).<br>
<br>
Here are a list of my questions after looking at the VecNest type:<br>
<br>
1) Does VecDuplicate create a shallow or deep copy ? i.e., are all<br>
leaf vectors/matrices recreated based on a recursive duplicate or does<br>
it only replicate the higher level structure ?<br></blockquote><div><br></div><div>Deep copy. A shallow copy would not be semantically correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2) Do I need to restore the references after I get the vectors ? Say<br>
VecNestGetSubVecs and something along the lines of<br>
VecNestRestoreSubVecs (I dont see such a routine though) ? Or is this<br>
unnecessary ?<br></blockquote><div><br></div><div>VecNestGetSubVecs() gives you direct access to the data structure. It does not increment a reference and does not need to be restored. You should prefer to use VecGetSubVector() which works for any Vec type and still gives you a cheap (no-copy) reference for VecNest.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
3) Is there a way to lazily set the reference to one of the vectors<br>
that is part of the nest structure ? Or does it always have to be<br>
specified during creation of VECNEST ? I see that this is not the case<br>
for matrices since there is a MatNestSetSubMats but I don't see<br>
something similar for Vec. Can this be handled via VecNestGetSubVecs ?<br>
In petsc-ext, there was a function that handled VecBlockSetValue and I<br>
guess I am looking for a suitable replacement, if that shows better<br>
light on the context.<br></blockquote><div><br></div><div>Even with Mat, you are only supposed to call this once (at setup time). If it doesn't check for this, it should. It could be modified to be safe to call more than once, but is not currently. The single-Mat function MatNestSetSubMat() does exist and is safe to call multiple times.</div>
<div><br></div><div>It would make sense to have VecNestSetSubVec(), but it is not implemented yet.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
4) Are there any examples that make use of the VecNest type ? Even a<br>
trivial one might help clarify some trouble I'm having in<br>
understanding calling sequence.<br></blockquote><div><br></div><div>In general, I don't recommend using VecNest unless it's very, very important to you that fields with some interlaced ordering actually be stored separately (or you have very specific requirements about in-place ghost updates for individual fields). You get a lot more consistent support if you use a standard contiguous Vec type and call VecGetSubVector() or a VecScatter when you need to get part of it. If you write code this way, you'll be able to use -dm_vec_type nest sometime and see if it helps performance.</div>
<div><br></div><div>If after the above, you are still dedicated to needless pain, check the tests for usage of the internal interfaces.</div><div><br></div><div><div>$ grep -l VecNest src/**/examples/**/*.c</div><div>src/ksp/ksp/examples/tests/ex22.c</div>
<div>src/snes/examples/tests/ex17.c</div><div>src/vec/vec/examples/tests/ex37.c</div></div><div> </div><div><br></div><div>Note: MatNest is far more useful because the data structure tradeoffs are more significant when using PCFieldSplit. Again, you should try to avoid ever using the MatNest() interface directly. Instead, you can use MatGetLocalSubMatrix(). See src/snes/examples/tutorials/ex28.c, make runex28_3 for usage of MatNest without ever referencing it in the code.</div>
<div><br></div><div>Note that there is still a preallocation interface challenge for off-diagonal blocks when using MatNest in a multiphysics application.</div></div>