Re: [petsc-users] coordinate degrees of freedom for 2nd-order gmsh mesh

2023-01-12 Thread Jed Brown
Dave May  writes:

> On Thu 12. Jan 2023 at 17:58, Blaise Bourdin  wrote:
>
>> Out of curiosity, what is the rationale for _reading_ high order gmsh
>> meshes?
>>
>
> GMSH can use a CAD engine like OpenCascade. This provides geometric
> representations via things like BSplines. Such geometric representation are
> not exposed to the users application code, nor are they embedded in any
> mesh format GMSH emits. The next best thing is to use a high order
> representation of the mesh geometry and project the CAD geometry (say a
> BSpline) into this higher order function space. The projection of the
> geometry is a quantity that can be described with the .msh format.

Adding to this, efficient methods for volumes with concave surfaces *must* use 
at least quadratic geometry. See Figure 5, where "p-refinement with linear 
geometry" causes anti-convergence (due the spurious stress singularities from 
the linear geometry, visible in Figure 4) while p-refinement with quadratic 
geometry is vastly more efficient despite the physical stress singularities 
that prevent exponential convergence. 

https://arxiv.org/pdf/2204.01722.pdf


Re: [petsc-users] coordinate degrees of freedom for 2nd-order gmsh mesh

2023-01-12 Thread Matthew Knepley
On Thu, Jan 12, 2023 at 4:10 PM Dave May  wrote:

> On Thu 12. Jan 2023 at 17:58, Blaise Bourdin  wrote:
>
>> Out of curiosity, what is the rationale for _reading_ high order gmsh
>> meshes?
>>
>
> GMSH can use a CAD engine like OpenCascade. This provides geometric
> representations via things like BSplines. Such geometric representation are
> not exposed to the users application code, nor are they embedded in any
> mesh format GMSH emits. The next best thing is to use a high order
> representation of the mesh geometry and project the CAD geometry (say a
> BSpline) into this higher order function space. The projection of the
> geometry is a quantity that can be described with the .msh format.
>

Note that PETSc can directly read CAD files now and mesh over them.


> Is it so that one can write data back in native gmsh format?
>>
>
> No.
>
> Cheers,
> Dave
>
>>
>
>
>
>> Regards,
>> Blaise
>>
>>
>> On Jan 12, 2023, at 7:13 PM, Matthew Knepley  wrote:
>>
>> On Thu, Jan 12, 2023 at 1:33 PM Jed Brown  wrote:
>>
>>> It's confusing, but this line makes high order simplices always read as
>>> discontinuous coordinate spaces. I would love if someone would revisit
>>> that, perhaps also using DMPlexSetIsoperiodicFaceSF(),
>>
>>
>> Perhaps as a switch, but there is no way I am getting rid of the current
>> periodicity. As we have discussed before, breaking the topological relation
>> is a non-starter for me.
>>
>> It does look like higher order Gmsh does read as DG. We can just project
>> that to CG for non-periodic stuff.
>>
>>   Thanks,
>>
>> Matt
>>
>> which should simplify the code and avoid the confusing cell coordinates
>>> pattern. Sadly, I don't have time to dive in.
>>>
>>>
>>> https://gitlab.com/petsc/petsc/-/commit/066ea43f7f75752f012be6cd06b6107ebe84cc6d#3616cad8148970af5b97293c49492ff893e25b59_1552_1724
>>>
>>> "Daniel R. Shapero"  writes:
>>>
>>> > Sorry either your mail system or mine prevented me from attaching the
>>> file,
>>> > so I put it on pastebin:
>>> > https://pastebin.com/awFpc1Js
>>> >
>>> > On Wed, Jan 11, 2023 at 4:54 PM Matthew Knepley 
>>> wrote:
>>> >
>>> >> Can you send the .msh file? I still have not installed Gmsh :)
>>> >>
>>> >>   Thanks,
>>> >>
>>> >>  Matt
>>> >>
>>> >> On Wed, Jan 11, 2023 at 2:43 PM Daniel R. Shapero 
>>> wrote:
>>> >>
>>> >>> Hi all -- I'm trying to read in 2nd-order / piecewise quadratic
>>> meshes
>>> >>> that are generated by gmsh and I don't understand how the
>>> coordinates are
>>> >>> stored in the plex. I've been discussing this with Matt Knepley here
>>> >>> <
>>> https://urldefense.com/v3/__https://github.com/firedrakeproject/firedrake/issues/982__;!!K-Hz7m0Vt54!hL9WLR51ieyHFZx8N9AjhDwJCRpvmQto9CL1XOTkkAxFfUbtsabHuBDOATnWyP6lQszhA2gOStva7A$
>>> >
>>> >>> as it pertains to Firedrake but I think this is more an issue at the
>>> PETSc
>>> >>> level.
>>> >>>
>>> >>> This code
>>> >>> <
>>> https://urldefense.com/v3/__https://gist.github.com/danshapero/a140daaf951ba58c48285ec29f5973cc__;!!K-Hz7m0Vt54!hL9WLR51ieyHFZx8N9AjhDwJCRpvmQto9CL1XOTkkAxFfUbtsabHuBDOATnWyP6lQszhA2hho2eD1g$
>>> >
>>> >>> uses gmsh to generate a 2nd-order mesh of the unit disk, read it
>>> into a
>>> >>> DMPlex, print out the number of cells in each depth stratum, and
>>> finally
>>> >>> print a view of the coordinate DM's section. The resulting mesh has
>>> 64
>>> >>> triangles, 104 edges, and 41 vertices. For 2nd-order meshes, I'd
>>> expected
>>> >>> there to be 2 degrees of freedom at each node and 2 at each edge. The
>>> >>> output is:
>>> >>>
>>> >>> ```
>>> >>> Depth strata: [(64, 105), (105, 209), (0, 64)]
>>> >>>
>>> >>> PetscSection Object: 1 MPI process
>>> >>>   type not yet set
>>> >>> 1 fields
>>> >>>   field 0 with 2 components
>>> >>> Process 0:
>>> >>>   (   0) dim 12 offset   0
>>> >>>   (   1) dim 12 offset  12
>>> >>>   (   2) dim 12 offset  24
>>> >>> ...
>>> >>>   (  62) dim 12 offset 744
>>> >>>   (  63) dim 12 offset 756
>>> >>>   (  64) dim  0 offset 768
>>> >>>   (  65) dim  0 offset 768
>>> >>> ...
>>> >>>   ( 207) dim  0 offset 768
>>> >>>   ( 208) dim  0 offset 768
>>> >>>   PetscSectionSym Object: 1 MPI process
>>> >>> type: label
>>> >>> Label 'depth'
>>> >>> Symmetry for stratum value 0 (0 dofs per point): no symmetries
>>> >>> Symmetry for stratum value 1 (0 dofs per point): no symmetries
>>> >>> Symmetry for stratum value 2 (12 dofs per point):
>>> >>>   Orientation range: [-3, 3)
>>> >>> Symmetry for stratum value -1 (0 dofs per point): no symmetries
>>> >>> ```
>>> >>>
>>> >>> The output suggests that there are 12 degrees of freedom in each
>>> >>> triangle. That would mean the coordinate field is discontinuous
>>> across cell
>>> >>> boundaries. Can someone explain what's going on? I tried reading the
>>> .msh
>>> >>> file but it's totally inscrutable to me. I'm happy to RTFSC if
>>> someone
>>> >>> points me in the right direction. Matt tells me that the coordinate
>>> field
>>> >>> should only be 

Re: [petsc-users] coordinate degrees of freedom for 2nd-order gmsh mesh

2023-01-12 Thread Dave May
On Thu 12. Jan 2023 at 17:58, Blaise Bourdin  wrote:

> Out of curiosity, what is the rationale for _reading_ high order gmsh
> meshes?
>

GMSH can use a CAD engine like OpenCascade. This provides geometric
representations via things like BSplines. Such geometric representation are
not exposed to the users application code, nor are they embedded in any
mesh format GMSH emits. The next best thing is to use a high order
representation of the mesh geometry and project the CAD geometry (say a
BSpline) into this higher order function space. The projection of the
geometry is a quantity that can be described with the .msh format.

Is it so that one can write data back in native gmsh format?
>

No.

Cheers,
Dave

>



> Regards,
> Blaise
>
>
> On Jan 12, 2023, at 7:13 PM, Matthew Knepley  wrote:
>
> On Thu, Jan 12, 2023 at 1:33 PM Jed Brown  wrote:
>
>> It's confusing, but this line makes high order simplices always read as
>> discontinuous coordinate spaces. I would love if someone would revisit
>> that, perhaps also using DMPlexSetIsoperiodicFaceSF(),
>
>
> Perhaps as a switch, but there is no way I am getting rid of the current
> periodicity. As we have discussed before, breaking the topological relation
> is a non-starter for me.
>
> It does look like higher order Gmsh does read as DG. We can just project
> that to CG for non-periodic stuff.
>
>   Thanks,
>
> Matt
>
> which should simplify the code and avoid the confusing cell coordinates
>> pattern. Sadly, I don't have time to dive in.
>>
>>
>> https://gitlab.com/petsc/petsc/-/commit/066ea43f7f75752f012be6cd06b6107ebe84cc6d#3616cad8148970af5b97293c49492ff893e25b59_1552_1724
>>
>> "Daniel R. Shapero"  writes:
>>
>> > Sorry either your mail system or mine prevented me from attaching the
>> file,
>> > so I put it on pastebin:
>> > https://pastebin.com/awFpc1Js
>> >
>> > On Wed, Jan 11, 2023 at 4:54 PM Matthew Knepley 
>> wrote:
>> >
>> >> Can you send the .msh file? I still have not installed Gmsh :)
>> >>
>> >>   Thanks,
>> >>
>> >>  Matt
>> >>
>> >> On Wed, Jan 11, 2023 at 2:43 PM Daniel R. Shapero 
>> wrote:
>> >>
>> >>> Hi all -- I'm trying to read in 2nd-order / piecewise quadratic meshes
>> >>> that are generated by gmsh and I don't understand how the coordinates
>> are
>> >>> stored in the plex. I've been discussing this with Matt Knepley here
>> >>> <
>> https://urldefense.com/v3/__https://github.com/firedrakeproject/firedrake/issues/982__;!!K-Hz7m0Vt54!hL9WLR51ieyHFZx8N9AjhDwJCRpvmQto9CL1XOTkkAxFfUbtsabHuBDOATnWyP6lQszhA2gOStva7A$
>> >
>> >>> as it pertains to Firedrake but I think this is more an issue at the
>> PETSc
>> >>> level.
>> >>>
>> >>> This code
>> >>> <
>> https://urldefense.com/v3/__https://gist.github.com/danshapero/a140daaf951ba58c48285ec29f5973cc__;!!K-Hz7m0Vt54!hL9WLR51ieyHFZx8N9AjhDwJCRpvmQto9CL1XOTkkAxFfUbtsabHuBDOATnWyP6lQszhA2hho2eD1g$
>> >
>> >>> uses gmsh to generate a 2nd-order mesh of the unit disk, read it into
>> a
>> >>> DMPlex, print out the number of cells in each depth stratum, and
>> finally
>> >>> print a view of the coordinate DM's section. The resulting mesh has 64
>> >>> triangles, 104 edges, and 41 vertices. For 2nd-order meshes, I'd
>> expected
>> >>> there to be 2 degrees of freedom at each node and 2 at each edge. The
>> >>> output is:
>> >>>
>> >>> ```
>> >>> Depth strata: [(64, 105), (105, 209), (0, 64)]
>> >>>
>> >>> PetscSection Object: 1 MPI process
>> >>>   type not yet set
>> >>> 1 fields
>> >>>   field 0 with 2 components
>> >>> Process 0:
>> >>>   (   0) dim 12 offset   0
>> >>>   (   1) dim 12 offset  12
>> >>>   (   2) dim 12 offset  24
>> >>> ...
>> >>>   (  62) dim 12 offset 744
>> >>>   (  63) dim 12 offset 756
>> >>>   (  64) dim  0 offset 768
>> >>>   (  65) dim  0 offset 768
>> >>> ...
>> >>>   ( 207) dim  0 offset 768
>> >>>   ( 208) dim  0 offset 768
>> >>>   PetscSectionSym Object: 1 MPI process
>> >>> type: label
>> >>> Label 'depth'
>> >>> Symmetry for stratum value 0 (0 dofs per point): no symmetries
>> >>> Symmetry for stratum value 1 (0 dofs per point): no symmetries
>> >>> Symmetry for stratum value 2 (12 dofs per point):
>> >>>   Orientation range: [-3, 3)
>> >>> Symmetry for stratum value -1 (0 dofs per point): no symmetries
>> >>> ```
>> >>>
>> >>> The output suggests that there are 12 degrees of freedom in each
>> >>> triangle. That would mean the coordinate field is discontinuous
>> across cell
>> >>> boundaries. Can someone explain what's going on? I tried reading the
>> .msh
>> >>> file but it's totally inscrutable to me. I'm happy to RTFSC if someone
>> >>> points me in the right direction. Matt tells me that the coordinate
>> field
>> >>> should only be discontinuous if the mesh is periodic, but this mesh
>> >>> shouldn't be periodic.
>> >>>
>> >>
>> >>
>> >> --
>> >> What most experimenters take for granted before they begin their
>> >> experiments is infinitely more interesting than any results to which
>> their
>> >> experiments lead.
>> >> 

Re: [petsc-users] coordinate degrees of freedom for 2nd-order gmsh mesh

2023-01-12 Thread Matthew Knepley
On Thu, Jan 12, 2023 at 3:57 PM Blaise Bourdin  wrote:

> Out of curiosity, what is the rationale for _reading_ high order gmsh
> meshes?
> Is it so that one can write data back in native gmsh format?
>

So we can use meshes that other people design I think.

   Matt


> Regards,
> Blaise
>
>
> On Jan 12, 2023, at 7:13 PM, Matthew Knepley  wrote:
>
> On Thu, Jan 12, 2023 at 1:33 PM Jed Brown  wrote:
>
>> It's confusing, but this line makes high order simplices always read as
>> discontinuous coordinate spaces. I would love if someone would revisit
>> that, perhaps also using DMPlexSetIsoperiodicFaceSF(),
>
>
> Perhaps as a switch, but there is no way I am getting rid of the current
> periodicity. As we have discussed before, breaking the topological relation
> is a non-starter for me.
>
> It does look like higher order Gmsh does read as DG. We can just project
> that to CG for non-periodic stuff.
>
>   Thanks,
>
> Matt
>
> which should simplify the code and avoid the confusing cell coordinates
>> pattern. Sadly, I don't have time to dive in.
>>
>>
>> https://gitlab.com/petsc/petsc/-/commit/066ea43f7f75752f012be6cd06b6107ebe84cc6d#3616cad8148970af5b97293c49492ff893e25b59_1552_1724
>>
>> "Daniel R. Shapero"  writes:
>>
>> > Sorry either your mail system or mine prevented me from attaching the
>> file,
>> > so I put it on pastebin:
>> > https://pastebin.com/awFpc1Js
>> >
>> > On Wed, Jan 11, 2023 at 4:54 PM Matthew Knepley 
>> wrote:
>> >
>> >> Can you send the .msh file? I still have not installed Gmsh :)
>> >>
>> >>   Thanks,
>> >>
>> >>  Matt
>> >>
>> >> On Wed, Jan 11, 2023 at 2:43 PM Daniel R. Shapero 
>> wrote:
>> >>
>> >>> Hi all -- I'm trying to read in 2nd-order / piecewise quadratic meshes
>> >>> that are generated by gmsh and I don't understand how the coordinates
>> are
>> >>> stored in the plex. I've been discussing this with Matt Knepley here
>> >>> <
>> https://urldefense.com/v3/__https://github.com/firedrakeproject/firedrake/issues/982__;!!K-Hz7m0Vt54!hL9WLR51ieyHFZx8N9AjhDwJCRpvmQto9CL1XOTkkAxFfUbtsabHuBDOATnWyP6lQszhA2gOStva7A$
>> >
>> >>> as it pertains to Firedrake but I think this is more an issue at the
>> PETSc
>> >>> level.
>> >>>
>> >>> This code
>> >>> <
>> https://urldefense.com/v3/__https://gist.github.com/danshapero/a140daaf951ba58c48285ec29f5973cc__;!!K-Hz7m0Vt54!hL9WLR51ieyHFZx8N9AjhDwJCRpvmQto9CL1XOTkkAxFfUbtsabHuBDOATnWyP6lQszhA2hho2eD1g$
>> >
>> >>> uses gmsh to generate a 2nd-order mesh of the unit disk, read it into
>> a
>> >>> DMPlex, print out the number of cells in each depth stratum, and
>> finally
>> >>> print a view of the coordinate DM's section. The resulting mesh has 64
>> >>> triangles, 104 edges, and 41 vertices. For 2nd-order meshes, I'd
>> expected
>> >>> there to be 2 degrees of freedom at each node and 2 at each edge. The
>> >>> output is:
>> >>>
>> >>> ```
>> >>> Depth strata: [(64, 105), (105, 209), (0, 64)]
>> >>>
>> >>> PetscSection Object: 1 MPI process
>> >>>   type not yet set
>> >>> 1 fields
>> >>>   field 0 with 2 components
>> >>> Process 0:
>> >>>   (   0) dim 12 offset   0
>> >>>   (   1) dim 12 offset  12
>> >>>   (   2) dim 12 offset  24
>> >>> ...
>> >>>   (  62) dim 12 offset 744
>> >>>   (  63) dim 12 offset 756
>> >>>   (  64) dim  0 offset 768
>> >>>   (  65) dim  0 offset 768
>> >>> ...
>> >>>   ( 207) dim  0 offset 768
>> >>>   ( 208) dim  0 offset 768
>> >>>   PetscSectionSym Object: 1 MPI process
>> >>> type: label
>> >>> Label 'depth'
>> >>> Symmetry for stratum value 0 (0 dofs per point): no symmetries
>> >>> Symmetry for stratum value 1 (0 dofs per point): no symmetries
>> >>> Symmetry for stratum value 2 (12 dofs per point):
>> >>>   Orientation range: [-3, 3)
>> >>> Symmetry for stratum value -1 (0 dofs per point): no symmetries
>> >>> ```
>> >>>
>> >>> The output suggests that there are 12 degrees of freedom in each
>> >>> triangle. That would mean the coordinate field is discontinuous
>> across cell
>> >>> boundaries. Can someone explain what's going on? I tried reading the
>> .msh
>> >>> file but it's totally inscrutable to me. I'm happy to RTFSC if someone
>> >>> points me in the right direction. Matt tells me that the coordinate
>> field
>> >>> should only be discontinuous if the mesh is periodic, but this mesh
>> >>> shouldn't be periodic.
>> >>>
>> >>
>> >>
>> >> --
>> >> 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/
>> >> <
>> https://urldefense.com/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!K-Hz7m0Vt54!hL9WLR51ieyHFZx8N9AjhDwJCRpvmQto9CL1XOTkkAxFfUbtsabHuBDOATnWyP6lQszhA2go23tjRg$
>> >
>> >>
>>
>
>
> --
> 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

Re: [petsc-users] coordinate degrees of freedom for 2nd-order gmsh mesh

2023-01-12 Thread Blaise Bourdin



Out of curiosity, what is the rationale for _reading_ high order gmsh meshes?
Is it so that one can write data back in native gmsh format? 


Regards,
Blaise



On Jan 12, 2023, at 7:13 PM, Matthew Knepley  wrote:



On Thu, Jan 12, 2023 at 1:33 PM Jed Brown  wrote:



It's confusing, but this line makes high order simplices always read as discontinuous coordinate spaces. I would love if someone would revisit that, perhaps also using DMPlexSetIsoperiodicFaceSF(),


Perhaps as a switch, but there is no way I am getting rid of the current periodicity. As we have discussed before, breaking the topological relation is a non-starter for me.


It does look like higher order Gmsh does read as DG. We can just project that to CG for non-periodic stuff.


  Thanks,


    Matt



which should simplify the code and avoid the confusing cell coordinates pattern. Sadly, I don't have time to dive in.

https://gitlab.com/petsc/petsc/-/commit/066ea43f7f75752f012be6cd06b6107ebe84cc6d#3616cad8148970af5b97293c49492ff893e25b59_1552_1724

"Daniel R. Shapero"  writes:

> Sorry either your mail system or mine prevented me from attaching the file,
> so I put it on pastebin:
> https://pastebin.com/awFpc1Js
>
> On Wed, Jan 11, 2023 at 4:54 PM Matthew Knepley  wrote:
>
>> Can you send the .msh file? I still have not installed Gmsh :)
>>
>>   Thanks,
>>
>>      Matt
>>
>> On Wed, Jan 11, 2023 at 2:43 PM Daniel R. Shapero  wrote:
>>
>>> Hi all -- I'm trying to read in 2nd-order / piecewise quadratic meshes
>>> that are generated by gmsh and I don't understand how the coordinates are
>>> stored in the plex. I've been discussing this with Matt Knepley here
>>> 
>>> as it pertains to Firedrake but I think this is more an issue at the PETSc
>>> level.
>>>
>>> This code
>>> 
>>> uses gmsh to generate a 2nd-order mesh of the unit disk, read it into a
>>> DMPlex, print out the number of cells in each depth stratum, and finally
>>> print a view of the coordinate DM's section. The resulting mesh has 64
>>> triangles, 104 edges, and 41 vertices. For 2nd-order meshes, I'd expected
>>> there to be 2 degrees of freedom at each node and 2 at each edge. The
>>> output is:
>>>
>>> ```
>>> Depth strata: [(64, 105), (105, 209), (0, 64)]
>>>
>>> PetscSection Object: 1 MPI process
>>>   type not yet set
>>> 1 fields
>>>   field 0 with 2 components
>>> Process 0:
>>>   (   0) dim 12 offset   0
>>>   (   1) dim 12 offset  12
>>>   (   2) dim 12 offset  24
>>> ...
>>>   (  62) dim 12 offset 744
>>>   (  63) dim 12 offset 756
>>>   (  64) dim  0 offset 768
>>>   (  65) dim  0 offset 768
>>> ...
>>>   ( 207) dim  0 offset 768
>>>   ( 208) dim  0 offset 768
>>>   PetscSectionSym Object: 1 MPI process
>>>     type: label
>>>     Label 'depth'
>>>     Symmetry for stratum value 0 (0 dofs per point): no symmetries
>>>     Symmetry for stratum value 1 (0 dofs per point): no symmetries
>>>     Symmetry for stratum value 2 (12 dofs per point):
>>>       Orientation range: [-3, 3)
>>>     Symmetry for stratum value -1 (0 dofs per point): no symmetries
>>> ```
>>>
>>> The output suggests that there are 12 degrees of freedom in each
>>> triangle. That would mean the coordinate field is discontinuous across cell
>>> boundaries. Can someone explain what's going on? I tried reading the .msh
>>> file but it's totally inscrutable to me. I'm happy to RTFSC if someone
>>> points me in the right direction. Matt tells me that the coordinate field
>>> should only be discontinuous if the mesh is periodic, but this mesh
>>> shouldn't be periodic.
>>>
>>
>>
>> --
>> 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/
>> 
>>





-- 






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/



























— 
Canada Research Chair in Mathematical and Computational Aspects of Solid Mechanics (Tier 1)
Professor, Department of Mathematics & Statistics
Hamilton Hall room 409A, 

Re: [petsc-users] coordinate degrees of freedom for 2nd-order gmsh mesh

2023-01-12 Thread Matthew Knepley
On Thu, Jan 12, 2023 at 1:33 PM Jed Brown  wrote:

> It's confusing, but this line makes high order simplices always read as
> discontinuous coordinate spaces. I would love if someone would revisit
> that, perhaps also using DMPlexSetIsoperiodicFaceSF(),


Perhaps as a switch, but there is no way I am getting rid of the current
periodicity. As we have discussed before, breaking the topological relation
is a non-starter for me.

It does look like higher order Gmsh does read as DG. We can just project
that to CG for non-periodic stuff.

  Thanks,

Matt

which should simplify the code and avoid the confusing cell coordinates
> pattern. Sadly, I don't have time to dive in.
>
>
> https://gitlab.com/petsc/petsc/-/commit/066ea43f7f75752f012be6cd06b6107ebe84cc6d#3616cad8148970af5b97293c49492ff893e25b59_1552_1724
>
> "Daniel R. Shapero"  writes:
>
> > Sorry either your mail system or mine prevented me from attaching the
> file,
> > so I put it on pastebin:
> > https://pastebin.com/awFpc1Js
> >
> > On Wed, Jan 11, 2023 at 4:54 PM Matthew Knepley 
> wrote:
> >
> >> Can you send the .msh file? I still have not installed Gmsh :)
> >>
> >>   Thanks,
> >>
> >>  Matt
> >>
> >> On Wed, Jan 11, 2023 at 2:43 PM Daniel R. Shapero 
> wrote:
> >>
> >>> Hi all -- I'm trying to read in 2nd-order / piecewise quadratic meshes
> >>> that are generated by gmsh and I don't understand how the coordinates
> are
> >>> stored in the plex. I've been discussing this with Matt Knepley here
> >>> <
> https://urldefense.com/v3/__https://github.com/firedrakeproject/firedrake/issues/982__;!!K-Hz7m0Vt54!hL9WLR51ieyHFZx8N9AjhDwJCRpvmQto9CL1XOTkkAxFfUbtsabHuBDOATnWyP6lQszhA2gOStva7A$
> >
> >>> as it pertains to Firedrake but I think this is more an issue at the
> PETSc
> >>> level.
> >>>
> >>> This code
> >>> <
> https://urldefense.com/v3/__https://gist.github.com/danshapero/a140daaf951ba58c48285ec29f5973cc__;!!K-Hz7m0Vt54!hL9WLR51ieyHFZx8N9AjhDwJCRpvmQto9CL1XOTkkAxFfUbtsabHuBDOATnWyP6lQszhA2hho2eD1g$
> >
> >>> uses gmsh to generate a 2nd-order mesh of the unit disk, read it into a
> >>> DMPlex, print out the number of cells in each depth stratum, and
> finally
> >>> print a view of the coordinate DM's section. The resulting mesh has 64
> >>> triangles, 104 edges, and 41 vertices. For 2nd-order meshes, I'd
> expected
> >>> there to be 2 degrees of freedom at each node and 2 at each edge. The
> >>> output is:
> >>>
> >>> ```
> >>> Depth strata: [(64, 105), (105, 209), (0, 64)]
> >>>
> >>> PetscSection Object: 1 MPI process
> >>>   type not yet set
> >>> 1 fields
> >>>   field 0 with 2 components
> >>> Process 0:
> >>>   (   0) dim 12 offset   0
> >>>   (   1) dim 12 offset  12
> >>>   (   2) dim 12 offset  24
> >>> ...
> >>>   (  62) dim 12 offset 744
> >>>   (  63) dim 12 offset 756
> >>>   (  64) dim  0 offset 768
> >>>   (  65) dim  0 offset 768
> >>> ...
> >>>   ( 207) dim  0 offset 768
> >>>   ( 208) dim  0 offset 768
> >>>   PetscSectionSym Object: 1 MPI process
> >>> type: label
> >>> Label 'depth'
> >>> Symmetry for stratum value 0 (0 dofs per point): no symmetries
> >>> Symmetry for stratum value 1 (0 dofs per point): no symmetries
> >>> Symmetry for stratum value 2 (12 dofs per point):
> >>>   Orientation range: [-3, 3)
> >>> Symmetry for stratum value -1 (0 dofs per point): no symmetries
> >>> ```
> >>>
> >>> The output suggests that there are 12 degrees of freedom in each
> >>> triangle. That would mean the coordinate field is discontinuous across
> cell
> >>> boundaries. Can someone explain what's going on? I tried reading the
> .msh
> >>> file but it's totally inscrutable to me. I'm happy to RTFSC if someone
> >>> points me in the right direction. Matt tells me that the coordinate
> field
> >>> should only be discontinuous if the mesh is periodic, but this mesh
> >>> shouldn't be periodic.
> >>>
> >>
> >>
> >> --
> >> 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/
> >> <
> https://urldefense.com/v3/__http://www.cse.buffalo.edu/*knepley/__;fg!!K-Hz7m0Vt54!hL9WLR51ieyHFZx8N9AjhDwJCRpvmQto9CL1XOTkkAxFfUbtsabHuBDOATnWyP6lQszhA2go23tjRg$
> >
> >>
>


-- 
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/ 


Re: [petsc-users] coordinate degrees of freedom for 2nd-order gmsh mesh

2023-01-12 Thread Jed Brown
It's confusing, but this line makes high order simplices always read as 
discontinuous coordinate spaces. I would love if someone would revisit that, 
perhaps also using DMPlexSetIsoperiodicFaceSF(), which should simplify the code 
and avoid the confusing cell coordinates pattern. Sadly, I don't have time to 
dive in.

https://gitlab.com/petsc/petsc/-/commit/066ea43f7f75752f012be6cd06b6107ebe84cc6d#3616cad8148970af5b97293c49492ff893e25b59_1552_1724

"Daniel R. Shapero"  writes:

> Sorry either your mail system or mine prevented me from attaching the file,
> so I put it on pastebin:
> https://pastebin.com/awFpc1Js
>
> On Wed, Jan 11, 2023 at 4:54 PM Matthew Knepley  wrote:
>
>> Can you send the .msh file? I still have not installed Gmsh :)
>>
>>   Thanks,
>>
>>  Matt
>>
>> On Wed, Jan 11, 2023 at 2:43 PM Daniel R. Shapero  wrote:
>>
>>> Hi all -- I'm trying to read in 2nd-order / piecewise quadratic meshes
>>> that are generated by gmsh and I don't understand how the coordinates are
>>> stored in the plex. I've been discussing this with Matt Knepley here
>>> 
>>> as it pertains to Firedrake but I think this is more an issue at the PETSc
>>> level.
>>>
>>> This code
>>> 
>>> uses gmsh to generate a 2nd-order mesh of the unit disk, read it into a
>>> DMPlex, print out the number of cells in each depth stratum, and finally
>>> print a view of the coordinate DM's section. The resulting mesh has 64
>>> triangles, 104 edges, and 41 vertices. For 2nd-order meshes, I'd expected
>>> there to be 2 degrees of freedom at each node and 2 at each edge. The
>>> output is:
>>>
>>> ```
>>> Depth strata: [(64, 105), (105, 209), (0, 64)]
>>>
>>> PetscSection Object: 1 MPI process
>>>   type not yet set
>>> 1 fields
>>>   field 0 with 2 components
>>> Process 0:
>>>   (   0) dim 12 offset   0
>>>   (   1) dim 12 offset  12
>>>   (   2) dim 12 offset  24
>>> ...
>>>   (  62) dim 12 offset 744
>>>   (  63) dim 12 offset 756
>>>   (  64) dim  0 offset 768
>>>   (  65) dim  0 offset 768
>>> ...
>>>   ( 207) dim  0 offset 768
>>>   ( 208) dim  0 offset 768
>>>   PetscSectionSym Object: 1 MPI process
>>> type: label
>>> Label 'depth'
>>> Symmetry for stratum value 0 (0 dofs per point): no symmetries
>>> Symmetry for stratum value 1 (0 dofs per point): no symmetries
>>> Symmetry for stratum value 2 (12 dofs per point):
>>>   Orientation range: [-3, 3)
>>> Symmetry for stratum value -1 (0 dofs per point): no symmetries
>>> ```
>>>
>>> The output suggests that there are 12 degrees of freedom in each
>>> triangle. That would mean the coordinate field is discontinuous across cell
>>> boundaries. Can someone explain what's going on? I tried reading the .msh
>>> file but it's totally inscrutable to me. I'm happy to RTFSC if someone
>>> points me in the right direction. Matt tells me that the coordinate field
>>> should only be discontinuous if the mesh is periodic, but this mesh
>>> shouldn't be periodic.
>>>
>>
>>
>> --
>> 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/
>> 
>>


Re: [petsc-users] coordinate degrees of freedom for 2nd-order gmsh mesh

2023-01-11 Thread Daniel R. Shapero
Sorry either your mail system or mine prevented me from attaching the file,
so I put it on pastebin:
https://pastebin.com/awFpc1Js

On Wed, Jan 11, 2023 at 4:54 PM Matthew Knepley  wrote:

> Can you send the .msh file? I still have not installed Gmsh :)
>
>   Thanks,
>
>  Matt
>
> On Wed, Jan 11, 2023 at 2:43 PM Daniel R. Shapero  wrote:
>
>> Hi all -- I'm trying to read in 2nd-order / piecewise quadratic meshes
>> that are generated by gmsh and I don't understand how the coordinates are
>> stored in the plex. I've been discussing this with Matt Knepley here
>> 
>> as it pertains to Firedrake but I think this is more an issue at the PETSc
>> level.
>>
>> This code
>> 
>> uses gmsh to generate a 2nd-order mesh of the unit disk, read it into a
>> DMPlex, print out the number of cells in each depth stratum, and finally
>> print a view of the coordinate DM's section. The resulting mesh has 64
>> triangles, 104 edges, and 41 vertices. For 2nd-order meshes, I'd expected
>> there to be 2 degrees of freedom at each node and 2 at each edge. The
>> output is:
>>
>> ```
>> Depth strata: [(64, 105), (105, 209), (0, 64)]
>>
>> PetscSection Object: 1 MPI process
>>   type not yet set
>> 1 fields
>>   field 0 with 2 components
>> Process 0:
>>   (   0) dim 12 offset   0
>>   (   1) dim 12 offset  12
>>   (   2) dim 12 offset  24
>> ...
>>   (  62) dim 12 offset 744
>>   (  63) dim 12 offset 756
>>   (  64) dim  0 offset 768
>>   (  65) dim  0 offset 768
>> ...
>>   ( 207) dim  0 offset 768
>>   ( 208) dim  0 offset 768
>>   PetscSectionSym Object: 1 MPI process
>> type: label
>> Label 'depth'
>> Symmetry for stratum value 0 (0 dofs per point): no symmetries
>> Symmetry for stratum value 1 (0 dofs per point): no symmetries
>> Symmetry for stratum value 2 (12 dofs per point):
>>   Orientation range: [-3, 3)
>> Symmetry for stratum value -1 (0 dofs per point): no symmetries
>> ```
>>
>> The output suggests that there are 12 degrees of freedom in each
>> triangle. That would mean the coordinate field is discontinuous across cell
>> boundaries. Can someone explain what's going on? I tried reading the .msh
>> file but it's totally inscrutable to me. I'm happy to RTFSC if someone
>> points me in the right direction. Matt tells me that the coordinate field
>> should only be discontinuous if the mesh is periodic, but this mesh
>> shouldn't be periodic.
>>
>
>
> --
> 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/
> 
>


Re: [petsc-users] coordinate degrees of freedom for 2nd-order gmsh mesh

2023-01-11 Thread Matthew Knepley
Can you send the .msh file? I still have not installed Gmsh :)

  Thanks,

 Matt

On Wed, Jan 11, 2023 at 2:43 PM Daniel R. Shapero  wrote:

> Hi all -- I'm trying to read in 2nd-order / piecewise quadratic meshes
> that are generated by gmsh and I don't understand how the coordinates are
> stored in the plex. I've been discussing this with Matt Knepley here
>  as it pertains
> to Firedrake but I think this is more an issue at the PETSc level.
>
> This code
> 
> uses gmsh to generate a 2nd-order mesh of the unit disk, read it into a
> DMPlex, print out the number of cells in each depth stratum, and finally
> print a view of the coordinate DM's section. The resulting mesh has 64
> triangles, 104 edges, and 41 vertices. For 2nd-order meshes, I'd expected
> there to be 2 degrees of freedom at each node and 2 at each edge. The
> output is:
>
> ```
> Depth strata: [(64, 105), (105, 209), (0, 64)]
>
> PetscSection Object: 1 MPI process
>   type not yet set
> 1 fields
>   field 0 with 2 components
> Process 0:
>   (   0) dim 12 offset   0
>   (   1) dim 12 offset  12
>   (   2) dim 12 offset  24
> ...
>   (  62) dim 12 offset 744
>   (  63) dim 12 offset 756
>   (  64) dim  0 offset 768
>   (  65) dim  0 offset 768
> ...
>   ( 207) dim  0 offset 768
>   ( 208) dim  0 offset 768
>   PetscSectionSym Object: 1 MPI process
> type: label
> Label 'depth'
> Symmetry for stratum value 0 (0 dofs per point): no symmetries
> Symmetry for stratum value 1 (0 dofs per point): no symmetries
> Symmetry for stratum value 2 (12 dofs per point):
>   Orientation range: [-3, 3)
> Symmetry for stratum value -1 (0 dofs per point): no symmetries
> ```
>
> The output suggests that there are 12 degrees of freedom in each triangle.
> That would mean the coordinate field is discontinuous across cell
> boundaries. Can someone explain what's going on? I tried reading the .msh
> file but it's totally inscrutable to me. I'm happy to RTFSC if someone
> points me in the right direction. Matt tells me that the coordinate field
> should only be discontinuous if the mesh is periodic, but this mesh
> shouldn't be periodic.
>


-- 
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/ 


[petsc-users] coordinate degrees of freedom for 2nd-order gmsh mesh

2023-01-11 Thread Daniel R. Shapero
Hi all -- I'm trying to read in 2nd-order / piecewise quadratic meshes that
are generated by gmsh and I don't understand how the coordinates are stored
in the plex. I've been discussing this with Matt Knepley here
 as it pertains
to Firedrake but I think this is more an issue at the PETSc level.

This code
 uses
gmsh to generate a 2nd-order mesh of the unit disk, read it into a DMPlex,
print out the number of cells in each depth stratum, and finally print a
view of the coordinate DM's section. The resulting mesh has 64 triangles,
104 edges, and 41 vertices. For 2nd-order meshes, I'd expected there to be
2 degrees of freedom at each node and 2 at each edge. The output is:

```
Depth strata: [(64, 105), (105, 209), (0, 64)]

PetscSection Object: 1 MPI process
  type not yet set
1 fields
  field 0 with 2 components
Process 0:
  (   0) dim 12 offset   0
  (   1) dim 12 offset  12
  (   2) dim 12 offset  24
...
  (  62) dim 12 offset 744
  (  63) dim 12 offset 756
  (  64) dim  0 offset 768
  (  65) dim  0 offset 768
...
  ( 207) dim  0 offset 768
  ( 208) dim  0 offset 768
  PetscSectionSym Object: 1 MPI process
type: label
Label 'depth'
Symmetry for stratum value 0 (0 dofs per point): no symmetries
Symmetry for stratum value 1 (0 dofs per point): no symmetries
Symmetry for stratum value 2 (12 dofs per point):
  Orientation range: [-3, 3)
Symmetry for stratum value -1 (0 dofs per point): no symmetries
```

The output suggests that there are 12 degrees of freedom in each triangle.
That would mean the coordinate field is discontinuous across cell
boundaries. Can someone explain what's going on? I tried reading the .msh
file but it's totally inscrutable to me. I'm happy to RTFSC if someone
points me in the right direction. Matt tells me that the coordinate field
should only be discontinuous if the mesh is periodic, but this mesh
shouldn't be periodic.