Hi Paul,
as you and Dan already stated, the HDF5 format is a very good choice to
write out large datasets.
I usually write the HDF5 files directly from my simulation codes and
generate a XDMF file afterwards.
The actual XDMF file contains just the meta data in XML format [1] and
this can be tailored to your application/dataset (I use python with h5py
and xml.etree to do this).
Hence, my simulation codes (written in C++) only depend on the HDF5
libraries.
Eventually, this will enable you to store your data in a robust,
flexible and portable file format.
For more complex setups I would also consider using the VTK libraries to
handle the data IO as Dan suggested.
-Armin
[1] http://www.xdmf.org/index.php/XDMF_Model_and_Format
On 06/07/2015 10:40 PM, Dan Lipsa wrote:
You are right, ParaView does not read hdf5 directly but rather hdf5
based formats (hdf5 + additional info): both netcdf and xdmf have readers.
You can get a list of all readers supported by your ParaView
installation using Help in ParaView. Additional readers can be enabled with
compile time options.
You can write Xdmf data using vtkXdmfWriter or vtkXdm3Writer (you'll
have to link with the VTK library). These writers have tests which is a
good way to see an example of how to use the class. You can also take a
look at the VTK XML based formats: vtkXMLPolyDataWriter,
vtkXMLImageDataWriter, vtkXMLUnstructuredGridWriter/Reader. Probably you
could write data with a library that comes with that format and then
read it with ParaView.
Do you need parallel writing/reading?
Dan
On Sun, Jun 7, 2015 at 4:26 AM Paul Anton Letnes <[email protected]
<mailto:[email protected]>> wrote:
Hi Dan!
I’m familiar with the HDF5 library and documentation, but thanks
anyway for the link.
I don’t see how I can have ParaView read and understand HDF5 files.
That is, there are several readers (e.g. H5Nimrod) that use HDF5 as
the underlying format, but I don’t see how to get paraview to
understand which arrays are coordinates (nodes?), which are results,
etc. for my application.
Perhaps I should stress again that I have limited experience with
ParaView, and since the supported file formats and possibilities
seem endless, I have trouble getting an overview of sensible choices.
My preference for hdf5 is partly due to other software in my
organization supporting this format, and my own familiarity with it.
Paul
> On 7. jun. 2015, at 04.07, Dan Lipsa <[email protected]
<mailto:[email protected]>> wrote:
>
> Hi Paul,
> Indeed #2 makes sense, especially if you want to change the
in-house format. To write the file (from the simulation) it seems to
me you should checkout
>
> https://www.hdfgroup.org/HDF5/doc/fortran/index.html
>
> I don't see why ParaView would be used in that process. Am I
missing something?
> Dan
>
>
>
> On Sat, Jun 6, 2015 at 8:04 AM Paul Anton Letnes <[email protected]
<mailto:[email protected]>> wrote:
> Hi, fellow paraviewers!
>
> I’ve spent some time playing with tutorials and user manuals, and
so far I’m impressed with what paraview can do.
>
> I am working on a specialized structural engineering program
that, mainly, performs simulations of pipes with circular cross
sections. Each pipe is split into nodes and 1D elements, and results
are reported at points (or, less commonly, elements) along the pipe.
>
> Some results are reported once per cross section; e.g, the
tension in the pipe has a single value for the entire cross section.
Other results, e.g. plastic strain, is reported for a number of
points along the circumference of the pipe (say, 5-50 points), for
each of the cross sections. The results can be either “snapshots” or
time series.
>
> After what I’ve seen from the paraview documentation, possible
approaches include:
> 1. Create a paraview plugin to read our current in-house file format.
> 2. Directly write output files in an already supported format.
> 3. Write pvpython scripts that perform the conversion on the fly.
>
> Approach 1 is probably a lot of work and the file format is not
of interest to anyone else (optimally, I’d like to replace it), so
this seems less attractive. Approach 3 is probably less
user-friendly for our users.
>
> The second approach seems sensible, but the paraview
documentation does not give many examples of how to do this.
Optimally, I’d like to write a hdf5-based format (xdmf? netcdf? raw
hdf5?) directly from Fortran, but I haven’t found documentation on
how to do this. Using hdf5 seems attractive as it’s so widely
supported by e.g. matlab, python, and other postprocessing tools
used in the industry. Getting a single results database would
simplify a lot of workflows!
>
> What would you guys do?
>
> Cheers
> Paul
> _______________________________________________
> Powered by www.kitware.com <http://www.kitware.com>
>
> Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
>
> Search the list archives at: http://markmail.org/search/?q=ParaView
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Search the list archives at: http://markmail.org/search/?q=ParaView
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView
Search the list archives at: http://markmail.org/search/?q=ParaView
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
