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