[MOAB-dev] MOAB insights?

Sat Oct 31 11:10:43 CDT 2015

I think you did not get the attachment before

________________________________
From: Nico Schlömer [nico.schloemer at gmail.com]
Sent: Saturday, October 31, 2015 10:25 AM
To: Grindeanu, Iulian R.; moab-dev at mcs.anl.gov
Subject: Re: [MOAB-dev] MOAB insights?

> what "standard" do you need ? Do you have an example ?

Something that can be consumed by VTK/ParaView or for which there is a sufficiently broad user base (e.g., XDMF).

The typical workflow right now:

* Use Gmsh [1]/PyGmsh [2] to generate a mesh
* use PyGmsh [2]/VTK [3] to translate the file into Exodus (.e)
* use decomp from SEACAS [4] to split it into a set (e.g., .e.10.*)
* Feed those files in parallel into the code, using STK/SEACAS.
* run the code, get the output in split Exodus files
* use ejoin from SEACAS to put them back together to one single Exodus file
* visualize with Paraview.

A crucial part here is the decomp which hooks up to Zoltan to generate a partition. I'm not tied to this, and if there is a tool that, for example, splits VTU files into PVTU, I'd be happy to use that.

(Side note: Parallel Exodus is sometimes known as Nemesis, I believe.)

What's the typical MOAB workflow? How do you visualize the data?

Cheers,
Nico

[1] http://geuz.org/gmsh/
[2] https://pypi.python.org/pypi/pygmsh
[3] http://www.vtk.org/
[4] https://launchpad.net/~nschloe/+archive/ubuntu/seacas-nightly

On Sat, Oct 31, 2015 at 3:57 PM Grindeanu, Iulian R. <iulian at mcs.anl.gov<mailto:iulian at mcs.anl.gov>> wrote:
Hi Nico,
maybe you can describe your tool set a little
exodus is supported by moab; what is parallel exodus?

If your model is described in a series of files, we also have parallel merge tool, that can be used to stitch models in parallel
(in short, each task loads a file in serial, which is a part in a partition, then parallel merge can be used to have a global view / access, identify shared entities and enable ghosting; this assumes that the parts are "conforming" and not overlapping, as a geometric tolerance is used to identify common vertices)

what  "standard" do you need ? Do you have an example ?

Best Regards,
Iulian

________________________________
From: Nico Schlömer [nico.schloemer at gmail.com<mailto:nico.schloemer at gmail.com>]
Sent: Saturday, October 31, 2015 9:08 AM

To: Grindeanu, Iulian R.; moab-dev at mcs.anl.gov<mailto:moab-dev at mcs.anl.gov>
Subject: Re: [MOAB-dev] MOAB insights?
Thanks everyone!

I believe that right now, I cannot efficiently use MOAB yet. We really need to be able to read from standardized file formats like XDMF, VTU, Exodus. This is what the tool set is composed around, and it'd probably much work to get it right for MOAB's custom HDF5-thing.

That said, I'd be happy to help out with extending MOAB in these directions. Perhaps after the release, we can arrange a plan.

Cheers,
Nico

On Fri, Oct 30, 2015 at 12:40 AM Grindeanu, Iulian R. <iulian at mcs.anl.gov<mailto:iulian at mcs.anl.gov>> wrote:
Hi Nico,
Sorry I missed your message
I modified one of the examples to construct all edges and faces, and output them in some files

after compiling it, you can launch it with

./HelloMOAB

or
./HelloMOAB <other_file>

other_file can be any file that can be loaded in MOAB, in serial (for example, a gmsh file)

for parallel IO, you can look at HelloParMOAB example, or tests in test/parallel

There is a list of examples on doxygen page, with more links on how is data accessed.
http://ftp.mcs.anl.gov/pub/fathom/moab-docs/examples.html

Iulian

________________________________
From: Nico Schlömer [nico.schloemer at gmail.com<mailto:nico.schloemer at gmail.com>]
Sent: Thursday, October 29, 2015 3:37 PM

To: Grindeanu, Iulian R.; moab-dev at mcs.anl.gov<mailto:moab-dev at mcs.anl.gov>
Subject: Re: [MOAB-dev] MOAB insights?
Absolutely!

I'm interested to see
 * how I/O works,
 * how edges/faces arecreated,
 * how relationships are queried (Which cells does this face border on? Which nodes does this cell have? etc)

If there's an example in the sources, I'd be more than happy to look at that, too, of course.

Cheers,
Nico

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

________________________________
From: Nico Schlömer [nico.schloemer at gmail.com<mailto:nico.schloemer at gmail.com>]
Sent: Thursday, October 29, 2015 12:45 PM
To: Grindeanu, Iulian R.; moab-dev at mcs.anl.gov<mailto:moab-dev at mcs.anl.gov>
Subject: Re: [MOAB-dev] MOAB insights?

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

hmmm, that is too long, indeed.

For moab, creating the edges and/or faces for that size of a mesh is on the order  of seconds, on a laptop

I will write a small example if you are interested

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20151031/0092c045/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screw.png
Type: image/png
Size: 138844 bytes
Desc: Screw.png
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20151031/0092c045/attachment-0001.png>