<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 5, 2014 at 11:53 AM, David E DeMarle <span dir="ltr"><<a href="mailto:dave.demarle@kitware.com" target="_blank">dave.demarle@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><div class="">On Mon, May 5, 2014 at 2:41 PM, Mohammad Mirzadeh <span dir="ltr"><<a href="mailto:mirzadeh@gmail.com" target="_blank">mirzadeh@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><br></div><div>It is more likely the case that a serial reader will be read by everyone and then ParaView will strip out everything but the local chunk on each node.<br>
</div></div></blockquote><div><br></div></div><div>but then isn't this still a limiting factor on the size of the file? I assume you would still get into trouble reading a file that is too big.</div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div></div><div><br></div></div></blockquote></div></div></div></div></blockquote><div><br></div></div><div>I don't think the file size itself is much of a problem these days. Even in 32 bit days you could do it with the right flags. Burlen of course has valid points for extremely large files that you might run across in HPC contexts.<br>
</div><div class=""><div><br></div></div></div></div></div></blockquote><div><br></div><div>Well unless I still don't understand the loading process, I'm thinking that if a process needs to load the whole file into memory and then decide which part its going to keep, it is going to be limited by the file size. For instance in my case the whole vis file is around 8.5 GB and each process normally has access to 2 GB of data (16 process/node -- 32 GB/node). </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div></div><div>The better readers will have each node read only its own portion from the filesystem. Ideally each node's portion is located in its own file because having lots of nodes read from the same big file can be problematic. I don't think we have any parallel-hdf5 readers currently which efficiently read in parallel from a single hdf5 file.</div>
<div><div><br></div></div></div></blockquote></div><div>Hum... that's what I was afraid of. So I assume that currently every processor reads the whole HDF5 file and deletes the unwanted parts?</div></div></div></div>
</blockquote><div><br></div></div><div>Nope. In the case of XDMF every processor reads the whole XML file, and then reads only the parts of the hdf5 file (or better yet files) that they are responsible for.</div><div class="">
<div> </div></div></div></div></div></blockquote><div>Ok this sounds promising then. Just to be sure though, is the reading process essentially serial for HDF5? i.e. no MPI-IO is used for reading the file?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div></div></div></div><div class="gmail_extra"><div><br clear="all"><div>David E DeMarle<br>Kitware, Inc.<br>R&D Engineer<br>21 Corporate Drive<br>Clifton Park, NY 12065-8662<br>Phone: <a href="tel:518-881-4909" value="+15188814909" target="_blank">518-881-4909</a></div>
<br><br></div></div></blockquote></div></div></div></div></div></blockquote></div></div></div></div>
</blockquote></div><br></div></div>