[petsc-users] DMPlex higher order elements

Mark Lohry mlohry at princeton.edu
Wed Aug 24 12:56:47 CDT 2016


Philosophically it's certainly part of the job of the mesh generator, 
but realistically I don't think there are any really viable high-order 
mesh generators or even file formats right now (correct me if I'm 
wrong). And as Matthew put, the mesh generator has no business telling 
us what our function basis should be, and by extension has no basis 
telling us where we should place our face nodes.


> I was simply stating that  without access to the original geometric representation, I don't know 
if my simulation domain really has flat walls, > or even how curved are 
the walls if they are curved, so there's no general way for me to 
accurately determine the shape of the element.

This comes up a lot in high order mesh discussions, but I always wonder 
when do you *not* have access to the original geometric representation? 
If you've generated the mesh yourself you must have the geometry.



On 08/24/2016 11:48 AM, Andrew Ho wrote:
> That sounds like taking part of the job of the mesh generator and 
> putting it into my code. I was simply stating that without access to 
> the original geometric representation, I don't know if my simulation 
> domain really has flat walls, or even how curved are the walls if they 
> are curved, so there's no general way for me to accurately determine 
> the shape of the element.
>
> On Wed, Aug 24, 2016 at 10:40 AM, Mark Lohry <mlohry at princeton.edu 
> <mailto:mlohry at princeton.edu>> wrote:
>
>     On 08/24/2016 11:27 AM, Andrew Ho wrote:
>>     Good geometric accuracy is very import for achieving appropriate
>>     convergence rates in complex geometry, not just using higher
>>     order polynomials on flat elements.
>>
>>     If you look at Hesthaven's book Nodal Discontinuous Galerkin
>>     Methods, Table 9.1 shows that without support for curved
>>     elements, higher order DG element on flat elements converges at
>>     sub optimal rates due to inaccuracies produced by the boundary
>>     conditions.
>>
>>     There's no way to re-construct this curved information correctly
>>     after the fact; it must be generated by the meshing software.
>>
>
>     I don't *entirely* agree with the suggestion the mesh generator
>     has to provide that information. Some people reconstruct splines
>     through the nodes to create higher order meshes after the fact
>     (which also requires some detection or specification of sharp
>     corners to break the spline). I personally take the given mesh
>     from the generator in addition to an IGES/NURBS type CAD file for
>     complex geometries, and then do a kind of projection for sub-cell
>     curved boundary faces.
>
>
>>     On Wed, Aug 24, 2016 at 10:12 AM, Jed Brown <jed at jedbrown.org
>>     <mailto:jed at jedbrown.org>> wrote:
>>
>>         Matthew Knepley <knepley at gmail.com
>>         <mailto:knepley at gmail.com>> writes:
>>         >> Yes, I do not support that since I think its a crazy way
>>         to talk about
>>         >> things. All the topological information is in the Tri3
>>         mesh, and
>>         >> Cubit has no business telling me about the function space.
>>         >>
>>         >>
>>         >> Do you support / plan to support curved elements?
>>         >>
>>         >
>>         > I had "support" in there, but there were bugs. Toby and
>>         Mark discovered
>>         > these, and Toby has fixed them. I think
>>         > all of the fixes are in master now.
>>
>>         The context is clearly that the mesh generator needs to
>>         express the
>>         curved elements.  DMPlex doesn't have a geometric model
>>         available, so it
>>         doesn't know how to make the Tri3 elements curve to conform more
>>         accurately to the boundary.  The mesh generator has no
>>         business telling
>>         you what function space to use for your solution, but it'd be
>>         a shame to
>>         prevent it from expressing element geometry.
>>
>>
>>
>>
>>     -- 
>>     Andrew Ho
>
>
>
>
>
> -- 
> Andrew Ho

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20160824/f94f2bb6/attachment.html>


More information about the petsc-users mailing list