<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 14, 2017 at 10:35 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">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"><span class=""><br>
> On Sep 14, 2017, at 11:10 AM, Kong, Fande <<a href="mailto:fande.kong@inl.gov">fande.kong@inl.gov</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, Sep 14, 2017 at 9:47 AM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
> On Thu, Sep 14, 2017 at 11:43 AM, Adriano Côrtes <<a href="mailto:adrimacortes@gmail.com">adrimacortes@gmail.com</a>> wrote:<br>
> Dear Matthew,<br>
><br>
> Thank you for your return. It worked, but this prompts another question. So why PetscViewer does not write both files (.h5 and .xmf) directly, instead of having to post-proc the .h5 file (in serial)?<br>
><br>
> 1) Maintenance: Changing the Python is much easier than changing the C you would add to generate it<br>
><br>
> 2) Performance: On big parallel system, writing files is expensive so I wanted to minimize what I had to do.<br>
><br>
> 3) Robustness: Moving 1 file around is much easier than remembering 2. I just always regenerate the xdmf when needed.<br>
><br>
> And what about big 3D simulations? PETSc always serialize the output of the distributed dmplex? Is there a way to output one .h5 per mesh partition?<br>
><br>
> Given the way I/O is structured on big machines, we believe the multiple file route is a huge mistake. Also, all our measurements<br>
> say that sending some data on the network is not noticeable given the disk access costs.<br>
><br>
> I have slightly different things here. We tried the serial output, it looks really slow for large-scale problems, and the first processor often runs out of memory because of gathering all data from other processor cores.<br>
<br>
</span>  Where in PETSc is this?  What type of viewer? Is there an example that reproduces the problem? Even when we do not use MPI IO in PETSc we attempt to not "put the entire object on the first process" so memory should not be an issue. For example VecVew() should memory scale both with or without MPI IO<br></blockquote><div><br></div><div>We manually gather all data to the first processor core, and write it as a single vtk file. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
> The parallel IO runs smoothly and much faster than I excepted. We have done experiments with ten thousands  of cores for a problem with 1 billion of unknowns.<br>
<br>
</span>    Is this your own canned IO or something in PETSc?<br></blockquote><div><br></div><div>We implement the writer based on the ISView and VecView with HDF5 viewer  in PETSc to output all data as a single HDF. ISView and VecView do the magic job for me. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> I did not see any concern so far.<br>
<br>
</span>   Ten thousand files is possibly manageable but I question 2 million.<br></blockquote><div><br></div><div>Just one single HDF5 file. </div><div><br></div><div>Fande,</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br>
><br>
><br>
> Fande,<br>
><br>
><br>
>   Thanks,<br>
><br>
>     Matt<br>
><br>
> Best regards,<br>
> Adriano.<br>
><br>
><br>
> 2017-09-14 12:00 GMT-03:00 Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>>:<br>
> On Thu, Sep 14, 2017 at 10:30 AM, Adriano Côrtes <<a href="mailto:adrimacortes@gmail.com">adrimacortes@gmail.com</a>> wrote:<br>
> Dear all,<br>
><br>
> I am running the SNES ex12  and I'm passing the options -dm_view hdf5:sol.h5 -vec_view hdf5:sol.h5::append to generate an output file. The .h5 file is generated, but I'm not being able to load it in Paraview (5.4.0-64bits). Paraview recognizes the file and offers severel options to read it, here is the complete list<br>
><br>
> Chombo Files<br>
> GTC Files<br>
> M3DC1 Files<br>
> Multilevel 3D Plasma Files<br>
> PFLOTRAN Files<br>
> Pixie Files<br>
> Tetrad Files<br>
> UNIC Files<br>
> VizSchema Files<br>
><br>
> The problem is none of the options above work :(<br>
> I'm using the configure option '-download-hdf5' and it installs hdf5 version 1.8.18<br>
> Any hint of how to fix it and have the visualization working?<br>
><br>
> Yes, Paraview does not directly read HDF5. It needs you to tell it what the data in the HDF5 file means. You do<br>
> this by creating a *.xdmf file, which is XML. We provide a tool<br>
><br>
>   $PETSC_DIR/bin/petsc_gen_xdmf.<wbr>py <HDF5 file><br>
><br>
> which should automatically produce this file for you. Let us know if it does not work.<br>
><br>
>   Thanks,<br>
><br>
>     Matt<br>
><br>
><br>
> Best regards,<br>
> Adriano.<br>
><br>
> --<br>
> Adriano Côrtes<br>
> ==============================<wbr>===================<br>
> Campus Duque de Caxias and<br>
> High-performance Computing Center (NACAD/COPPE)<br>
> Federal University of Rio de Janeiro (UFRJ)<br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
><br>
</div></div>> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.caam.rice.edu_-7Emk51_&d=DwIFaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=YTLjMkjfS0tYLZ3RxmJFoe8BT56h48axFCzaadZwBXA&s=iLsaHQugaY4gj4DKE9gq8XdBt7q3ejdpDRfJ8RFerE0&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=http-3A__www.<wbr>caam.rice.edu_-7Emk51_&d=<wbr>DwIFaQ&c=<wbr>54IZrppPQZKX9mLzcGdPfFD1hxrcB_<wbr>_aEkJFOKJFd00&r=DUUt3SRGI0_<wbr>JgtNaS3udV68GRkgV4ts7XKfj2opmi<wbr>CY&m=<wbr>YTLjMkjfS0tYLZ3RxmJFoe8BT56h48<wbr>axFCzaadZwBXA&s=<wbr>iLsaHQugaY4gj4DKE9gq8XdBt7q3ej<wbr>dpDRfJ8RFerE0&e=</a><br>
<span class="">><br>
><br>
><br>
> --<br>
> Adriano Côrtes<br>
> ==============================<wbr>===================<br>
> Campus Duque de Caxias and<br>
> High-performance Computing Center (NACAD/COPPE)<br>
> Federal University of Rio de Janeiro (UFRJ)<br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
> -- Norbert Wiener<br>
><br>
</span>> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.caam.rice.edu_-7Emk51_&d=DwIFaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=YTLjMkjfS0tYLZ3RxmJFoe8BT56h48axFCzaadZwBXA&s=iLsaHQugaY4gj4DKE9gq8XdBt7q3ejdpDRfJ8RFerE0&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=http-3A__www.<wbr>caam.rice.edu_-7Emk51_&d=<wbr>DwIFaQ&c=<wbr>54IZrppPQZKX9mLzcGdPfFD1hxrcB_<wbr>_aEkJFOKJFd00&r=DUUt3SRGI0_<wbr>JgtNaS3udV68GRkgV4ts7XKfj2opmi<wbr>CY&m=<wbr>YTLjMkjfS0tYLZ3RxmJFoe8BT56h48<wbr>axFCzaadZwBXA&s=<wbr>iLsaHQugaY4gj4DKE9gq8XdBt7q3ej<wbr>dpDRfJ8RFerE0&e=</a><br>
><br>
<br>
</blockquote></div><br></div></div>