[MOAB-dev] MOAB insights?

[Nico Schlömer]

> What stk format? this one?

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).

> Our best supported format (native moab format) is based on HDF5.

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.

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?

> What format do you have for your mesh/data ?

I'm quite flexible between Exodus and VTK.

> 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.

That's the way it should be. Again, no support for standard data formats
here; parallel Exodus, parallel VTK?

> If you have cell data, you can build easily in MOAB a list of adjacent
> faces or edges.

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?

Cheers,
Nico




On Thu, Oct 29, 2015 at 3:13 PM Grindeanu, Iulian R. <iulian at mcs.anl.gov>
wrote:



Hi Nico,

Thanks for your help with debian support
Please see below



From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on behalf
of Nico Schlömer [nico.schloemer at gmail.com]
Sent: Thursday, October 29, 2015 8:16 AM
To: moab-dev at mcs.anl.gov
Subject: [MOAB-dev] MOAB insights?




Hi everyone,



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).


What stk format?
this one?
https://trilinos.org/oldsite/packages/stk/STK_Tutorial_4.pdf

Or something else?




Before tackling that task, I'd like to get your expert insight on a bunch
of things:


* What data types does MOAB support. (I'm looking for something that can be
visualized easily, i.e., I want standards. :)


One good example is mbconvert tool;
If you do mbconvert -l, it will list the supported formats, readers and
writers based on build configuration.

Our best supported format (native moab format) is based on HDF5.
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)

What format do you have for your mesh/data ?



* How does MOAB treat parallel I/O?


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.




* In MOAB's notion of meshes, is it possible to generate edges or faces
from purely point/cell input data?

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;
If you have cell data, you can build easily in MOAB a list of adjacent
faces or edges.

If you have just a cloud of points, you need to build first a mesh, using
Delaunay / Voronoi type of algorithms


We have MOAB documentation here
http://press3.mcs.anl.gov/sigma/moab-library/

Thanks,
Iulian



Cheers,
Nico

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20151029/6a0f8e12/attachment.html>