[MOAB-dev] MOAB insights?

[Nico Schlömer]

> 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>
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]
> *Sent:* Saturday, October 31, 2015 9:08 AM
>
> *To:* Grindeanu, Iulian R.; 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>
> 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]
>> *Sent:* Thursday, October 29, 2015 3:37 PM
>>
>> *To:* Grindeanu, Iulian R.; 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>
>> wrote:
>>
>>>
>>> ------------------------------
>>> *From:* Nico Schlömer [nico.schloemer at gmail.com]
>>> *Sent:* Thursday, October 29, 2015 12:45 PM
>>> *To:* Grindeanu, Iulian R.; 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/0a888532/attachment-0001.html>