[MOAB-dev] h5m with data

Tue Nov 10 07:28:31 CST 2015

>  We should see if there are other formats provided by
> meshio that may be useful to integrate directly into MOAB so that we

MeshIO undestands legacy VTK (ASCII and binary), VTU, Exodus, Gmsh, and
H5M. Of these, I explicitly need Exodus.

Also, MeshIO doesn't inherit the bugs (e.g., [1]) of mbconvert.

> You can always convert h5m->vtk

Now you can convert to a little more up-to-date formats. :)

Cheers,
Nico

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

On Tue, Nov 10, 2015 at 1:55 PM Vijay S. Mahadevan <vijay.m at gmail.com>
wrote:

> MOAB already provides an array of formats that can be inter-converted
> from/to h5m. We should see if there are other formats provided by
> meshio that may be useful to integrate directly into MOAB so that we
> can increase the extent of I/O formats.
>
> The Paraview plugin is there specifically to visualize a h5m file
> directly. You can always convert h5m->vtk and read that without the
> extension but you end up losing something during conversion due to the
> nature/description of file formats.
>
> Vijay
>
> On Tue, Nov 10, 2015 at 6:06 AM, Nico Schlömer <nico.schloemer at gmail.com>
> wrote:
> > Sounds good!
> > For the meantime, I've created MeshIO [1,2] to convert between various
> mesh
> > file formats, including H5M. This makes installing a ParaView extension
> > unnecessary, at least if you can afford to copy your mesh into another
> > format. I'll put it to the test with one of my applications this week and
> > see if I finally get to read actual data with MAOB. :)
> >
> > Cheers,
> > Nico
> >
> > [1] https://pypi.python.org/pypi/meshio
> > [2] https://github.com/nschloe/meshio
> >
> > On Mon, Nov 9, 2015 at 1:32 PM Vijay S. Mahadevan <vijay.m at gmail.com>
> wrote:
> >>
> >> > Something that would have helped me avoid this extra work is MOAB
> >> > offering
> >> > first-class support for an established standard format (Exodus, VTK,
> >> > XDMF
> >> > come to mind).
> >>
> >> Nico, we will be happy to work with you to add support for more
> >> standard formats. In the realm of parallel I/O, there are very few
> >> solutions that scale well to beyond 10K processors and this is an
> >> active area of improvement in MOAB. There is already support for
> >> legacy VTK and we are planning to add readers/writers for VTK-m in the
> >> next year. Perhaps if we converge on your needs better, we can choose
> >> either Nemesis or XDMF based formats as an alternate format too.
> >>
> >> Vijay
> >>
> >> On Mon, Nov 9, 2015 at 4:29 AM, Nico Schlömer <nico.schloemer at gmail.com
> >
> >> wrote:
> >> > Thanks everyone; I'll plow my way through the format, trying to
> >> > integrate it
> >> > better with the conversion tools I have at hand. Once I'm through
> that I
> >> > think I'll be able to integrate it with my application too.
> >> >
> >> > Something that would have helped me avoid this extra work is MOAB
> >> > offering
> >> > first-class support for an established standard format (Exodus, VTK,
> >> > XDMF
> >> > come to mind).
> >> >
> >> > Anyhow, I'll probably ask one or two more questions about the format
> >> > here,
> >> > so your help is still appreciated! :)
> >> >
> >> > --Nico
> >> >
> >> > On Mon, Nov 9, 2015 at 5:55 AM Vijay S. Mahadevan <vijay.m at gmail.com>
> >> > wrote:
> >> >>
> >> >> Nico, as Patrick mentioned, Tags are the abstract ways to represent,
> >> >> serialize and manipulate data associated with entities in a MOAB
> mesh.
> >> >> Tags can be associated directly with entities such as vertex or
> >> >> element, or you could choose to create sets of entities and associate
> >> >> data to these sets. So based on this degree of representation, we
> have
> >> >> the terminology that a tag can be dense or sparse. This is just an
> >> >> internal way to store these tags to optimize memory layout and does
> >> >> slightly affect how data is serialized/read-back to/from h5m files.
> >> >>
> >> >> Now in terms of usage, just get the tag handle, and you can either
> >> >> read or write to the tag by using tag_get_data and tag_set_data
> >> >> respectively.
> >> >>
> >> >> The SetsNTags [1], VisTags [2] examples show how to read the data
> >> >> stored in h5m. You can use set_tag_data to write this a priori. If
> >> >> needed, we can also create a simplistic example to create/manipulate
> >> >> tag data on a mesh, but I think this may be overkill. Let me know if
> >> >> this would help though.
> >> >>
> >> >> Vijay
> >> >>
> >> >> [1]
> >> >>
> ftp://ftp.mcs.anl.gov/pub/fathom/moab-docs/SetsNTags_8cpp-example.html
> >> >> [2]
> >> >> ftp://ftp.mcs.anl.gov/pub/fathom/moab-docs/VisTags_8cpp-example.html
> >> >>
> >> >> On Sun, Nov 8, 2015 at 8:32 PM, Patrick Shriwise <shriwise at wisc.edu>
> >> >> wrote:
> >> >> > Hey Nico,
> >> >> >
> >> >> > Ok. There doesn't appear to be a great example for applying data.
> >> >> > Applying
> >> >> > data works in a very similar way to the way you retrieve tagged
> data,
> >> >> > using
> >> >> > tag_set_data with a Tag which can be created for a certain type of
> >> >> > data
> >> >> > with
> >> >> > a given name by calling tag_get_handle with the MBCREAT option at
> the
> >> >> > end.
> >> >> > I'd like to be clear that you can apply/retrieve data from MOAB
> >> >> > Entities
> >> >> > or
> >> >> > MOAB EntitySets. So you can either apply data directly to entities
> >> >> > like
> >> >> > vertices or you can group them together in a set and apply data to
> >> >> > that
> >> >> > set
> >> >> > instead. For the purpose you're indicating, it sounds like it'd be
> >> >> > best
> >> >> > to
> >> >> > apply the data directly to the vertices.
> >> >> >
> >> >> > Sample code for creating a MOAB Tag:
> >> >> >   Tag name_tag;
> >> >> >   rval = mdbImpl->tag_get_handle(NAME_TAG_NAME, NAME_TAG_SIZE,
> >> >> > MB_TYPE_OPAQUE,
> >> >> >                                  name_tag, MB_TAG_SPARSE |
> >> >> > MB_TAG_CREAT);
> >> >> > Cheers,
> >> >> >
> >> >> > Patrick C. Shriwise
> >> >> > Research Fellow
> >> >> > University of Wisconsin - Madison
> >> >> > Engineering Research Building - Rm. 428
> >> >> > 1500 Engineering Drive
> >> >> > Madison, WI 53706
> >> >> > (608) 446-8173
> >> >> >
> >> >> > On 11/08/15 21:01, Nico Schlömer wrote:
> >> >> >
> >> >> > In both ways, actually. I need to build h5m files from data and I
> >> >> > need
> >> >> > to
> >> >> > extract data from h5m meshes.
> >> >> > With [1], I'm digging my way through understanding the sets group
> >> >> > now.
> >> >> >
> >> >> > --Nico
> >> >> >
> >> >> > [1] https://trac.mcs.anl.gov/projects/ITAPS/wiki/MOAB/h5m
> >> >> >
> >> >> > On Mon, Nov 9, 2015 at 2:53 AM Patrick Shriwise <shriwise at wisc.edu
> >
> >> >> > wrote:
> >> >> >>
> >> >> >> Hi Nico,
> >> >> >>
> >> >> >> I see. I may have misunderstood your problem. It seems you're
> trying
> >> >> >> to
> >> >> >> apply data to the mesh. Is that right?
> >> >> >>
> >> >> >>
> >> >> >> Cheers,
> >> >> >>
> >> >> >> Patrick C. Shriwise
> >> >> >> Research Fellow
> >> >> >> University of Wisconsin - Madison
> >> >> >> Engineering Research Building - Rm. 428
> >> >> >> 1500 Engineering Drive
> >> >> >> Madison, WI 53706
> >> >> >> (608) 446-8173
> >> >> >>
> >> >> >> On 11/08/15 20:03, Nico Schlömer wrote:
> >> >> >>
> >> >> >> Thanks Patrick for your reply.
> >> >> >>
> >> >> >> I'm still having problems where data should be stores. In a h5m
> >> >> >> file, I
> >> >> >> see tags, I see sets with tags in them, and it seems they are
> >> >> >> somehow
> >> >> >> related, but I don't know where and how to put the actual data. I
> >> >> >> would
> >> >> >> help
> >> >> >> to see a file with some mesh and a custom data element in it,
> e.g.,
> >> >> >> an
> >> >> >> array
> >> >> >> of values associated with the vertices.
> >> >> >>
> >> >> >> Cheers,
> >> >> >> Nico
> >> >> >>
> >> >> >> On Sun, Nov 8, 2015 at 9:20 PM Patrick Shriwise <
> shriwise at wisc.edu>
> >> >> >> wrote:
> >> >> >>>
> >> >> >>> Hi Nico,
> >> >> >>>
> >> >> >>> The vertex data should be stored in MOAB tags. You can access
> these
> >> >> >>> tags
> >> >> >>> via their name. There is a set of conventions for the tag names
> in
> >> >> >>> an
> >> >> >>> Exodus
> >> >> >>> file (here I think). However, if the tag has a custom name and
> >> >> >>> isn't
> >> >> >>> recognized by the Exodus reader, then the data might not be read
> in
> >> >> >>> from the
> >> >> >>> Exodus file and as a result won't be saved into the .h5m. Do you
> >> >> >>> have
> >> >> >>> an
> >> >> >>> idea of what the tag name might be for your data?
> >> >> >>>
> >> >> >>> There's also a good example here of how to access the tag data on
> >> >> >>> an
> >> >> >>> entity. The example I linked you to accesses EntitySets rather
> than
> >> >> >>> Entities, but they work the same way.
> >> >> >>>
> >> >> >>> If you think the data might be in the .h5m, you can use
> >> >> >>> tag_get_tags_on_entity to get all of the tags on a vertex and
> then
> >> >> >>> check for
> >> >> >>> the tag data you're looking for. An easier way of doing this in
> the
> >> >> >>> cmd line
> >> >> >>> is by using mbsize -t <your_file>.h5m to print out the count by
> >> >> >>> tag.
> >> >> >>>
> >> >> >>> Hope this helps!
> >> >> >>>
> >> >> >>> Cheers,
> >> >> >>>
> >> >> >>> Patrick C. Shriwise
> >> >> >>> Research Fellow
> >> >> >>> University of Wisconsin - Madison
> >> >> >>> Engineering Research Building - Rm. 428
> >> >> >>> 1500 Engineering Drive
> >> >> >>> Madison, WI 53706
> >> >> >>> (608) 446-8173
> >> >> >>>
> >> >> >>> On 11/08/15 13:43, Nico Schlömer wrote:
> >> >> >>>
> >> >> >>> Hi everyone,
> >> >> >>>
> >> >> >>> I have an Exodus file with vertex data in it (i.e., "a function"
> >> >> >>> defined
> >> >> >>> on the vertices). When converting this file to h5m, where does
> the
> >> >> >>> vertex
> >> >> >>> data go? And how to I retrieve the data after having it read with
> >> >> >>> `load_file()`?
> >> >> >>>
> >> >> >>> Cheers,
> >> >> >>> Nico
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20151110/0ca22178/attachment-0001.html>