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>
