<div dir="ltr"><span style="font-size:12.8px">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.</span><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 24, 2016 at 10:40 AM, Mark Lohry <span dir="ltr"><<a href="mailto:mlohry@princeton.edu" target="_blank">mlohry@princeton.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div lang="x-unicode"><span class=""> On 08/24/2016 11:27 AM,
Andrew Ho wrote:<br>
</span><span class=""><blockquote 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></span><span class="">
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>
</span><span class=""><blockquote 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 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>Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">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 data-smartmail="gmail_signature">
<div dir="ltr">Andrew Ho</div>
</div>
</div>
</blockquote>
<br>
</span></div>
<br>
</div>
</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>