Rajeev
> From: John M May <johnmay@coral.llnl.gov>
> Date: Mon, 24 Jun 1996 13:24:31 -0700 (PDT)
> Cc: johnmay@coral.llnl.gov, mpi-io@mcs.anl.gov,
> ptools-meeting-1996@cs.orst.edu
> X-Mailer: ELM [version 2.4 PL25]
> Mime-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Content-Length: 2228
>
> > All this sounds fine. My only concern is the MPI_COMM_WORLD case,
> > where the implementation must figure out the sets of processes
> > printing out identical data and display it accordingly.
> > I think that, in the general case, finding these subsets is quite a
> > task, best left to a good quality debugger.
> >
> > A simpler approach is to require that in the MPI_COMM_WORLD case,
> > all processes must output identical data, and only one copy gets
> > printed. If they don't output identical data, the implementation flags
> > an error. To find out the erroneous process(es), the user could print
> > with MPI_COMM_SELF in the next run.
>
> Rajeev's alternative to having MPI_Print find common output subsets
> output is reasonable, but in case it turns out that people really
> want MPI_Print to do this job, I'd like to point out that while
> an algorithm to do this may be slow, it's not unreasonably hard.
>
> One solution would be to simulate an MPI reduction (we can't
> use MPI_Reduce directly because the strings might be different
> lengths). Basically, we could use sends and receives to set up
> a reduction tree. At each level, a node would receive a list of
> unique output strings along with the sets of nodes that had produced
> each string. The node would compare each item in this list with
> each item in the list that it had kept from the previous round.
> For strings that matched, the corresponding sets of nodes would
> be merged. Depending on its position in the tree, the node would
> either forward this merged list one level down the tree or keep
> the list and wait for the next list to come in. At the root, the
> final set of comparisons would produce a list of unique strings and
> the nodes that had produced each one. I figure this algorithm
> requires O(n*n) string comparisons (n=number of nodes) in the
> worst case when all the strings are different. Not cheap, but
> not out of the question either.
>
> The reduction tree might look like this:
>
> Node 0 1 2 3 4 5 6 7
> String a b c d e f g h
>
> a<>b c<>d e<>f g<>h
>
> a c e g
> b<>d f<>h
>
> a e
> b f
> c g
> d<>h
>
> <> means compare each string in the left column with each
> string in the right column. This tree shows the worst
> case, with all the strings being different.
>
> John
>
>