<div dir="ltr">They are represented as unstructured grid. As a sample run, a 100M grid point on 256 proc produces almost 8.5G file. We intent to push the limits close to 1B at most at this time with # processors up to a few thousands. However, it would be good to have something that could scale to larger problems as well</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, May 3, 2014 at 1:28 AM, Stephen Wornom <span dir="ltr"><<a href="mailto:stephen.wornom@inria.fr" target="_blank">stephen.wornom@inria.fr</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Mohammad Mirzadeh wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi I am at a critical point in deciding I/O format for my application. So far my conclusion is to use parallel HDF5 for restart files as they are quite flexible and portable across systems.<br>
<br>
When it comes to visualization, however, i'm not quite sure. Up until now I've been using pvtu along with vtu files and although they generally work fine, one easily gets in trouble when running big simulations on large number of processors as the number of files can easily get out of control and even simplest utility commands (e.g. ls) takes minutes to finish!<br>


<br>
After many thinking I've come to a point to decide between two strategies:<br>
<br>
1) Go with a single parallel HDF5 file that includes data for all time-steps. This makes it all nice and portable except there are two issues. i) It looks like doing MPI-IO might not be as efficient as separate POSIX IO, especially on large number of processors. ii) ParaView does not seem to be able to read HDF5 files in parallel<br>


<br>
2) Go with the same pvtu+vtu strategy except take precautions to avoid file explosions. I can think of two strategies here: i) use nested folders to separate vtu files from pvtu and also each time step ii) create an IO group communicator with much less processors that do the actual IO.<br>


<br>
My questions are 1) Is the second approach necessarily more efficient than MPI-IO used in HDF5? and 2) Is there any plan to support parallel IO for HDF5 files in paraview?<br>
<br>
<br></div></div><div class="">
______________________________<u></u>_________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/<u></u>opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the ParaView Wiki at: <a href="http://paraview.org/Wiki/ParaView" target="_blank">http://paraview.org/Wiki/<u></u>ParaView</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/<u></u>mailman/listinfo/paraview</a><br>
</div></blockquote>
Are your meshes structured or unstructured? How many vertices in your meshes?<span class="HOEnZb"><font color="#888888"><br>
<br>
Stephen<br>
<br>
-- <br>
<a href="mailto:stephen.wornom@inria.fr" target="_blank">stephen.wornom@inria.fr</a><br>
2004 route des lucioles - BP93<br>
Sophia Antipolis<br>
06902 CEDEX<br>
                <br>
Tel: 04 92 38 50 54<br>
Fax: 04 97 15 53 51<br>
<br>
</font></span></blockquote></div><br></div>