On Wed, 1 Sep 2010, Jed Brown wrote:
> On Wed, 1 Sep 2010 12:58:11 -0500 (CDT), Roy Stogner > <royst...@ices.utexas.edu> wrote: >> I'm not sure I understood Jed's suggestion - eliminate parallel >> non-ghosted vectors entirely, then write our own ghosting support to >> handle the non-PETSc backends? That seems like a lot of work to get >> slightly more robust support for a feature that most people wouldn't >> need. We already support non-ghosted vectors, we already support >> ghosted vectors (efficiently with PETSc or inefficiently otherwise), >> why not just let people choose between them even for the "internal" >> vectors? > > Abstractly, there are only two "views" that a user needs: the parallel > one where each degree of freedom appears exactly once, and the "local" > one where a single process can look at it's subdomain plus unowned > interface dofs. With VecGhost, these get to share the same array and > you use VecGhostUpdate to update ghost values and sum into global > values, otherwise they are separate arrays and you map between with > VecScatter. Since you have your own Vector class, you can add an extra > slot for the local form and update it with VecScatter instead of using > the PETSc-managed local form that would be updated with VecGhostUpdate. > If this whole thing is more than about ten lines of code, something is > wrong. > > But maybe I've missed something unique about your use case. There are indeed a lot of vectors we end up using for which user code doesn't need access to ghost data, and for which we wouldn't necessarily want default storage of ghost degrees of freedom. On the other hand: Tim's initial interface to PETSc ghost vectors was a couple hundred lines. If you can support ghost data on all NumericVector subclasses together in 10 lines, we'd love a patch! (this was actually the way Ben had originally intended to add ghosted vector support - but when Tim offered to write the PETSc-specific support, we'd hardly want to turn that down in favor of something else we might write someday) --- Roy ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
