[petsc-users] Some questions regarding VecNest type.

[Jed Brown]

On Tue, Oct 11, 2011 at 15:53, Vijay S. Mahadevan <vijay.m at gmail.com> wrote:

> > It would make sense to have VecNestSetSubVec(), but it is not implemented
> > yet.
>
> In src/vec/vec/examples/tests/ex37.c, I see a call to this function
> but it is part of dead code.
>
> I don't see a specialization VecGetSubVector/VecRestoreSubVector in
> VecNest


vecnest.c:639 ?


> and so my related question is if I call VecGetSubVector with
> multiple indices,


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.


> do I expect a nested vector back ? And in the case
> when the index set has only one entry, perhaps the returned vector is
> in the parallel layout of the corresponding block entry. Or does the
> returned Vector have a different parallel layout in these cases ?
>

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.)


>
> > 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.
>
> I used to take this route until I found the block extensions. I feel
> it is elegant to handle different physics blocks using the block or
> Nest interface specifically since dofs for each physics can be
> distributed independently based on its own mesh and other
> requirements. IMO, the blocking also makes the solve/preconditioning
> for multi-physics problems natural (yes the sparsity pattern for
> off-diagonal blocks are tricky). I will also investigate the Nest
> independent interface to generalize this access.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20111012/ea333661/attachment.htm>