[petsc-users] Some questions regarding VecNest type.

[Vijay S. Mahadevan]

> Nonsense! That's the point of the MatGetLocalSubMatrix() assembly interface.

Didn't realize that VecGetSubVector/MatGetLocalSubMatrix are the
pervasive implementation agnostic interfaces. Good to know !

> So we can (and should) change this to be like MatNest where you can
> MatCreate(), MatSetType(), MatNestSetSubMats(). But even with the update,
> you will still have to call VecNestSetSubVecs(), so creation is still
> different.

I can live with creation alone being different if the user wants it
so. As long as the access via the above interface is still
transparent, and it provides the ability to update/change the block
references after creation, I can't ask for more.

On Wed, Oct 12, 2011 at 4:41 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Wed, Oct 12, 2011 at 16:26, Vijay S. Mahadevan <vijay.m at gmail.com> wrote:
>>
>> Not fun, yes, but two different code paths are inevitable.
>
> Nonsense! That's the point of the MatGetLocalSubMatrix() assembly interface.
>
>>
>> You can
>> choose to do block solves or monolithic inversions but both do need a
>> different data structure representation. In your example mat X vs Y.
>>
>> Anyway, I was trying to create a simple test case and was stopped
>> immediately in my progress. I found the hard way that VecCreateNest is
>> the only way to create a Nest vector ? The usual
>> VecCreate+SetFromOptions doesn't seem to do the trick.
>
> So we can (and should) change this to be like MatNest where you can
> MatCreate(), MatSetType(), MatNestSetSubMats(). But even with the update,
> you will still have to call VecNestSetSubVecs(), so creation is still
> different. The point of the rest of the interface (e.g. VecGetSubVector()
> instead of VecNestGetSubVecs()) is that *the rest* of your code never
> depends on the implementation.
>