<div class="gmail_quote">On Tue, Oct 11, 2011 at 15:53, 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 class="im">> It would make sense to have VecNestSetSubVec(), but it is not implemented<br>
> yet.<br>
<br>
</div>In src/vec/vec/examples/tests/ex37.c, I see a call to this function<br>
but it is part of dead code.<br>
<br>
I don't see a specialization VecGetSubVector/VecRestoreSubVector in<br>
VecNest</blockquote><div><br></div><div>vecnest.c:639 ?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> and so my related question is if I call VecGetSubVector with<br>
multiple indices,</blockquote><div><br></div><div>What do you mean by multiple indices? The union of multiple constituent index sets? You could make a hierarchical VecNest if you really want that layout, otherwise we need to find an inexpensive way to handle exotic index sets without losing structure.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> do I expect a nested vector back ? And in the case<br>
when the index set has only one entry, perhaps the returned vector is<br>
in the parallel layout of the corresponding block entry. Or does the<br>
returned Vector have a different parallel layout in these cases ?<br></blockquote><div><br></div><div>Same parallel layout, the returned vector has the distribution specified by the IS. The main difference between using VecNest and standard Vec is that the former can have a non-contiguous index set, but store it contiguously in memory, and provide no-copy access to that piece. With a normal Vec, you only get no-copy access if the index space is contiguous. (But usually you choose the ordering of the index space so that related things are nearby, so it should be a good ordering.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
> You get a lot more consistent support if you<br>
> use a standard contiguous Vec type and call VecGetSubVector() or a<br>
> VecScatter when you need to get part of it.<br>
<br>
</div>I used to take this route until I found the block extensions. I feel<br>
it is elegant to handle different physics blocks using the block or<br>
Nest interface specifically since dofs for each physics can be<br>
distributed independently based on its own mesh and other<br>
requirements. IMO, the blocking also makes the solve/preconditioning<br>
for multi-physics problems natural (yes the sparsity pattern for<br>
off-diagonal blocks are tricky). I will also investigate the Nest<br>
independent interface to generalize this access.<br></blockquote><div><br></div><div>With the Nest-independent interface, you access pieces using an IS instead of an integer. I find it quite valuable when comparing algorithms to switch between monolithic formats with Schwarz/coupled multigrid/direct solvers and the Nest format with FieldSplit preconditioners. Since you can write your software so that this choice is a run-time option, I don't see a good rationale for choosing an interface that only does one thing.</div>
</div>