On Thu, Mar 26, 2020 at 5:14 PM Yann Jobic <[email protected]> wrote:
> Hi matt > > Le 3/23/2020 à 2:24 PM, Matthew Knepley a écrit : > > On Wed, Mar 18, 2020 at 12:58 PM Yann Jobic <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi matt, > > > > Le 3/17/2020 à 4:00 PM, Matthew Knepley a écrit : > > > On Mon, Mar 16, 2020 at 5:20 PM Yann Jobic > > <[email protected] <mailto:[email protected]> > > > <mailto:[email protected] <mailto:[email protected]>>> > > wrote: > > > > > > Hi all, > > > > > > I would like to implement a nodal DG with the DMPlex > interface. > > > Therefore, i must add the internal nodes to the DM (GLL > > nodes), with > > > the > > > constrains : > > > 1) Add them as solution points, with correct coordinates (and > > keep the > > > good rotational ordering) > > > 2) Find the shared nodes at faces in order to compute the > fluxes > > > 3) For parallel use, so synchronize the ghost node at each > > time steps > > > > > > > > > Let me get the fundamentals straight before advising, since I > > have never > > > implemented nodal DG. > > > > > > 1) What is shared? > > I need to duplicate an edge in 2D, or a facet in 3D, and to sync it > > after a time step, in order to compute the numerical fluxes > > (Lax-Friedrichs at the beginning). > > > > > > I should have been more specific, but I think I see what you want. You > > do not "share" unknowns between cells, > > so all unknowns should be associated with some cell in the Section. > > > > You think of some cell unknowns as being "connected" to a face, so when > > you want to calculate a flux, you need > > the unknowns from the adjacent cell in order to do it. In order to do > > this, I would partition with overlap=1, which > > is what we do for finite volume, which has the same adjacency needs. You > > might also set > > > > > https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/DM/DMSetAdjacency.html > > to PETSC_TRUE, PETSC_FALSE, but you are probably doing everything > > matrix-free if you are using DG. > > The above is optimal for FV, but not for DG because you communicate more > > than you absolutely have to. > > > > A more complicated, but optimal, thing to do would be to assign interior > > dofs to the cell, and two sets of dofs > > to each face, one for each cell. Then you only communicate the face > > dofs. Its just more bookkeeping for you, > > but it will work in parallel just fine. > I'm going this way. > So i should use dm/impls/plex/examples/tutorials/ex1.c.html as reference. > I should define the internal nodes on cells : > I define the section with 3 fields (field 0 on cells, field 1 and 2 on > faces), as : > numComp[0] = Nr; /* Total number of dof per Cell */ > numDof[0*(dim+1)+0] = dim; /* defined over the Cell */ > And on the same section, the dofs at faces : > numComp[1] = NumDofPerFace; > numComp[2] = NumDofPerFace; > numDof[1*(dim+1)+dim-1] = dim-1; /* internal dof of the cell */ > numDof[2*(dim+1)+dim-1] = dim-1; /* external dof of the cell */ > > Is it a good way to create my section ? > I would put them all in one field. A "field" is supposed to be a physical thing, like velocity or pressure. > Thus, the data is duplicated for the faces, that means that i have to > sync the internal Face dof at faces with their corresponding values from > the internal one (at cells). > That is not how I was envisioning it. Perhaps a drawing. Suppose you had DG2, then you have 17 18 7-----8-----9-----14----15 | | | 16,3 4 5,6 11 12,13 | | | 1-----2-----3-----9-----10 19 20 so each face gets 2 dofs, one for each cell.When doing a cell integral, you only use the dof that is for that cell. The local-to-global would update the face dofs, so you would get each side. There is a reordering when you extract the closure. I have written one for spectral elements. We would need another here that ordered all the "other" face dofs to the end. This seems a little complicated to me. Do you know how Andreas Klockner does it in Hedge? Or Tim Warburton? I just want to make sure I am not missing an elegant way to handle this. > Here field 1 is synchronised with field 0, locally. > But the external Face dof, field 2, have to be synchronised with the > values of the adjacent cell. > Is it possible to use something like DMPlexGetFaceFields ? > Is there an example of such use of PetscSection and synchronisation > process ? > > For the parallel part, should i use PetscSF object ? > In parallel, integrals would be summed into the global vector, so each side has a 0 for the other face dof and the right contribution for its face dof. Then both sides get both solution dofs. It seems to work in my head. > I read your article "Mesh Algorithms for PDE with Sieve I: Mesh > Distribution". But it's refereeing to Matthew G. Knepley and Dmitry A. > Karpeev. Sieve implementation. > Technical Report ANL/MCS to appear, Argonne National Laboratory, > January 2008. > I couldn't find it. It is freely available ? > Don't bother reading that. There are later ones: There are two pretty good sources: https://arxiv.org/abs/1505.04633 https://arxiv.org/abs/1506.06194 The last one is a follow-on to this paper https://arxiv.org/abs/0908.4427 Thanks, Matt > > > > I don't think you need extra vertices, > or coordinates, and for output I > > recommend using DMPlexProject() to get > > the solution in some space that can be plotted like P1, or anything else > > supported by your visualization. > > I would like to use DMplex as much as i can, as i would in the future > refine locally the mesh. > > I hope you're good in this difficult situation (covid19), > > Best regards, > > Yann > > > > > Thanks, > > > > Matt > > > > > > > > We have an implementation of spectral element ordering > > > > > ( > https://gitlab.com/petsc/petsc/-/blob/master/src/dm/impls/plex/examples/tutorials/ex6.c > ). > > > > > Those share > > > the whole element boundary. > > > > > > 2) What ghosts do you need? > > In order to compute the numerical fluxes of one element, i need the > > values of the surrounding nodes connected to the adjacent elements. > > > > > > 3) You want to store real space coordinates for a quadrature? > > It should be basically the same as PetscFE of higher order. > > I add some vertex needed to compute a polynomal solution of the > desired > > order. That means that if i have a N, order of the local > approximation, > > i need 0.5*(N+1)*(N+2) vertex to store in the DMPlex (in 2D), in > > order to : > > 1) have the correct number of dof > > 2) use ghost nodes to sync the values of the vertex/edge/facet for > > 1D/2D/3D problem > > 2) save correctly the solution > > > > Does it make sense to you ? > > > > Maybe like > > > https://www.mcs.anl.gov/petsc/petsc-current/src/ts/examples/tutorials/ex11.c.html > > With the use of the function SplitFaces, which i didn't fully > > understood > > so far. > > > > Thanks, > > > > Yann > > > > > > > > We usually define a quadrature on the reference element > once. > > > > > > Thanks, > > > > > > Matt > > > > > > I found elements of answers in those threads : > > > > > > https://lists.mcs.anl.gov/pipermail/petsc-users/2016-August/029985.html > > > > > > https://lists.mcs.anl.gov/mailman/htdig/petsc-users/2019-October/039581.html > > > > > > However, it's not clear for me where to begin. > > > > > > Quoting Matt, i should : > > > " DMGetCoordinateDM(dm, &cdm); > > > <Set field information into cdm instead of dm> > > > DMCreateLocalVector(cdm, &coordinatesLocal); > > > <Fill in higher order coordinate values> > > > DMSetCoordinatesLocal(dm, coordinatesLocal);" > > > > > > However, i will not create ghost nodes this way. And i'm not > > sure to > > > keep the good ordering. > > > This part should be implemented in the PetscFE interface, for > > high > > > order > > > discrete solutions. > > > I did not succeed in finding the correct part of the source > > doing it. > > > > > > Could you please give me some hint to begin correctly thoses > > tasks ? > > > > > > Thanks, > > > > > > Yann > > > > > > > > > > > > -- > > > 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/>
