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