[MOAB-dev] h5m with data
Nico Schlömer
nico.schloemer at gmail.com
Tue Nov 10 06:06:29 CST 2015
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/f4ea8585/attachment.html>
More information about the moab-dev
mailing list