Hy Jeff, thanks for replying.

Does it mean that you don't have it working properly yet? I read the thread at the devel list where you addressed the problem and a possible solution, but I was not able to find a conclusion about the problem.

I'm in trouble without this function. Probably I'll need to redesign all my implementation to achieve what I need.


On Fri, Jan 27, 2012 at 2:35 PM, Jeff Squyres <jsquyres@cisco.com> wrote:
Unfortunately, I think that this is a known problem with INTERCOMM_MERGE and COMM_SPAWN parents and children:

   https://svn.open-mpi.org/trac/ompi/ticket/2904


On Jan 26, 2012, at 12:11 PM, Rodrigo Oliveira wrote:

> Hi there, I tried to understand the behavior Thatyene said and I think is a bug in open mpi implementation.
>
> I do not know what exactly is happening because I am not an expert in ompi code, but I could see that when one process define its color as MPI_UNDEFINED, one of the processes on the inter-communicator blocks in the call to the function bellow:
>
> /* Step 3: set up the communicator                           */
>     /* --------------------------------------------------------- */
>     /* Create the communicator finally */
>     rc = ompi_comm_set ( &newcomp,           /* new comm */
>                          comm,               /* old comm */
>                          my_size,            /* local_size */
>                          lranks,             /* local_ranks */
>                          my_rsize,           /* remote_size */
>                          rranks,             /* remote_ranks */
>                          NULL,               /* attrs */
>                          comm->error_handler,/* error handler */
>                          (pass_on_topo)?
>                          (mca_base_component_t *)comm->c_topo_component:
>                          NULL,               /* topo component */
>                          NULL,               /* local group */
>                          NULL                /* remote group */
>     );
>
> This function is called inside ompi_comm_split, in the file ompi/communicator/comm.c
>
> Is there a solution for this problem in some revision? I insist in this problem because I need to use this function for a similar purpose.
>
> Any idea?
>
>
> On Wed, Jan 25, 2012 at 4:50 PM, Thatyene Louise Alves de Souza Ramos <thatyene@gmail.com> wrote:
> It seems the split is blocking when must return MPI_COMM_NULL, in the case I have one process with a color that does not exist in the other group or with the color = MPI_UNDEFINED.
>
> On Wed, Jan 25, 2012 at 4:28 PM, Rodrigo Oliveira <rsilva.oliveira@gmail.com> wrote:
> Hi Thatyene,
>
> I took a look in your code and it seems to be logically correct. Maybe there is some problem when you call the split function having one client process with color = MPI_UNDEFINED. I understood you are trying to isolate one of the client process to do something applicable only to it, am I wrong? According to open mpi documentation, this function can be used to do that, but it is not working. Anyone have any idea about what can be?
>
> Best regards
>
> Rodrigo Oliveira
>
>
> _______________________________________________
> users mailing list
> users@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users
>
> _______________________________________________
> users mailing list
> users@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/users


--
Jeff Squyres
jsquyres@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/


_______________________________________________
users mailing list
users@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users