On Thu, 15 Jan 2009, Tim Kroeger wrote: > But there is another problem (things turn out to be more difficult than I > thought): In the ghost cell case, PETSc does not provide the appropriate > global-to-local mapping that would be required for e.g. > NumericVector::operator()(unsigned int). I asked this in the petsc-users > list. Jed Brown commented on this by arguing the natural thing would be that > libMesh's DofMap should work on local dof numbers.
Giving identical degrees of freedom different ids on different processors would not be natural for us, especially considering the changes we'd be forced to make to the DofMap (which would now need to talk to our numeric interfaces for the first time!), to our non-Petsc numeric interfaces, to code that stores non-DoF data associated with particular degrees of freedom... I sympathize with their desire to have contiguous local dof numbers, but I think this would be too big a change for us right now. > (A local-to-global mapping seems to be provided by PETSc.) Interesting - like a sparsity pattern for vectors. Is it shared between multiple vectors? > 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. --- Roy ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
