Hi Matt and Jed,
Thanks for your replies.
I did not consider that distinction Matt, that makes clearer. Maybe it's time to the DAG-stuff on the documentation another attempt...
Jed, could you point me in the direction of a possible solution to this, if there exists one? In my (FEM) application I'm not using the weak-form stuff, but do I use PetscFE to describe my data layout and access it with DMPlexVec(Mat)Set(Get)Closure and friends.
Thanks!
Vilmer
Matthew Knepley <knepley@gmail.com> writes:
> On Fri, May 5, 2023 at 10:55 AM Vilmer Dahlberg via petsc-users <
> petsc-users@mcs.anl.gov> wrote:
>
>> Hi.
>>
>>
>> I'm trying to read a mesh of higher element order, in this example a mesh
>> consisting of 10-node tetrahedral elements, from gmsh, into PETSC. But It
>> looks like the mesh is not properly being loaded and converted into a
>> DMPlex. gmsh tells me it has generated a mesh with 7087 nodes, but when I
>> view my dm object it tells me it has 1081 0-cells. This is the printout I
>> get
>>
>
> Hi Vilmer,
>
> Plex makes a distinction between topological entities, like vertices, edges
> and cells, and the function spaces used to represent fields, like velocity
> or coordinates. When formats use "nodes", they mix the two concepts
> together.
>
> You see that if you add the number of vertices and edges, you get 7087,
> since for P2 there is a "node" on every edge. Is anything else wrong?
Note that quadratic (and higher order) tets are broken with the Gmsh reader. It's been on my todo list for a while.
As an example, this works when using linear elements (the projection makes them quadratic and visualization is correct), but is tangled when holes.msh is quadratic.
$ $PETSC_ARCH/tests/dm/impls/plex/tutorials/ex1 -dm_plex_filename ~/meshes/holes.msh -dm_view cgns:s.cgns -dm_coord_petscspace_degree 2