<div dir="ltr">> What  stk format? this one?<br><br><div dir="ltr">Yup, STK as in Sierra ToolKit. I've been using it for a long time now but honestly it's been giving my lots of troubles. For one, the source code isn't really out in the open (although distributed one-way via Trilinos).</div><div dir="ltr"><div><br></div><div>> Our best supported format (native moab format) is based on HDF5. </div><div><br></div></div><div dir="ltr"><div>Ah, I only read "based on". This probably means that you use the HDF5 data model, but nothing that's a standard like XDMF or so. Using a custom MOAB data type is a big no-no for me since I rely on several other tools in my workflow. I need standards.</div><div><br></div><div>VTK would be an options, but I interpret the MOAB source code correctly, you only support the legacy VTK format, not the XML-based one (VTU and friends). Right?</div></div><div dir="ltr"><div><br></div><div>> What format do you have for your mesh/data ?<br></div><div><br></div></div><div dir="ltr"><div>I'm quite flexible between Exodus and VTK.</div></div><div dir="ltr"><div><br></div><div>> MOAB HDF5 reader / writer supports parallel IO natively, in the sense </div><div>> every rank is responsible for a portion (part of a partition) of the mesh. </div><div><br></div></div><div dir="ltr"><div>That's the way it should be. Again, no support for standard data formats here; parallel Exodus, parallel VTK?</div></div><div dir="ltr"><div><br></div><div>> If you have cell data, you can build easily in MOAB a list of adjacent </div><div>> faces or edges. </div><div><br></div></div><div dir="ltr"><div>I do have cell data. Building edges and faces via STK unfortunately takes really really long, almost prohibitively long. That's one of the reasons why I'm looking in other directions. What's your experience in MOAB there?</div><div><br></div><div>Cheers,</div><div>Nico</div><div><br></div><div><br></div><div><br></div><div><div></div></div></div><div dir="ltr"><div><div><br>On Thu, Oct 29, 2015 at 3:13 PM Grindeanu, Iulian R. <<a href="mailto:iulian@mcs.anl.gov" target="_blank">iulian@mcs.anl.gov</a>> wrote:<br><br> <br> <br>Hi Nico,<br> <br> Thanks for your help with debian support<br> Please see below<br> <br> <br> <br></div></div></div><div dir="ltr"><div><div>From: <a href="mailto:moab-dev-bounces@mcs.anl.gov" target="_blank">moab-dev-bounces@mcs.anl.gov</a> [<a href="mailto:moab-dev-bounces@mcs.anl.gov" target="_blank">moab-dev-bounces@mcs.anl.gov</a>] on behalf of Nico Schlömer [<a href="mailto:nico.schloemer@gmail.com" target="_blank">nico.schloemer@gmail.com</a>]<br> Sent: Thursday, October 29, 2015 8:16 AM<br> To: <a href="mailto:moab-dev@mcs.anl.gov" target="_blank">moab-dev@mcs.anl.gov</a><br> Subject: [MOAB-dev] MOAB insights?<br> <br> <br> <br> <br>Hi everyone, <br><br> <br><br>I'm about to consider switching a larger application of mine over from STK (which I'm very unhappy with) to MOAB (the development experience of which has been great).<br> <br><br> What  stk format? <br>  this one?<br> <a href="https://trilinos.org/oldsite/packages/stk/STK_Tutorial_4.pdf" target="_blank">https://trilinos.org/oldsite/packages/stk/STK_Tutorial_4.pdf</a><br> <br> Or something else?<br> <br> <br> <br> <br>Before tackling that task, I'd like to get your expert insight on a bunch of things: <br><br> <br>* What data types does MOAB support. (I'm looking for something that can be visualized easily, i.e., I want standards. :)<br> <br><br> One good example is mbconvert tool;<br> If you do mbconvert  -l, it will list the supported formats, readers and writers based on build configuration. <br> <br> Our best supported format (native moab format) is based on HDF5. <br> For visualization, we use VisIt and Paraview, and you need to build MOAB plugins for moab native hdf5 format. (or, if you can convert to vtk, you do not need to do anything, use any downloaded VisIt or Paraview)<br> <br> What format do you have for your mesh/data ?<br> <br> <br><br>* How does MOAB treat parallel I/O?<br> <br><br> MOAB HDF5 reader / writer supports parallel IO natively, in the sense every rank is responsible for a portion (part of a partition) of the mesh. Mesh is partitioned using metis or zoltan. <br> <br> <br> <br> <br>* In MOAB's notion of meshes, is it possible to generate edges or faces from purely point/cell input data? <br><br> Do you have a cloud of points ? Or do you have cell data?  For MOAB , a cell is described either as connectivity (list of vertices) or as a polyhedra, in which we have a list of polygons that define each volume; <br> If you have cell data, you can build easily in MOAB a list of adjacent faces or edges. <br> <br> If you have just a cloud of points, you need to build first a mesh, using Delaunay / Voronoi type of algorithms<br> <br> <br>  We have MOAB documentation here<br> <a href="http://press3.mcs.anl.gov/sigma/moab-library/" target="_blank">http://press3.mcs.anl.gov/sigma/moab-library/</a><br> <br> Thanks,<br> Iulian<br> <br> <br> <br>Cheers, <br>Nico<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt"><div style="font-family:Times New Roman;color:#000000;font-size:16px"><div><div dir="ltr">
</div>
</div>
</div>
</div>
</div>

</blockquote></div></div></div></div></div>