Dear Ben, On Thu, 15 Jan 2009, Kirk, Benjamin (JSC-EG) wrote:
>>> My idea would be that PetscVector creates the global-to-local mapping (for >>> the ghost cells only) itself (and stores it, e.g. as a std::map<unsigned >>> int, >>> unsigned int>). This should still save a lot of memory compared with the >>> serial vector version. >> >> Sounds like the best we can do. Maybe typedef the container to make >> it easier for us to play with map vs. hash_map performance for it. > > I believe this should be handled by the send_list. The send_list, minus the > local components, should be the remote ghost dofs we need. Even better, it > is already sorted. In any case, this should generally be a small number of > (global) integer indices (except after refinement/redistribution). So, we > can take that part of the send list, and pack it into > [minimum_global_ghost_idx ... maximum_global_ghost_idx) > and then use a binary search to find the 'local' ghost dof index. > > Main advantage here is (i) the data already exist, and (ii) the integer > index array will be small. As Roy asks/suggests, though, this information > could *still* be shared among several vectors with the same partitioning if > desired. > > BTW, I think I promised this a while ago, so I am delinquent in my delivery. > Roy, I'd be happy to help. I think we should copy off NumericVector and > work on it in parallel (pun intended?) to the the existing implementation. > It should then be a drop-in replacement when we are done. I have to admit that I don't understand most of the things you write here since I'm not familiar with libMesh's send_list concept. The decisive question for me is: Will I be working on NumericVector and PetscVector (the way I discussed with Roy), or will you be working on that (in which case I just have to wait for things to happen)? Or will I still be working on NumericVector and PetscVector, but in a different way? In that case, please explain in more detail. I mean NumericVector::operator()(unsigned int) is supposed to get a global index anyway, and it does not have access to a send_list. Best Regards, Tim -- Dr. Tim Kroeger [email protected] Phone +49-421-218-7710 [email protected] Fax +49-421-218-4236 Fraunhofer MEVIS, Institute for Medical Image Computing Universitaetsallee 29, 28359 Bremen, Germany ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
