<div class="gmail_quote">On Wed, Apr 13, 2011 at 22:15, Vijay S. Mahadevan <span dir="ltr"><<a href="mailto:vijay.m@gmail.com">vijay.m@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":5t">I will definitely look at NEK as per your suggestion but if they only<br>
use MOAB to read the mesh and convert it to their own mesh data<br>
structures, it beats the purpose of my question. Thanks for the<br>
pointer though.</div></blockquote></div><br><div>I have a library that does a bit of a hybrid. A key aspect is to retain enough structure to make high-order and composite finite element methods efficient while still having reasonable performance for low order. I don't think it's really what you're looking for because it just pulls out arrays for most tasks (though it doesn't maintain a full mesh data structure on its own), but I use sets and tags for some purposes. Be warned that it is quite immature and since I don't have any users that I know of, I change things pretty arbitrarily. There are also several places that assume hex elements rather than work through the correct API. Let me know if you have questions.</div>
<div><br></div><div><a href="https://github.com/jedbrown/dohp">https://github.com/jedbrown/dohp</a></div><div><br></div><div>MOAB/iMesh is not user-visible in a typical assembly loop, so Dohp is probably irrelevant to you</div>
<div><br></div><div><a href="https://github.com/jedbrown/dohp/blob/master/src/fs/tests/ellip.c#L430">https://github.com/jedbrown/dohp/blob/master/src/fs/tests/ellip.c#L430</a></div>