Newsgroups: comp.parallel.mpi
From: Junglas@tu-harburg.d400.de (Peter Junglas)
Reply-To: Junglas@tu-harburg.de (Peter Junglas)
Subject: unexpected behaviour of MPI_Waitany with target MPI_PROC_NULL
Organization: Techn. Uni. Hamburg-Harburg, Germany
Date: 8 Nov 1994 09:02:49 GMT
Message-ID: <39nerp$lqk@rztsun.tu-harburg.de>


  Hi, MPI experts.

  I'm trying to use nonblocking operations and MPI_Waitany to overlap
  communication and computation, together with cartesian topology functions.
  At the boundaries, some of the Irecv's communicate with MPI_PROC_NULL
  (coming from MPI_Cart_shift). The problem now is the way, how MPI_Waitany
  handles such requests. To be a bit more concrete, the structure in the 1d
  case is the following:

    start receive of row   0 from  lower neighbour (request 0)
    start receive of row N+1 from  upper neighbour (request 1)
    start sends to upper and lower neighbours

    compute inner points (i=2 .. N-1)

    do twice
      MPI_Waitany( .. &id ..)
      if       id = 0  -> compute row 1
      else if  id = 1  -> compute row N

    finish sends

  
  For the inner processors everything works fine, but what about the boundary
  points? Since I find the standard document a bit confusing at this point,
  first my opinion about what should happen:

  All receive-requests, which result from communication with MPI_PROC_NULL,
  should complete at once. Then MPI_Waitany would arbitrarily choose first
  one, then the other request (cf. MPI-doc. p. 43, l.40-43).  With such a
  behaviour one wouldn't need special code for the boundaries, even the case
  of only one processor would work. As far as I understand, this is the reason
  for having a dummy target like MPI_PROC_NULL.
    
  What actually happens - at least in the ANL/MSU implementation of MPI - is
  the following: if both request handles come from communication with
  MPI_PROC_NULL (as in the case of only one processor), MPI_Waitany returns
  MPI_UNDEFINED in the index variable. The same happens, if only one such
  request handle exists and the other one has finished in the first iteration
  (i.e. it is set to MPI_REQUEST_NULL). Of course this means that special code
  has to be supplied, in order to test for MPI_UNDEFINED and to handle the
  boundaries correctly .

  This behaviour can be understood, if one interprets such special request
  handles as (null or) inactive (cf. p.43, l.46-48). But I'm not sure whether
  this is consistent with the standard document: In p. 39, l.13-17, persistent
  handles without ongoing communication are called "inactive", but this term
  is not defined at all for non-persistent handles. Neither would I conclude
  from ch. 3.11 (Null Processes) that corresponding handles should be
  "inactive" ones.

  So I'd like to know the meaning of the MPI experts: 

  1. Does the standard document imply, allow or forbid the interpretation that
  request handles connected with communication to MPI_PROC_NULL are
  "inactive", with the described consequences for MPI_Waitany?

  2. If this interpretation is allowed (or even implied), should one change
  the standard document in order to simplify the handling of boundary points,
  or should one write special code for them? (Or is there another possibility,
  which I overlooked?)


    Greetings from Hamburg 
       Peter

--
Peter Junglas                           Tel.:  040/7718-3193
TU Hamburg-Harburg,                     Fax.:  040/7718-2803
  Rechenzentrum                         email: Junglas@tu-harburg.d400.de
Denickestr. 17    
21071 Hamburg

