<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 24, 2016 at 1:18 PM, Andrew Ho <span dir="ltr"><<a href="mailto:andrewh0@uw.edu" target="_blank">andrewh0@uw.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">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.</span><span style="font-size:12.8px"><br></span></blockquote><div><br></div></span>The mesh surface nodes have no correspondence to the basis set I use for expanding my solution on; i.e. I could use sub/super parametric mappings. I think this is why Exodus II doesn't support any elements higher than 6-node triangles; I believe these are sufficient for representing conics sections (not entirely sure about this).<div class="gmail_extra"><span class=""><span style="font-size:12.8px"><br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">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.</span></blockquote><div><br></div></span><div>Yes, I have the original CAD files, but there are a few issues:</div><div><br></div><div>1. I don't have any code for reading in the CAD format (not entirely sure how difficult this is)</div><div>2. I don't know of any easy way to correspond a given element in the mesh with a surface in the CAD file, as in what part of the original surface is my element on. I could do some "geometric tolerance" based approach, but I don't know how robust this is especially near where two surfaces join together.</div><div>3. Why do I need to add this complexity to all of my simulation codes? The mesh generator already knows how to understand the geometry, and output meshes which conform to the curved surface. I simply want to use this existing feature and have my simulation code deal entirely with performing the simulation, not deal with having to handle NURBS surfaces, conics section, surface mapping, etc.</div></div></div></blockquote><div><br></div><div>Correspondence should not be hard since you can mark the mesh however you like. If you are happy with quadratic surface approximations,</div><div>then you are in a great spot here. However, I think its easy to push to a place where they are insufficient (needing exact normals for conservation</div><div>or balance, needing accurate volume conservation, ...) and you must interact with the CAD model. However, we have tried this before. Jed had a</div><div>hard time with the CAD file reader, and when Jed has a hard time I usually give up immediately.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="HOEnZb"><font color="#888888">-- <br><div data-smartmail="gmail_signature"><div dir="ltr">Andrew Ho</div></div>
</font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>