<div dir="ltr">Thanks for the comment!<div><br></div><div>To be able to do I/O from a visualizable format directly (without mbconvert or any other tool) is in fact more important to me than not wasting space on storing a mesh more than once (although also interesting). Perhaps these two things can be aligned.</div><div><br></div><div>Cheers,</div><div>Nico</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Apr 7, 2016 at 11:06 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">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 <<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 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 files. I<br>
> usually tell people to grab meshio [1] and convert to a format they use. I<br>
> guess I could extend meshio such that it can translate h5m's tag time series<br>
> data into another format with native series. Anyhow, more work 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 <<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 tags if<br>
>> you want to store time-stepping data. This is what Lukasz is 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 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 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 parallel, to<br>
>> query and visualize solution. Once that is in place, adding capability<br>
>> to show time-series data can be added out of the box. Note that 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 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. There is<br>
>> native support for time-series data with the pure NetCDF route<br>
>> already, written more focused on climate applications [1, 2]. 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] <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>> wrote:<br>
>> > Hello,<br>
>> ><br>
>> > I am not convinced that this is the best approach, however I can tell<br>
>> > how I<br>
>> > do it.<br>
>> ><br>
>> > I create meshset with number of contained meshsets equal to number of<br>
>> > time<br>
>> > steps. Each of contained meshsets has tag, which data on all entities on<br>
>> > meshset which I store for time step. That can be saved in native HD5<br>
>> > file<br>
>> > and read  back if needed without data redundancies and allow to add time<br>
>> > steps. However is a issue of post-processing, that will need some proper<br>
>> > reader for post-procssor which I not currently have.<br>
>> ><br>
>> > There are additional complexities, when you store multiple fields and<br>
>> > you<br>
>> > store data for variable number of entities for each step. In may case I<br>
>> > implemented it like tape recorder, that I have different tapes for which<br>
>> > I<br>
>> > record and play tapes depending on need. If this will be any use for you<br>
>> > pleas look at example,<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 use for<br>
>> > recording another for reading for testing proposes. This works ok, but<br>
>> > is<br>
>> > missing proper reader for paraview and at the end I produce series of<br>
>> > VTKs<br>
>> > for paraview. This is very specific to my development by you 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 read time<br>
>> > series of tags for moab. That if one will write reader for 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 <<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 wondering<br>
>> > about file formats here. Ideally, I'd have one time series per file<br>
>> > (particularly since the mesh isn't changing over time, perhaps that<br>
>> > could be<br>
>> > made use of), but I'm not sure if MOAB's custom HDF5 supports 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 to mind).<br>
>> > Is<br>
>> > this still a thing?<br>
>> ><br>
>> > Cheers,<br>
>> > Nico<br>
>> ><br>
>> ><br>
</blockquote></div>