<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 30, 2016 at 1:06 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"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">1) I don't use Physical Groups from GMsh since its unclear how this would be reflected in the discretization</blockquote><div> </div>If I'm not using physical groups in GMsh, how do I easily denote what part of the domain should be handled with which physics? I would like to be able to use the same code with similar but not identical meshes (for example to do a convergence study), so manually iterating through a list of vertices at the element height stratum in a chart doesn't provide any hints on which subdomain an element is suppose to belong in.</div>
</blockquote></div><br>I think the right way to handle all this is to just mark pieces of the mesh. Mesh formats should just have a generic marking</div><div class="gmail_extra">ability which does not differentiate between vertices, edges, faces, and cells. Some formats come close (ExodusII) and some</div><div class="gmail_extra">are just crazy (GMsh). If you can point me toward the documentation for the GMsh format, I will put in code to translate whatever</div><div class="gmail_extra">part marks cells to a cell label, as we do for ExodusII.</div><div class="gmail_extra"><br></div><div class="gmail_extra">  Thanks,</div><div class="gmail_extra"><br></div><div class="gmail_extra">     Matt<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>