[petsc-users] Re-ordering in DMPlexCreateFromCellListParallelPetsc
Nicolas Barral
nicolas.barral at math.u-bordeaux.fr
Mon Mar 22 16:54:54 CDT 2021
@+
--
Nicolas
On 22/03/2021 17:53, Matthew Knepley wrote:
> On Mon, Mar 22, 2021 at 12:20 PM Nicolas Barral
> <nicolas.barral at math.u-bordeaux.fr
> <mailto:nicolas.barral at math.u-bordeaux.fr>> wrote:
>
> Thanks for your answers Matt.
>
> On 22/03/2021 13:45, Matthew Knepley wrote:
> > On Mon, Mar 22, 2021 at 6:22 AM Nicolas Barral
> > <nicolas.barral at math.u-bordeaux.fr
> <mailto:nicolas.barral at math.u-bordeaux.fr>
> > <mailto:nicolas.barral at math.u-bordeaux.fr
> <mailto:nicolas.barral at math.u-bordeaux.fr>>> wrote:
> >
> > On 21/03/2021 21:29, Matthew Knepley wrote:
> > > On Sat, Mar 20, 2021 at 10:07 AM Nicolas Barral
> > > <nicolas.barral at math.u-bordeaux.fr
> <mailto:nicolas.barral at math.u-bordeaux.fr>
> > <mailto:nicolas.barral at math.u-bordeaux.fr
> <mailto:nicolas.barral at math.u-bordeaux.fr>>
> > > <mailto:nicolas.barral at math.u-bordeaux.fr
> <mailto:nicolas.barral at math.u-bordeaux.fr>
> > <mailto:nicolas.barral at math.u-bordeaux.fr
> <mailto:nicolas.barral at math.u-bordeaux.fr>>>> wrote:
> > >
> > > Hi all,
> > >
> > > I'm building a plex from elements arrays using
> > > DMPlexCreateFromCellListParallelPetsc. Once the plex
> is built, I
> > > need to
> > > set up boundary labels. I have an array of faces
> containing a
> > series of
> > > 3 vertex local indices. To rebuild boundary labels, I
> need to
> > loop over
> > > the array and get the join of 3 consecutive points to
> find the
> > > corresponding face point in the DAG.
> > >
> > >
> > > This is very common. We should have a built-in thing that
> does this.
> > >
> > Ordering apart, it's not very complicated once you figure out
> "join" is
> > the right operation to use. We need more doc on graph layout and
> > operations in DMPlex, I think I'm going to make pictures when
> I'm done
> > with that code because I waste too much time every time. Is
> there a
> > starting point you like ?
> >
> >
> > I think the discussion in
> >
> > @article{LangeMitchellKnepleyGorman2015,
> > title = {Efficient mesh management in {Firedrake} using
> > {PETSc-DMPlex}},
> > author = {Michael Lange and Lawrence Mitchell and Matthew G.
> > Knepley and Gerard J. Gorman},
> > journal = {SIAM Journal on Scientific Computing},
> > volume = {38},
> > number = {5},
> > pages = {S143--S155},
> > eprint = {http://arxiv.org/abs/1506.07749},
> > doi = {10.1137/15M1026092},
> > year = {2016}
> > }
> >
> > is pretty good.
> >
> It is, I'd just like to have something more complete (meet, join,
> height, depth...) and with more 2D & 3D pictures. It's all information
> available somewhere, but I would find it convenient to be all at the
> same place. Are sources of the paper available somewhere ?
>
>
> I think the right answer is no, there is not a complete reference. I
> have some things in presentations,
> but no complete work has been written. Maybe it is time to do that. At
> this point, a book is probably
> possible :)
I'll gladly help with figures or coffees if it can speed up the process ;)
>
> > > Problem, vertices get reordered by
> > > DMPlexCreateFromCellListParallelPetsc
> > > so that locally owned vertices are before remote ones, so
> > local indices
> > > are changed and the indices in the face array are not good
> > anymore.
> > >
> > >
> > > This is not exactly what happens. I will talk through the
> > algorithm so
> > > that maybe we can find a good
> > > interface. I can probably write the code quickly:
> > >
> > > 1) We take in cells[numCells, numCorners], which is a list
> of all
> > the
> > > vertices in each cell
> > >
> > > The vertex numbers do not have to be a contiguous
> set. You can
> > > have any integers you want.
> > >
> > > 2) We create a sorted list of the unique vertex numbers on
> each
> > process.
> > > The new local vertex numbers
> > > are the locations in this list.
> > >
> >
> > Ok It took me re-writing this email a couple times but I think I
> > understand. I was too focused on local/global indices. But if
> I get
> > this
> > right, you still make an assumption: that the numVertices*dim
> > coordinates passed in vertexCoords are the coordinates of the
> > numvertices first vertices in the sorted list. Is that true ?
> >
> >
> > No. It can be arbitrary. That is why we make the vertexSF, so we
> can map
> > those coordinates back to the right processes.
> >
> So how do you know which coordinates correspond to which vertex
> since no
> map is explicitly provided ?
>
>
> Ah, it is based on the input assumptions when everything is put
> together. You could call BuildParallel()
> with any old numbering of vertices. However, if you call
> CreateParallel(), so that you are also passing
> in an array for vertex coordinates. Now vertices are assumed to be
> numbered [0, Nv) to correspond to
> the input array. Now, that array of coordinates can be chopped up
> differently in parallel than the vertices
> for subdomains. The vertexSF can convert between the mappings.
So if on rank 0, I have numCells tets using say 10 different vertices,
and I pass a list of 7*2 coordinates, the coordinates will be assumed to
be those of the 7 first vertices in the sorted unique identifier list ?
Is this fool proof ? (meaning: if it works for me now, can I assume I
did the right thing or should I be careful and look twice ?)
>
> > > Here is my proposed interface. We preserve this list of unique
> > vertices,
> > > just as we preserve the vertexSF.
> > > Then after DMPlexCreateFromCellListParallelPetsc(), can
> > > DMPlexInterpolate(), you could call
> > >
> > > DMPlexBuildFaceLabelsFromCellList(dm, numFaces, faces,
> labelName,
> > > labelValues)
> > >
> > > Would that work for you? I think I could do that in a
> couple of
> > hours.
> > >
> >
> > So that function would be very helpful. But is it as simple
> as you're
> > thinking ? The sorted list gives local index -> unique
> identifier, but
> >
> > what we need is the other way round, isn't it ?
> >
> >
> > You get the other way using search.
> >
> Do you mean a linear search for each vertex ?
>
>
> Since it is sorted, it is a log search.
>
You are right. Are you opposed to hash tables though ? :)
Thanks
--
Nicolas
> Thanks,
>
> Matt
>
> Thanks,
>
> --
> Nicolas
>
> > Thanks,
> >
> > Matt
> >
> > Once I understand better, I can have a first draft in my
> plexadapt code
> > and we pull it out later.
> >
> > Thanks
> >
> > --
> > Nicolas
> >
> >
> > > Thanks,
> > >
> > > Matt
> > >
> > > Is there a way to track this renumbering ? For owned
> > vertices, I can
> > > find the local index from the global one (so do old local
> > index ->
> > > global index -> new local index). For the remote ones, I'm
> > not sure. I
> > > can hash global indices, but is there a more idiomatic
> way ?
> > >
> > > Thanks,
> > >
> > > --
> > > Nicolas
> > >
> > >
> > >
> > > --
> > > What most experimenters take for granted before they begin
> their
> > > experiments is infinitely more interesting than any
> results to which
> > > their experiments lead.
> > > -- Norbert Wiener
> > >
> > > https://www.cse.buffalo.edu/~knepley/
> > <http://www.cse.buffalo.edu/~knepley/>
> >
> >
> >
> > --
> > What most experimenters take for granted before they begin their
> > experiments is infinitely more interesting than any results to which
> > their experiments lead.
> > -- Norbert Wiener
> >
> > https://www.cse.buffalo.edu/~knepley/
> <http://www.cse.buffalo.edu/~knepley/>
>
>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which
> their experiments lead.
> -- Norbert Wiener
>
> https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
More information about the petsc-users
mailing list