[MOAB-dev] MOAB insights?

Sun Nov 1 14:08:40 CST 2015

I can convert from VT*, Exodus to h5m now, so I'll probably go ahead and
see if I can integrate MOAB into our test suite. The serial case seems
pretty doable, for parallel I/O I'll probably need a little longer.

Btw, is there a way to visualize the partition in ParaView without using
the plugin? I thought of converting the resulting h5m into VTK, but a MOAB
bug [1] keeps me from doing so.

Cheers,
Nico

[1]
https://bitbucket.org/fathomteam/moab/issues/23/mbconvert-cell-array-global_id-with-1

On Sun, Nov 1, 2015 at 8:54 PM Timothy Tautges <
timothy.tautges at cd-adapco.com> wrote:

> And, you know moab has an exo writer, right? Should only need to add the
> nemesis records to make that parallel.
> On Nov 1, 2015 1:52 PM, "Timothy Tautges" <timothy.tautges at cd-adapco.com>
> wrote:
>
>> Call get_adjacencies with the book flag true, requesting all faces from
>> elements then all edge's from elems. There's an equivalent itaps call to
>> request a full mesh but I forget what it is.
>> On Nov 1, 2015 1:09 PM, "Nico Schlömer" <nico.schloemer at gmail.com> wrote:
>>
>>> I'm writing a little conversion tool from VT*/Exodus to h5m, and I'm
>>> having some trouble with the edges/faces. For example, I can read node and
>>> element info from a VTK file; I can also write it out to a h5m file, see
>>> [1].
>>>
>>> This file gets read alright by the HelloMOAB example, and reports
>>> ```
>>> Number of vertices is 21218
>>> Number of edges is 0
>>> Number of faces is 0
>>> Number of elements is 91215
>>> ```
>>> All good.
>>>
>>> Now, I would like have edges and faces. Can I create those entities at
>>> all? Or is there a MOAB tool to enrich a given h5m file [1] with edges and
>>> faces?
>>>
>>> Cheers,
>>> Nico
>>>
>>> [1] http://chunk.io/f/836dc0de673947b8ac72ad0181f57862
>>>
>>> On Sat, Oct 31, 2015 at 5:34 PM Nico Schlömer <nico.schloemer at gmail.com>
>>> wrote:
>>>
>>>> Sounds interesting!
>>>>
>>>>
>>>> > As I said, we use Visit or Paraview (with plugins for moab h5m file)
>>>>
>>>> This is the only thing I'm worried about. I mean, I myself could easily
>>>> do that, but I can't possibly demand this from my users. I already see them
>>>> failing to set up their viewers.
>>>>
>>>> A tool that can convert between h5m, vtk, vtu, exodus etc. would
>>>> certainly help. I already have a tool in place for all of the rest [1].
>>>> Perhaps it's an easy addition with [2].
>>>> Ideal, as Timothy suggests, would be if MOAB supported (parallel) I/O
>>>> with Exodus or VTU.
>>>>
>>>> Cheers,
>>>> Nico
>>>>
>>>> [1] https://github.com/nschloe/pygmsh/blob/master/tools/pygmsh-convert
>>>> [2] http://www.h5py.org/
>>>>
>>>>
>>>> On Sat, Oct 31, 2015 at 4:56 PM Grindeanu, Iulian R. <
>>>> iulian at mcs.anl.gov> wrote:
>>>>
>>>>> Hi Nico,
>>>>>
>>>>> As I said, we use Visit or Paraview (with plugins for moab h5m file)
>>>>> we partition with mbpart (backend is zoltan or metis, directly)
>>>>> an msh file for gmsh can be partitioned with
>>>>>  mbpart 10 -z RCB screw.msh  screw.h5m
>>>>>
>>>>>
>>>>> partition means we add sets to our h5m file, that can be interpreted
>>>>> by visit plugin
>>>>>
>>>>>
>>>>>
>>>>> the file can be read in parallel/processed by moab application
>>>>>
>>>>> output is another h5m file (with new tags for new solution variables,
>>>>> which can be usually read by visit plugin directly from the file)
>>>>>
>>>>>
>>>>> If the file is too big, we can "extract" with some tools a portion only
>>>>>
>>>>> One issue is mbpart does not work in parallel now, but we will add
>>>>> that in the next release
>>>>>
>>>>>
>>>>> As long as you can read the file (  it was generated by one task),
>>>>> mbpart can partition it
>>>>>
>>>>> Iulian
>>>>>
>>>>> ------------------------------
>>>>> *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> 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/20151101/3cd9c60a/attachment.html>