[MOAB-dev] MOAB insights?

Sun Nov 1 14:28:22 CST 2015

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/5f900279/attachment.html>