<p dir="ltr">Yes this is an interesting extension and we can certainly add something natively in MOAB. </p>
<p dir="ltr">Jacob, if you can point us to your code and/or want to submit a PR for new reader/writer, we would happy to add the capability for xdmf. </p>
<p dir="ltr">Vijay </p>
<div class="gmail_quote">On Apr 8, 2016 7:49 AM, "Nico Schlömer" <<a href="mailto:nico.schloemer@gmail.com">nico.schloemer@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">> The xml file very generation is very quick with a simple python script<div>> (we have written to general python classes for this, if you're interested).  <br><div><br></div><div>Very much so; where do I find the code? <span style="line-height:1.5">Perhaps this could even be included in MOAB itself.</span></div></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Cheers,</span></div><div><span style="line-height:1.5">Nico</span></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Apr 8, 2016 at 2:43 PM Jacob Hochhalter <<a href="mailto:Jacob.D.Hochhalter@nasa.gov" target="_blank">Jacob.D.Hochhalter@nasa.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
We have had this issue come up too.  Our solution, which we have been<br>
very happy with so far, is to use the .h5m file as part of the XDMF<br>
concept (see <a href="http://www.xdmf.org/index.php/Main_Page" rel="noreferrer" target="_blank">http://www.xdmf.org/index.php/Main_Page</a>).  With that<br>
approach, we simply 'wrap' the .h5m file with a xml file, which<br>
describes which data we want to visualize (and how).  There is no<br>
duplication of the mesh or results data, since the xml file simply<br>
'points' to datasets in the h5m file.  The xml file very generation is<br>
very quick with a simple python script (we have written to general<br>
python classes for this, if you're interested).  An added bonus is that<br>
both VisIt and Paraview support XDMF inherently.<br>
<br>
- Jake<br>
<br>
On 04/08/2016 03:31 AM, Nico Schlömer wrote:<br>
> Thanks for the comment!<br>
><br>
> To be able to do I/O from a visualizable format directly (without<br>
> mbconvert or any other tool) is in fact more important to me than not<br>
> wasting space on storing a mesh more than once (although also<br>
> interesting). Perhaps these two things can be aligned.<br>
><br>
> Cheers,<br>
> Nico<br>
><br>
> On Thu, Apr 7, 2016 at 11:06 PM Vijay S. Mahadevan <<a href="mailto:vijay.m@gmail.com" target="_blank">vijay.m@gmail.com</a><br>
> <mailto:<a href="mailto:vijay.m@gmail.com" target="_blank">vijay.m@gmail.com</a>>> wrote:<br>
><br>
>     Nico, if the time series data are stored as separate tags, like<br>
>     [SOLUTION_STEP0, SOLUTION_STEP1, .., SOLUTION_STEPN], any of the<br>
>     conversion tools should provide the right data output that can be<br>
>     visualized easily.<br>
><br>
>     You should be able to use mbconvert that gets installed with MOAB for<br>
>     the conversion. Of course, if you want exodus output, you will need<br>
>     the NetCDF dependency enabled. VTK is available out of the box though.<br>
><br>
>     We can also discuss more about the time series data and not writing<br>
>     the mesh more than once, especially for static non-AMR simulations. We<br>
>     should be able to find some time in the summer or a little later to<br>
>     implement this functionality within MOAB.<br>
><br>
>     Vijay<br>
><br>
>     On Wed, Apr 6, 2016 at 2:46 PM, Nico Schlömer<br>
>     <<a href="mailto:nico.schloemer@gmail.com" target="_blank">nico.schloemer@gmail.com</a> <mailto:<a href="mailto:nico.schloemer@gmail.com" target="_blank">nico.schloemer@gmail.com</a>>> wrote:<br>
>     > Thanks for the comments!<br>
>     ><br>
>     >> the visualization is the tricky bit tere since none of the main<br>
>     tools<br>
>     >> (VisIt, Paraview) understand the<br>
>     >> details of the layout explicitly<br>
>     >> [...]<br>
>     >>  if we understand your needs better.<br>
>     ><br>
>     > The question I have to answer the most is how to visualize H5M<br>
>     files. I<br>
>     > usually tell people to grab meshio [1] and convert to a format<br>
>     they use. I<br>
>     > guess I could extend meshio such that it can translate h5m's tag<br>
>     time series<br>
>     > data into another format with native series. Anyhow, more work<br>
>     for me and<br>
>     > for the users (to convert), so I'm not so happy with that yet.<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>
>     ><br>
>     > On Wed, Apr 6, 2016 at 4:49 PM Vijay S. Mahadevan<br>
>     <<a href="mailto:vijay.m@gmail.com" target="_blank">vijay.m@gmail.com</a> <mailto:<a href="mailto:vijay.m@gmail.com" target="_blank">vijay.m@gmail.com</a>>> wrote:<br>
>     >><br>
>     >> Hi NIco,<br>
>     >><br>
>     >> Our current HDF5-based I/O workflow supports adding arbitrary<br>
>     tags if<br>
>     >> you want to store time-stepping data. This is what Lukasz is<br>
>     doing for<br>
>     >> his needs and should extend arbitrarily to other applications using<br>
>     >> MOAB. As Lukasz also mentioned, the visualization is the tricky bit<br>
>     >> here since none of the main tools (VisIt, Paraview) understand the<br>
>     >> details of the layout explicitly and so only expose part of the<br>
>     data<br>
>     >> available in h5m files. I've also been think about enhancements to<br>
>     >> support multiple HDF5 files, where the mesh is written out only<br>
>     >> initially and when it changes. But this is a little more<br>
>     involved for<br>
>     >> the book-keeping to remain general.<br>
>     >><br>
>     >> On a related note, we are working with LLNL to add a native MOAB<br>
>     >> plugin to VisIt, that directly uses MOAB underneath, in<br>
>     parallel, to<br>
>     >> query and visualize solution. Once that is in place, adding<br>
>     capability<br>
>     >> to show time-series data can be added out of the box. Note that<br>
>     MOAB<br>
>     >> already supports only loading partial sets and tags, if you are<br>
>     >> concerned about the data movement with I/O for large simulation<br>
>     runs.<br>
>     >><br>
>     >> However, we have also been considering alternatives that support<br>
>     >> parallel I/O. Yes, from our discussions, I believe we converged on<br>
>     >> XDMF and Exodus/Nemesis. Currently, this is a bottleneck on the<br>
>     >> resources available to us and so has been in the back burner.<br>
>     There is<br>
>     >> native support for time-series data with the pure NetCDF route<br>
>     >> already, written more focused on climate applications [1, 2].<br>
>     We can<br>
>     >> also talk about extending this to more general use cases, if we<br>
>     >> understand your needs better.<br>
>     >><br>
>     >> Thoughts ?<br>
>     >><br>
>     >> Vijay<br>
>     >><br>
>     >> [1] <a href="https://www.ncl.ucar.edu/ParVis.shtml" rel="noreferrer" target="_blank">https://www.ncl.ucar.edu/ParVis.shtml</a><br>
>     >> [2]<br>
>     <a href="https://cfwebprod.sandia.gov/cfdocs/CompResearch/docs/template.pdf" rel="noreferrer" target="_blank">https://cfwebprod.sandia.gov/cfdocs/CompResearch/docs/template.pdf</a><br>
>     >><br>
>     >> On Wed, Apr 6, 2016 at 6:34 AM, Lukasz Kaczmarczyk<br>
>     >> <<a href="mailto:Lukasz.Kaczmarczyk@glasgow.ac.uk" target="_blank">Lukasz.Kaczmarczyk@glasgow.ac.uk</a><br>
>     <mailto:<a href="mailto:Lukasz.Kaczmarczyk@glasgow.ac.uk" target="_blank">Lukasz.Kaczmarczyk@glasgow.ac.uk</a>>> wrote:<br>
>     >> > Hello,<br>
>     >> ><br>
>     >> > I am not convinced that this is the best approach, however I<br>
>     can tell<br>
>     >> > how I<br>
>     >> > do it.<br>
>     >> ><br>
>     >> > I create meshset with number of contained meshsets equal to<br>
>     number of<br>
>     >> > time<br>
>     >> > steps. Each of contained meshsets has tag, which data on all<br>
>     entities on<br>
>     >> > meshset which I store for time step. That can be saved in<br>
>     native HD5<br>
>     >> > file<br>
>     >> > and read  back if needed without data redundancies and allow<br>
>     to add time<br>
>     >> > steps. However is a issue of post-processing, that will need<br>
>     some proper<br>
>     >> > reader for post-procssor which I not currently have.<br>
>     >> ><br>
>     >> > There are additional complexities, when you store multiple<br>
>     fields and<br>
>     >> > you<br>
>     >> > store data for variable number of entities for each step. In<br>
>     may case I<br>
>     >> > implemented it like tape recorder, that I have different<br>
>     tapes for which<br>
>     >> > I<br>
>     >> > record and play tapes depending on need. If this will be any<br>
>     use for you<br>
>     >> > pleas look at example,<br>
>     >> ><br>
>     >> ><br>
>     <a href="http://mofem.eng.gla.ac.uk/mofem/html/record__series__atom_8cpp_source.html" rel="noreferrer" target="_blank">http://mofem.eng.gla.ac.uk/mofem/html/record__series__atom_8cpp_source.html</a><br>
>     >> > In example I have two tapes there and two moab instances, one<br>
>     use for<br>
>     >> > recording another for reading for testing proposes. This<br>
>     works ok, but<br>
>     >> > is<br>
>     >> > missing proper reader for paraview and at the end I produce<br>
>     series of<br>
>     >> > VTKs<br>
>     >> > for paraview. This is very specific to my development by you<br>
>     can use it<br>
>     >> > as<br>
>     >> > idea if you like it.<br>
>     >> ><br>
>     >> > I would be great to have some common interface to record and<br>
>     read time<br>
>     >> > series of tags for moab. That if one will write reader for<br>
>     paraview it<br>
>     >> > could<br>
>     >> > be used by several developers woking on different codes.<br>
>     >> ><br>
>     >> ><br>
>     >> > Regards,<br>
>     >> > Lukasz<br>
>     >> ><br>
>     >> ><br>
>     >> ><br>
>     >> ><br>
>     >> ><br>
>     >> > On 6 Apr 2016, at 10:02, Nico Schlömer<br>
>     <<a href="mailto:nico.schloemer@gmail.com" target="_blank">nico.schloemer@gmail.com</a> <mailto:<a href="mailto:nico.schloemer@gmail.com" target="_blank">nico.schloemer@gmail.com</a>>> wrote:<br>
>     >> ><br>
>     >> > Hi everyone,<br>
>     >> ><br>
>     >> > I'll start tackling a time-series problem rather soon and I'm<br>
>     wondering<br>
>     >> > about file formats here. Ideally, I'd have one time series<br>
>     per file<br>
>     >> > (particularly since the mesh isn't changing over time,<br>
>     perhaps that<br>
>     >> > could be<br>
>     >> > made use of), but I'm not sure if MOAB's custom HDF5 supports<br>
>     that yet.<br>
>     >> ><br>
>     >> > Thinking of which, I faintly remember there had been talk about<br>
>     >> > switching to<br>
>     >> > a better-supported format in the future (xdmf and exodus came<br>
>     to mind).<br>
>     >> > Is<br>
>     >> > this still a thing?<br>
>     >> ><br>
>     >> > Cheers,<br>
>     >> > Nico<br>
>     >> ><br>
>     >> ><br>
><br>
<br>
</blockquote></div>
</blockquote></div>