<div dir="ltr">On Fri, May 24, 2013 at 6:52 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The output from '-pc_type gamg -ksp_view' in parallel is all jumbled up<br>
because every process prints on its own singleton (due to<br>
!same_local_solves), but the singletons aren't synchronized.<br>
<br>
I think we should:<br>
<br>
1. Make BJacobi only print from rank 0.  We can have a verbose output<br>
   flag to print the O(P) data in case of different solvers in different<br>
   subdomains, but I think it can't be on by default.  Especially in the<br>
   case of GAMG, there isn't anything interesting from the others<br>
   because they have zero degrees of freedom.  I would like to apply<br>
   this change to 'maint', the other points below would be developed on<br>
   'master'.<br></blockquote><div><br></div><div style>Definitely.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Buffer and then synchronize on PetscViewerRestoreSingleton.  This<br>
   requires adding PetscViewerASCIISynchronizedVPrintf so that normal<br>
   PetscViewerASCIIPrintf on the singleton viewer will write to a<br>
   string.<br></blockquote><div><br></div><div style>I would rather replace the writes with SynchronizedPrintf()s. Why change the</div><div style>semantics?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

3. PetscViewerASCIISynchronizedPrintf is currently messy because it<br>
   writes eagerly on rank 0.  Is that behavior important?  We need some<br>
   way to make rank 0 of the singleton still write to a buffer and I'd<br>
   rather not convolute the logic further.  Is it okay if I make<br>
   synchronized writes always go to a buffer (even from rank 0)?  (This<br>
   means that in case of a crash part way through a synchronized write,<br>
   we'll have less output.  I don't see any other disadvantages.)<br></blockquote><div><br></div><div style>This is alright with me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

4. We have two incompatible (private) definitions of the _PrintfQueue<br>
   structure.  I would like to consolidate by just using a<br>
   PetscSegBuffer in both places.<br></blockquote><div><br></div><div style>Fine.</div><div style><br></div><div style>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

src/sys/fileio/mprint.h:<br>
<br>
struct _PrintfQueue {<br>
  char        *string;<br>
  int         size;<br>
  PrintfQueue next;<br>
};<br>
<br>
src/sys/classes/viewer/impls/vu/petscvu.c:<br>
<br>
struct _PrintfQueue {<br>
  char        string[QUEUESTRINGSIZE];<br>
  PrintfQueue next;<br>
};<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <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
</div></div>