[MOAB-dev] MOAB insights?

Thu Oct 29 12:45:16 CDT 2015

> what means long for you, and what is the size of the mesh on one
> rank? what is a cell for you? a polyhedra or a
> tet/hex/prism/quad/triangle?

For me, long means (much) longer than the actual (linear) solver in the
end. On a test cube [1] of 140k tets and 27k nodes, creating edges takes
about one minutes, faces about two (on one core that is). The linear solver
in the end takes about seven seconds.

> We could investigate what it would mean for us; Adding more readers
> and writers in parallel is important.

Perhaps I could help you out; I'll probably make that dependent on if/when
I decide to make the switch.

Cheers,
Nico

[1] http://chunk.io/f/34fc1d7ff10f4719a2a72a21ed494b6c

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

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

yes, legacy vtk.

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

no parallel VTK or parallel Exodus, yet.

We could investigate what it would mean for us; Adding more readers and
writers in parallel is important.
(We do read climate pnetcdf files in parallel, and we also write. Exodus
down deep is netcdf based too; we already have exodus serial reader/writer )

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

what means long for you, and what is the size of the mesh on one rank? what
is a cell for you? a polyhedra or a tet/hex/prism/quad/triangle?

we have 2 ways, one classic, and one based on AHF data structure. if mesh
is mixed type (tet + hexas for example) , you have to use classic way; ahf
can be one order of magnitude faster for non-mixed to access and / or query
the subentities.

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/840f2ef4/attachment.html>