<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Feb 28, 2018 at 11:59 AM, Danyang Su <span dir="ltr"><<a href="mailto:danyang.su@gmail.com" target="_blank">danyang.su@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 text="#000000" bgcolor="#FFFFFF">
<p>Hi Barry and Matt,</p>
<p>Thanks for your quick response. Considering the output
performance, as well as the long-term plan of PETSc development,
which format would you suggest? I personally prefer the data
format that can be post-processed by Paraview as our sequential
code (written without PETSc) is also using Paraview compatible
data format. XDMF sounds promising as suggested by Matt.</p></div></blockquote><div>I definitely suggest the HDF5+XDMF route.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><p>Thanks,</p>
<p>Danyang<br>
</p>
<div class="m_-6246290035637900612moz-cite-prefix">On 18-02-28 08:17 AM, Smith, Barry F.
wrote:<br>
</div>
<blockquote type="cite">
<div class="m_-6246290035637900612BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="m_-6246290035637900612PlainText"><br>
It turns out the fix is really easy. Here is a patch.<br>
<br>
Apply it with <br>
<br>
patch -p1 < barry-vtk.patch<br>
<br>
then do <br>
<br>
make gnumake<br>
<br>
all in $PETSC_DIR<br>
<br>
</div>
</span></font></div>
<div class="m_-6246290035637900612BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="m_-6246290035637900612PlainText"><br>
<br>
> On Feb 28, 2018, at 9:07 AM, Danyang Su
<a class="m_-6246290035637900612moz-txt-link-rfc2396E" href="mailto:danyang.su@gmail.com" target="_blank"><danyang.su@gmail.com></a> wrote:<br>
> <br>
> Hi Matt，<br>
> <br>
> Thanks for your suggestion and I will use xmf
instead. <br>
> <br>
> Regards,<br>
> <br>
> Danyang<br>
> <br>
> On February 28, 2018 3:58:08 AM PST, Matthew Knepley
<a class="m_-6246290035637900612moz-txt-link-rfc2396E" href="mailto:knepley@gmail.com" target="_blank"><knepley@gmail.com></a> wrote:<br>
> On Wed, Feb 28, 2018 at 12:39 AM, Smith, Barry F.
<a class="m_-6246290035637900612moz-txt-link-rfc2396E" href="mailto:bsmith@mcs.anl.gov" target="_blank"><bsmith@mcs.anl.gov></a> wrote:<br>
> <br>
> Matt,<br>
> <br>
> I have confirmed this is reproducible and a bug.
The problem arises because<br>
> <br>
> frame #0: 0x000000010140625a
libpetsc.3.8.dylib`<wbr>PetscViewerVTKAddField_VTK(<wbr>viewer=0x00007fe66760c750,
dm=0x00007fe668810820,
PetscViewerVTKWriteFunction=(<wbr>libpetsc.3.8.dylib`<wbr>DMPlexVTKWriteAll
at plexvtk.c:633), fieldtype=PETSC_VTK_POINT_<wbr>FIELD,
vec=0x00007fe66880ee20) at vtkv.c:140<br>
> frame #1: 0x0000000101404e6e
libpetsc.3.8.dylib`<wbr>PetscViewerVTKAddField(viewer=<wbr>0x00007fe66760c750,
dm=0x00007fe668810820,
PetscViewerVTKWriteFunction=(<wbr>libpetsc.3.8.dylib`<wbr>DMPlexVTKWriteAll
at plexvtk.c:633), fieldtype=PETSC_VTK_POINT_<wbr>FIELD,
vec=0x00007fe66880ee20) at vtkv.c:46<br>
> frame #2: 0x0000000101e0b7c3
libpetsc.3.8.dylib`VecView_<wbr>Plex_Local(v=<wbr>0x00007fe66880ee20,
viewer=0x00007fe66760c750) at plex.c:301<br>
> frame #3: 0x0000000101e0ead7
libpetsc.3.8.dylib`VecView_<wbr>Plex(v=0x00007fe66880e820,
viewer=0x00007fe66760c750) at plex.c:348<br>
> <br>
> keeps a linked list of vectors that are to be viewed
and the vectors are the same Vec because they are obtained
with DMGetLocalVector().<br>
> <br>
> The safest fix is to have
PetscViewerVTKAddField_VTK() do a VecDuplicate() on the
vector passed in and store that in the linked list instead
of just storing a pointer to the passed in vector (which
might and can be overwritten before all the linked vectors
are actually stored).<br>
> <br>
> Danyang,<br>
> <br>
> Barry is right, and the bug can be fixed the way he
says. However, this points out why VTK is bad format. I
think a better choice is<br>
> to use HDF5 and XDMF. For example, in my code now I
always use<br>
> <br>
> DMVIewFromOptions(dm, NULL, "-dm_view");<br>
> <br>
> and then later (perhaps several times)<br>
> <br>
> VecViewFromOptions(u, NULL, "-u_vec_view")<br>
> VecViewFromOptions(v, NULL, "-v_vec_view")<br>
> <br>
> and then on the command line<br>
> <br>
> -dm_view hdf5:test.h5 -u_vec_view
hdf5:test.h5::append -v_vec_view hdf5:test.h5::append<br>
> <br>
> which produces a file<br>
> <br>
> test.h5<br>
> <br>
> Then I run<br>
> <br>
> $PETSC_DIR/bin/petsc_gen_xdmf.<wbr>py test.h5<br>
> <br>
> which produces another file<br>
> <br>
> test.xmf<br>
> <br>
> This can be loaded by Paraview for visualization.<br>
> <br>
> Thanks,<br>
> <br>
> Matt<br>
> <br>
> <br>
> <br>
> Barry<br>
> <br>
> <br>
> <br>
> > On Feb 27, 2018, at 10:44 PM, Danyang Su
<a class="m_-6246290035637900612moz-txt-link-rfc2396E" href="mailto:danyang.su@gmail.com" target="_blank"><danyang.su@gmail.com></a> wrote:<br>
> ><br>
> > Hi All,<br>
> ><br>
> > How to set different object names when using
multiple VecView? I try to use PetscObjectSetName with
multiple output, but the object name is overwritten by the
last one.<br>
> ><br>
> > As shown below, as well as the enclosed files as
example, the vector name in sol.vtk is vec_v for both
vector u and v.<br>
> ><br>
> > call PetscViewerCreate(PETSC_COMM_<wbr>WORLD,
viewer, ierr);CHKERRA(ierr)<br>
> > call PetscViewerSetType(viewer,
PETSCVIEWERVTK, ierr);CHKERRA(ierr)<br>
> > call PetscViewerPushFormat(viewer,
PETSC_VIEWER_ASCII_VTK, ierr);CHKERRA(ierr)<br>
> > call PetscViewerFileSetName(viewer,
'sol.vtk', ierr);CHKERRA(ierr)<br>
> ><br>
> > call PetscObjectSetName(u, 'vec_u',
ierr);CHKERRA(ierr)<br>
> > call VecView(u, viewer, ierr);CHKERRA(ierr)<br>
> ><br>
> > call PetscObjectSetName(v, 'vec_v',
ierr);CHKERRA(ierr)<br>
> > call VecView(v, viewer, ierr);CHKERRA(ierr)<br>
> ><br>
> > call PetscViewerDestroy(viewer,
ierr);CHKERRA(ierr)<br>
> ><br>
> > call DMRestoreGlobalVector(dm, u,
ierr);CHKERRA(ierr)<br>
> > call DMRestoreGlobalVector(dm, v,
ierr);CHKERRA(ierr)<br>
> ><br>
> > Thanks,<br>
> ><br>
> > Danyang<br>
> ><br>
> >
<ex1f90.F90><makefile.txt><<wbr>sol.vtk><br>
> <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>
> <a href="https://www.cse.buffalo.edu/%7Eknepley/" target="_blank">https://www.cse.buffalo.edu/~<wbr>knepley/</a><br>
> <br>
> -- <br>
> Sent from my Android device with K-9 Mail. Please
excuse my brevity.<br>
<br>
</div>
</span></font></div>
</blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>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</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div>
</div></div>