[petsc-dev] VecNestSetSubVec for VecNest.

Vijay S. Mahadevan vijay.m at gmail.com
Sun Oct 16 15:23:01 CDT 2011


> Let's wait on optimizing until we have a use case where it matters. Since
> everything else expects data structures to be rebuilt if anything changes, I
> don't think it's a concern just yet. If we allow more resizing in the
> future, we can optimize this routine.

Agreed. No need for premature optimization.

I do find the flow of creating a Nest vector odd now that the
SetSubVec* are in place. Because due to the VecCreateNest signature,
you still need to provide a set of vectors to create the leaf nodes.
Perhaps it might be useful to modify this signature to conform to the
usual strategy now ? i.e., VecCreate(), VecSetSizes(), VecSetType(),
VecSetFromOptions(), VecSetSubVecs(), VecAssemblyBegin/End() ?

On Sun, Oct 16, 2011 at 11:25 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Sat, Oct 15, 2011 at 10:12, Vijay S. Mahadevan <vijay.m at gmail.com> wrote:
>>
>> Find attached the bundle with the changes for
>> VecNestSetSubVec/VecNestSetSubVecs. The test file and the outputs are
>> also included in the bundle. Feel free to modify the documentation if
>> need be.
>
> Thanks, applied.
>
>>
>> The only thing that I think needs a better implementation is the
>> SetSubVecs where I've just looped over the indices and recursively
>> called the single SetSubVec. This was hard to optimize since
>> accommodating variable vectors involves traversing the IS one by one
>> and I couldn't figure out a way to implement this concurrently.
>> Anyway, if you can think of something better, let me know.
>
> Let's wait on optimizing until we have a use case where it matters. Since
> everything else expects data structures to be rebuilt if anything changes, I
> don't think it's a concern just yet. If we allow more resizing in the
> future, we can optimize this routine.



More information about the petsc-dev mailing list