[MOAB-dev] MOAB insights?

Timothy Tautges timothy.tautges at cd-adapco.com
Sun Nov 1 14:36:06 CST 2015 

Yep. Sounds like you need to test a released version for that.
On Nov 1, 2015 2:28 PM, "Nico Schlömer" <nico.schloemer at gmail.com> wrote:

> Do you mean
> ```
> -t [--tags]       : Write partition by tagging entities
> ```
> ? That doesn't work either. (After mbconvert, the VTK is corrupt.)
>
> --Nico
>
> On Sun, Nov 1, 2015 at 9:18 PM Timothy Tautges <
> timothy.tautges at cd-adapco.com> wrote:
>
>> Write the partition I'd as a cell variable (in mbpart there's an option
>> for that) and that will go through to VTK or exo.
>> On Nov 1, 2015 2:08 PM, "Nico Schlömer" <nico.schloemer at gmail.com> wrote:
>>
>>> 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/c4d15c46/attachment-0001.html>

More information about the moab-dev mailing list