[petsc-users] node DG with DMPlex
Yann Jobic
yann.jobic at univ-amu.fr
Thu Mar 26 16:14:06 CDT 2020
Hi matt
Le 3/23/2020 à 2:24 PM, Matthew Knepley a écrit :
> On Wed, Mar 18, 2020 at 12:58 PM Yann Jobic <yann.jobic at univ-amu.fr
> <mailto:yann.jobic at univ-amu.fr>> 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
> <yann.jobic at univ-amu.fr <mailto:yann.jobic at univ-amu.fr>
> > <mailto:yann.jobic at univ-amu.fr <mailto:yann.jobic at univ-amu.fr>>>
> 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 ?
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).
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 ?
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 ?
>
> 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/>
More information about the petsc-users
mailing list