On Thu, Jan 15, 2009 at 05:58, Kirk, Benjamin (JSC-EG) <[email protected]> wrote: >> 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.
The point is that the global-to-local mapping is more expensive and you can always get the global index cheaply by applying the local-to-global mapping. > We number the degrees of freedom such that they are contiguous by processor > block, so each processor can easily store > [first_local_dof ... last_local_dof) in the front of the vector, which is > done now. Right, we always have a cheap global-to-local map for the owned part (subtract our starting index). The ghosted part is usually smaller and needs the binary search or hash lookup. >>> (A local-to-global mapping seems to be provided by PETSc.) >> >> Interesting - like a sparsity pattern for vectors. Is it shared >> between multiple vectors? It is shared under VecDuplicate. Jed ------------------------------------------------------------------------------ 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
