<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Mohammad,<br>
    <br>
    This is not an answer to your question but there is a usage caveat
    w/ VTK XML files that I want to make sure you're aware of.  When you
    use that format make sure you set mode to "appended" and "encode"
    off. This is the combination to produce binary files which are going
    to be faster and very likely smaller too. You probably already know
    that, but just in case ...<br>
    <br>
    now to get to your question:<br>
    <blockquote type="cite">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</blockquote>
    comment: If I were you I'd avoid putting all time steps in a single
    file, or any solution where files get too big. Once files occupy
    more than ~80% of a tape drive you'll have very hard time getting
    them on and off archive systems. see this:
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a
href="http://www.nersc.gov/users/data-and-file-systems/hpss/storing-and-retrieving-data/mistakes-to-avoid/">http://www.nersc.gov/users/data-and-file-systems/hpss/storing-and-retrieving-data/mistakes-to-avoid/</a>
    My comment assumes that you actually use such systems. But you
    probably will need to if you generate large datasets at common HPC
    centers.<br>
    <br>
    I've seen some AMR codes get elaborate in their HDF5 formats and run
    into serious performance issues as a result. So my comment here is
    that if you go with HDF5, keep the format as simple as possible! and
    of course file sizes small enough to be archived ;-)<br>
    <br>
    Burlen<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 05/05/2014 10:48 AM, Mohammad
      Mirzadeh wrote:<br>
    </div>
    <blockquote
cite="mid:CAKsPKwm6ZaZDfbKoVotD8H+DbNWhx8KhWUBMiRJWfC=wsBbHgg@mail.gmail.com"
      type="cite">
      <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 moz-do-not-send="true"
              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="">
                _______________________________________________<br>
                Powered by <a moz-do-not-send="true"
                  href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
                <br>
                Visit other Kitware open-source projects at <a
                  moz-do-not-send="true"
                  href="http://www.kitware.com/opensource/opensource.html"
                  target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
                <br>
                Please keep messages on-topic and check the ParaView
                Wiki at: <a moz-do-not-send="true"
                  href="http://paraview.org/Wiki/ParaView"
                  target="_blank">http://paraview.org/Wiki/ParaView</a><br>
                <br>
                Follow this link to subscribe/unsubscribe:<br>
                <a moz-do-not-send="true"
                  href="http://www.paraview.org/mailman/listinfo/paraview"
                  target="_blank">http://www.paraview.org/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 moz-do-not-send="true"
                  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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Powered by <a class="moz-txt-link-abbreviated" href="http://www.kitware.com">www.kitware.com</a>

Visit other Kitware open-source projects at <a class="moz-txt-link-freetext" href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a>

Please keep messages on-topic and check the ParaView Wiki at: <a class="moz-txt-link-freetext" href="http://paraview.org/Wiki/ParaView">http://paraview.org/Wiki/ParaView</a>

Follow this link to subscribe/unsubscribe:
<a class="moz-txt-link-freetext" href="http://www.paraview.org/mailman/listinfo/paraview">http://www.paraview.org/mailman/listinfo/paraview</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>