More accurately, the PetscViewerASCII subcomm viewer mechanism appears broken.<div>I'm ready to push a fix, but since this is a heavily used and sensitive part of the code </div><div>I wanted to make sure I'm not missing anything this close to a release.</div>

<div>The problem seems to start here: <a href="http://petsc.cs.iit.edu/petsc/petsc-dev/file/dc597ff7b29f/src/sys/viewer/impls/ascii/filev.c#l827">http://petsc.cs.iit.edu/petsc/petsc-dev/file/dc597ff7b29f/src/sys/viewer/impls/ascii/filev.c#l827</a></div>

<div><div>In particular, </div><div><div class="parity1" style="background-color:rgb(246,246,240);font-size:12px;font-family:monospace"><pre style="margin-top:0px;margin-bottom:0px">   <a class="linenr" href="http://petsc.cs.iit.edu/petsc/petsc-dev/file/dc597ff7b29f/src/sys/viewer/impls/ascii/filev.c#l854" id="l854" style="color:rgb(136,0,0);text-decoration:none">854</a>   (*outviewer)->ops->destroy = PetscViewerDestroy_ASCII_Singleton;
</pre></div><div class="parity0" style="font-size:12px;font-family:monospace"><pre style="margin-top:0px;margin-bottom:0px"><a class="linenr" href="http://petsc.cs.iit.edu/petsc/petsc-dev/file/dc597ff7b29f/src/sys/viewer/impls/ascii/filev.c#l855" id="l855" style="color:rgb(136,0,0);text-decoration:none">   855</a>   /* following might not be correct??? */
</pre></div><div class="parity1" style="background-color:rgb(246,246,240);font-size:12px;font-family:monospace"><pre style="margin-top:0px;margin-bottom:0px"><a class="linenr" href="http://petsc.cs.iit.edu/petsc/petsc-dev/file/dc597ff7b29f/src/sys/viewer/impls/ascii/filev.c#l856" id="l856" style="color:rgb(136,0,0);text-decoration:none">   856</a>   if (rank) {
</pre></div><div class="parity0" style="font-size:12px;font-family:monospace"><pre style="margin-top:0px;margin-bottom:0px"><a class="linenr" href="http://petsc.cs.iit.edu/petsc/petsc-dev/file/dc597ff7b29f/src/sys/viewer/impls/ascii/filev.c#l857" id="l857" style="color:rgb(136,0,0);text-decoration:none">   857</a>     (*outviewer)->ops->flush = 0;
</pre></div><div class="parity1" style="background-color:rgb(246,246,240);font-size:12px;font-family:monospace"><pre style="margin-top:0px;margin-bottom:0px"><a class="linenr" href="http://petsc.cs.iit.edu/petsc/petsc-dev/file/dc597ff7b29f/src/sys/viewer/impls/ascii/filev.c#l858" id="l858" style="color:rgb(136,0,0);text-decoration:none">   858</a>   } else {
</pre></div><div class="parity0" style="font-size:12px;font-family:monospace"><pre style="margin-top:0px;margin-bottom:0px"><a class="linenr" href="http://petsc.cs.iit.edu/petsc/petsc-dev/file/dc597ff7b29f/src/sys/viewer/impls/ascii/filev.c#l859" id="l859" style="color:rgb(136,0,0);text-decoration:none">   859</a>     (*outviewer)->ops->flush = PetscViewerFlush_ASCII_Singleton_0;
</pre></div><div class="parity1" style="background-color:rgb(237,236,230);font-size:12px;font-family:monospace"><pre style="margin-top:0px;margin-bottom:0px"><a class="linenr" href="http://petsc.cs.iit.edu/petsc/petsc-dev/file/dc597ff7b29f/src/sys/viewer/impls/ascii/filev.c#l860" id="l860" style="color:rgb(136,0,0);text-decoration:none">   860</a>   }</pre>

</div></div><div>I totally agree with the comment in the above snippet.  In particular, if rank 0 of the original</div><div>comm isn't in the subcomm, no flushing will occur.  And if rank 0 makes it into the subcomm,</div>

<div>it will be the only proc writing to the file.  I actually experience both of these scenarios</div><div>when viewing GASM subdomain ISs, which can live on arbitrary subcomms (including </div><div>subcomm==comm).</div>

<div><br></div><div>The fix here seems to be relatively simple -- just leave the original function pointer in the vtable.</div><div>There are other things to navigate around -- for example, we can't just copy the fd, since only the </div>

<div>original rank 0 has it, and we have to be careful about reopening the file when subcomm==comm, </div><div>but those are easily taken care of.  </div><div><br></div><div>I've run some tests, and it seems to work okay.  I'm sure it will be caught in the nighlies, if this commit</div>

<div>breaks something.  Otherwise, as currently implemented PetscViewerGetSubcomm appears to be useless </div><div>(unless subcomm=PETSC_COMM_SELF; by the way, why don't we just use </div><div>PetscViewerGetSubcomm(view, PETSC_COMM_SELF, &sviewer) instead of the odd-sounding </div>

<div>PetscViewerGetSingleton(view, &sviewer)?)</div><div><br></div><div>Does anybody object to my pushing a fix to this?</div><div><br></div><div>Dmitry.</div><div><br></div><div><br></div><div><br></div></div>