[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