As far as I can tell, the "local form" idea implies some mesh with a stencil or overlap behind a Vec, which by itself is a purely algebraic construct. Does this mean that we are injecting some geometry into Vec's semantics?
On Tue, Dec 7, 2010 at 2:20 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > On Dec 7, 2010, at 1:59 PM, Jed Brown wrote: > > > On Tue, Dec 7, 2010 at 20:53, Barry Smith <bsmith at mcs.anl.gov> wrote: > > BTW: I consider the DMDA Vec just a very special case that gets way to > much attention and can sometimes distort the overall design of PETSc in > issues that are not important in that non-special case. > > > > Along these lines, I'm curious about using an API like VecGhost for the > DA. > > Interesting suggestion. > > > That is, what if there was a level where a Vec could know about a local > form. When you get the local form, one implementation would return the > contiguous local form (no copy) and another implementation would return a > separate vector. > > How with the DMDA could you have a no copy and still allow nice 2 d and > 3d array access of ghost points? It seems to me with DMDA you would always > need a copy (or some crazy overloading of [])? Or do you mean in the DMDA > case you get a copy but in the unstructured grid case you get no copy, but > the basic paradigm of "local form" is always used? > > > Barry > > > Then you could VecUpdateVector(Xglobal,Xlocal,imode,scattermode) or so > (need an unambiguous name). Then DMComposite could operate without forcing > separate local and global vectors. > > In other words all parallel Vecs could have related local forms and the > model is "give me local form Vec", scatter to/from local form vec etc? > > Barry > > > > > Jed > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20101207/b0b3cccf/attachment.html>
