[petsc-dev] synchronized printing, singletons, and jumbled GAMG/BJacobi output

Jed Brown jedbrown at mcs.anl.gov
Fri May 24 18:52:39 CDT 2013


The output from '-pc_type gamg -ksp_view' in parallel is all jumbled up
because every process prints on its own singleton (due to
!same_local_solves), but the singletons aren't synchronized.

I think we should:

1. Make BJacobi only print from rank 0.  We can have a verbose output
   flag to print the O(P) data in case of different solvers in different
   subdomains, but I think it can't be on by default.  Especially in the
   case of GAMG, there isn't anything interesting from the others
   because they have zero degrees of freedom.  I would like to apply
   this change to 'maint', the other points below would be developed on
   'master'.

2. Buffer and then synchronize on PetscViewerRestoreSingleton.  This
   requires adding PetscViewerASCIISynchronizedVPrintf so that normal
   PetscViewerASCIIPrintf on the singleton viewer will write to a
   string.

3. PetscViewerASCIISynchronizedPrintf is currently messy because it
   writes eagerly on rank 0.  Is that behavior important?  We need some
   way to make rank 0 of the singleton still write to a buffer and I'd
   rather not convolute the logic further.  Is it okay if I make
   synchronized writes always go to a buffer (even from rank 0)?  (This
   means that in case of a crash part way through a synchronized write,
   we'll have less output.  I don't see any other disadvantages.)

4. We have two incompatible (private) definitions of the _PrintfQueue
   structure.  I would like to consolidate by just using a
   PetscSegBuffer in both places.

src/sys/fileio/mprint.h:

struct _PrintfQueue {
  char        *string;
  int         size;
  PrintfQueue next;
};

src/sys/classes/viewer/impls/vu/petscvu.c:

struct _PrintfQueue {
  char        string[QUEUESTRINGSIZE];
  PrintfQueue next;
};



More information about the petsc-dev mailing list