The main reason to have this natural ordering is to read and write data, possibly with different numbers of procs.
ALB On Feb 17, 2014, at 6:21 PM, Jed Brown <[email protected]> wrote: > Matthew Knepley <[email protected]> writes: > >> On Mon, Feb 17, 2014 at 5:14 PM, Jed Brown <[email protected]> wrote: >> >>> Andrés Alessandro León Baldelli <[email protected]> writes: >>> >>>> Hi all, >>>> I am working with Blaise Bourdin on implementing a concept of "natural >>> numbering" for unstructured meshes using DMplex. >>>> Such natural numbering can be, e.g., that of the mesh prior to parallel >>> distribution. >>>> I have a working example in which I compute a field on the distributed >>> DM and I scatter it back to the serial DM on rank0 but I would like to >>> create a more general interface. To this regard I ask your advice: >>>> 1) Is it reasonable to add an SF within the DM typedef for this "natural >>> to global" scatter? >>> >>> Surely you don't want the (necessarily non-scalable) serial DM to be a >>> necessary part of this interface? What do you want to do with this >>> natural numbering? Just write output files? >>> >> >> Jed, No, no, no. This is not an SF for a serial DM. > > I was responding to the question above. Yes, we need a genuine parallel > reader (naive partition) and a way to write back in that ordering. But > my question remains: do you want to do something other than IO with that > "natural" ordering? > > Note that in the natural ordering, you likely have elements for which > you own zero of the vertices, and vice-versa, so it would be _really_ > bad to compute on it.
