<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body 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>
    <p>Thanks,</p>
    <p>Danyang<br>
    </p>
    <div class="moz-cite-prefix">On 18-02-28 08:17 AM, Smith, Barry F.
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:37E456DA-DC44-4BFE-BAA7-CD74FBA4E377@mcs.anl.gov">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div class="BodyFragment"><font size="2"><span
            style="font-size:11pt;">
            <div class="PlainText"><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="BodyFragment"><font size="2"><span
            style="font-size:11pt;">
            <div class="PlainText"><br>
              <br>
              > On Feb 28, 2018, at 9:07 AM, Danyang Su
              <a class="moz-txt-link-rfc2396E" href="mailto:danyang.su@gmail.com"><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="moz-txt-link-rfc2396E" href="mailto:knepley@gmail.com"><knepley@gmail.com></a> wrote:<br>
              > On Wed, Feb 28, 2018 at 12:39 AM, Smith, Barry F.
              <a class="moz-txt-link-rfc2396E" href="mailto:bsmith@mcs.anl.gov"><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`PetscViewerVTKAddField_VTK(viewer=0x00007fe66760c750,
              dm=0x00007fe668810820,
              PetscViewerVTKWriteFunction=(libpetsc.3.8.dylib`DMPlexVTKWriteAll
              at plexvtk.c:633), fieldtype=PETSC_VTK_POINT_FIELD,
              vec=0x00007fe66880ee20) at vtkv.c:140<br>
              >     frame #1: 0x0000000101404e6e
              libpetsc.3.8.dylib`PetscViewerVTKAddField(viewer=0x00007fe66760c750,
              dm=0x00007fe668810820,
              PetscViewerVTKWriteFunction=(libpetsc.3.8.dylib`DMPlexVTKWriteAll
              at plexvtk.c:633), fieldtype=PETSC_VTK_POINT_FIELD,
              vec=0x00007fe66880ee20) at vtkv.c:46<br>
              >     frame #2: 0x0000000101e0b7c3
              libpetsc.3.8.dylib`VecView_Plex_Local(v=0x00007fe66880ee20,
              viewer=0x00007fe66760c750) at plex.c:301<br>
              >     frame #3: 0x0000000101e0ead7
              libpetsc.3.8.dylib`VecView_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.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="moz-txt-link-rfc2396E" href="mailto:danyang.su@gmail.com"><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_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><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/"
                moz-do-not-send="true">https://www.cse.buffalo.edu/~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>
  </body>
</html>