Matthew Knepley <[email protected]> writes: > On Fri, Mar 19, 2021 at 2:21 PM Jed Brown <[email protected]> wrote: > >> Matthew Knepley <[email protected]> writes: >> >> >> Notice how the permutations are contained within the vertices {0, ..., >> 8}, >> >> edges {9, ..., 24}, and cells {25, ..., 32}. I would like to get rid of >> >> that restriction, but you've said it would have significant non-local >> >> consequences so I haven't tried. >> >> >> > >> > Yes, that is not a good idea, even in theory. It wrecks the nice >> contiguity >> > we use for topological operations. >> > >> > As Lawrence points out, this need not affect your smoother because dof >> > permutations can break this stratification. It has been that way for a >> > decade. >> >> I only want to break dof stratification, not point stratification. The >> points produced by the stratified RCM are okay (at least as Lawrence >> described it; not sure how it's done in DMPlexGetOrdering, but can't be >> anything hard). >> >> What code needs to be written to get unstratified RCM-like dofs? Lawrence >> evidently has this code in Firedrake, but I want it in DMPlex, tested and >> probably done by default because most users would benefit from it. I could >> swear you said it would break some other assumptions and thus not >> everything would work, but perhaps we weren't talking about the same thing. >> > > It is possible that I misunderstood what you were asking for. What Section > requires for everything to work is that dofs follow the point ordering.
I think what you mean is that the dofs for any point are contiguous, not that the dofs for point p come before the dofs for point p+1. > The point ordering can be anything we want since we can use a permutation > from the mesh point ordering. However, some stuff depends on all dofs > associated with a point being contiguous. Not everything does, since I wrote > something for LibMesh which allows them to order in a field major way, > instead of point major, but it is probably not possible to individually > permute unknowns. Usually, this is not what we want anyway I would assume. I don't want to break up the dofs for a point, just an unstratified locality-preserving ordering of dofs (not points). PetscSectionSetUp currently calculates offsets by walking the points in order. I'd like to be able to walk them in a different ordering, perhaps specified via an IS permutation, which could be computed using MATORDERINGRCM or directly via BFS of a closure (saves building a Mat). 1. Would this break anything you can think of? 2. How would you like it implemented?
