<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-text-html" lang="x-unicode"> On 08/24/2016 11:27 AM,
Andrew Ho wrote:<br>
<blockquote
cite="mid:CADhXwgsAtKBsKx21djG44wqE_pX8a2hK0CcOXafXQ-ok+hDTnA@mail.gmail.com"
type="cite">
<div dir="ltr">Good geometric accuracy is very import for
achieving appropriate convergence rates in complex geometry,
not just using higher order polynomials on flat elements.<br>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>There's no way to re-construct this curved information
correctly after the fact; it must be generated by the
meshing software.</div>
</div>
<div class="gmail_extra"><br>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:CADhXwgsAtKBsKx21djG44wqE_pX8a2hK0CcOXafXQ-ok+hDTnA@mail.gmail.com"
type="cite">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Aug 24, 2016 at 10:12 AM, Jed
Brown <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">Matthew Knepley <<a moz-do-not-send="true"
href="mailto:knepley@gmail.com">knepley@gmail.com</a>>
writes:<br>
>> Yes, I do not support that since I think its a
crazy way to talk about<br>
>> things. All the topological information is in
the Tri3 mesh, and<br>
>> Cubit has no business telling me about the
function space.<br>
>><br>
>><br>
>> Do you support / plan to support curved
elements?<br>
>><br>
><br>
> I had "support" in there, but there were bugs. Toby
and Mark discovered<br>
> these, and Toby has fixed them. I think<br>
> all of the fixes are in master now.<br>
<br>
</span>The context is clearly that the mesh generator
needs to express the<br>
curved elements. DMPlex doesn't have a geometric model
available, so it<br>
doesn't know how to make the Tri3 elements curve to
conform more<br>
accurately to the boundary. The mesh generator has no
business telling<br>
you what function space to use for your solution, but it'd
be a shame to<br>
prevent it from expressing element geometry.<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">Andrew Ho</div>
</div>
</div>
</blockquote>
<br>
</div>
<br>
</body>
</html>