[MOAB-dev] MOAB insights?

[Timothy Tautges]

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/cbfaeafc/attachment-0001.html>