<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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.<br>
<br>
<br>
<span style="font-size:12.8px">> 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>
<br>
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.<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 08/24/2016 11:48 AM, Andrew Ho
wrote:<br>
</div>
<blockquote
cite="mid:CADhXwgt4t-aCiky4hkt-xBCO5-NQkJBY-47TQxFvCxiSS20v2g@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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 moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:jed@jedbrown.org"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:jed@jedbrown.org">jed@jedbrown.org</a></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 moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>