Based on your description, it sounds like there might be something else wrong
in your code (George's point was that you need to call all collectives with the
same signature in all processes on the communicator, but just lipping the
output buffer from intensity to intensity2 -- or vice versa -- shouldn't affect
that).
Perhaps try with a memory-checking debugger...?
On Mar 4, 2013, at 5:16 PM, Andrew J Gomes <a-go...@northwestern.edu> wrote:
> I have the following code which does not give the expected result:
> if (mpi_rank!=0)
> { MPI_Reduce(&intensity,&intensity ,1,MPI_DOUBLE,MPI_SUM,0,MPI_COMM_WORLD);
>
> MPI_Reduce(&intensity2,&intensity2 ,1,MPI_DOUBLE,MPI_SUM,0,MPI_COMM_WORLD); }
> else
> {
> MPI_Reduce(MPI_IN_PLACE,&intensity2 ,1,MPI_DOUBLE,MPI_SUM,0,MPI_COMM_WORLD);
> MPI_Reduce(MPI_IN_PLACE,&intensity ,1,MPI_DOUBLE,MPI_SUM,0,MPI_COMM_WORLD);}
>
> However if I change the the order of the else block (reduction of intensity
> variable before intensity2 variable) to :
> else
> {
> MPI_Reduce(MPI_IN_PLACE,&intensity ,1,MPI_DOUBLE,MPI_SUM,0,MPI_COMM_WORLD);
> MPI_Reduce(MPI_IN_PLACE,&intensity2 ,1,MPI_DOUBLE,MPI_SUM,0,MPI_COMM_WORLD);}
>
> I get the expected result. This surprised me. Is there a reason the order of
> the else block should match the order of the if block? Is there a more robust
> way of implementing this type of code. Thank you
>
> Andrew
> _______________________________________________
> users mailing list
> us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
