<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">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>