Thanks Barry. <div><div>Well, I guess it all comes from the fact that I want it all. </div><div>I wanted to have everything done only once. Data that can be also read in a visualization package. </div><div>Then I guess I have to stick with my old strategy of having everything stored in binary and using a postprocessor to make hdft or vtk format data files for visualization. </div>
<div><br></div><div>Cheers, </div><div>Mohamad</div><div><br></div><div><br><div class="gmail_quote">On Tue, Jan 31, 2012 at 2:39 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Jan 31, 2012, at 4:34 PM, Mohamad M. Nasr-Azadani wrote:<br>
<br>
> Hi all,<br>
><br>
> I was using VecView() to write the data to file (a vector of total size 50*20*10 (3D DMDA)).<br>
> I compared the times for two cases: PETSc's binary and also HDF5.<br>
> I get an enormous difference between the times I get for these two cases (this test is done using only one processor)<br>
><br>
> HDF5: 16.2 (sec)<br>
> Binary: 0.33 (sec).<br>
><br>
> I am using HDF5 VecView() as a magic black box writer to dump the field quantities. And I am not an expert on it but this order of magnitude seems a bit strange to me.<br>
<br>
</div></div> I am not surprised at all. Just because HDF5 is a "defacto standard" and "supposedly" a good thing to use doesn't mean it will be faster than something else.<br>
<br>
I would only use HDF5 when the resulting file needs to be HDF5 for some other software, like visualization. If you are just using the file with PETSc then use PETSc's binary.<br>
<span class="HOEnZb"><font color="#888888"><br>
Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
><br>
> Any inputs are appreciated!<br>
> Best,<br>
> Mohamad<br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>