MPI_IRECV(3)

📦
version 5.0.11 · 17 versions
, in arch rolling

💌 MPI_IRECV(3) — Open MPI, but make it bestie ✨

MPI_Irecv — starts a standard-mode, nonblocking receive. That's literally the name line, and we're already slaying. 💅

✨ SYNTAX ✨

C Syntax

Okay so here's the C glow-up, bestie — seven arguments, one dream:

#include <mpi.h>

int MPI_Irecv(void *buf, int count, MPI_Datatype datatype,
        int source, int tag, MPI_Comm comm, MPI_Request *request)

Fortran Syntax

The Fortran version said "let me also be here," and honestly? Iconic.

USE MPI
! or the older form: INCLUDE 'mpif.h'
MPI_IRECV(BUF, COUNT, DATATYPE, SOURCE, TAG, COMM, REQUEST,
             IERROR)
     <type>  BUF(*)
     INTEGER COUNT, DATATYPE, SOURCE, TAG, COMM, REQUEST, IERROR

Fortran 2008 Syntax

And the Fortran 2008 syntax is giving modern main character energy 🦋:

USE mpi_f08
MPI_Irecv(buf, count, datatype, source, tag, comm, request, ierror)
     TYPE(*), DIMENSION(..), ASYNCHRONOUS :: buf
     INTEGER, INTENT(IN) :: count, source, tag
     TYPE(MPI_Datatype), INTENT(IN) :: datatype
     TYPE(MPI_Comm), INTENT(IN) :: comm
     TYPE(MPI_Request), INTENT(OUT) :: request
     INTEGER, OPTIONAL, INTENT(OUT) :: ierror

💖 INPUT PARAMETERS 💖

  • buf — initial address of receive buffer (choice). Like, where the receiving starts, periodt.
  • count — number of elements in receive buffer (integer). Count them, bestie.
  • datatype — datatype of each receive buffer element (handle). The whole what even is this data situation.
  • source — rank of source (integer). Who's sending it? This queen.
  • tag — message tag (integer). The little label on the message, iykyk.
  • comm — communicator (handle). The group chat where this is all happening.

🎀 OUTPUT PARAMETERS 🎀

  • request — communication request (handle). Keep this receipt, bestie.
  • ierror — Fortran only: error status (integer). Fortran said "I'll handle the error status, don't worry."

🌸 DESCRIPTION 🌸

Okay so nonblocking calls allocate a communication request object and associate it with the request handle — that's the request argument, bestie. You can use that request later to query the status of the communication or wait for its completion. Slay. 💅

A nonblocking receive call indicates that the system may start writing data into the receive buffer. 🚨 And listen: the receiver should not access any part of the receive buffer after a nonblocking receive operation is called, until the receive completes. Not a single byte. That's the vibe check. Don't ruin it.

A receive request can be determined to be completed by calling MPI_Wait, MPI_Waitany, MPI_Test, or MPI_Testany with request returned by this function. Like, those are your little completion checkers, and they ate. ✨

💀 ERRORS 💀

Almost all MPI routines return an error value; C routines as the return result of the function and Fortran routines in the last argument. So C said "I'll return it," and Fortran said "last argument, obviously."

Before the error value is returned, the current MPI error handler associated with the communication object (e.g., communicator, window, file) is called. If no communication object is associated with the MPI call, then the call is considered attached to MPI_COMM_SELF and will call the associated MPI error handler. When MPI_COMM_SELF is not initialized (i.e., before MPI_Init/MPI_Init_thread, after MPI_Finalize, or when using the Sessions Model exclusively) the error raises the initial error handler. The initial error handler can be changed by calling MPI_Comm_set_errhandler on MPI_COMM_SELF when using the World model, or the mpi_initial_errhandler CLI argument to mpiexec or info key to MPI_Comm_spawn/MPI_Comm_spawn_multiple. If no other appropriate error handler has been set, then the MPI_ERRORS_RETURN error handler is called for MPI I/O functions and the MPI_ERRORS_ABORT error handler is called for all other MPI functions. No cap, that's the whole chain.

Open MPI includes three predefined error handlers that can be used:

  • MPI_ERRORS_ARE_FATAL — causes the program to abort all connected MPI processes. Like, everybody. Gone. 💀
  • MPI_ERRORS_ABORT — an error handler that can be invoked on a communicator, window, file, or session. When called on a communicator, it acts as if MPI_Abort was called on that communicator. If called on a window or file, acts as if MPI_Abort was called on a communicator containing the group of processes in the corresponding window or file. If called on a session, aborts only the local process. Okay so it's dramatic but specific, and we respect that.
  • MPI_ERRORS_RETURN — returns an error code to the application. The chill one. The "here's your receipt" one.

MPI applications can also implement their own error handlers by calling:

  • MPI_Comm_create_errhandler then MPI_Comm_set_errhandler
  • MPI_File_create_errhandler then MPI_File_set_errhandler
  • MPI_Session_create_errhandler then MPI_Session_set_errhandler or at MPI_Session_init
  • MPI_Win_create_errhandler then MPI_Win_set_errhandler

Note that MPI does not guarantee that an MPI program can continue past an error. ⚠️ So if it goes wrong, it might just not continue. That's not a vibe, that's a warning.

See the MPI man page for a full list of MPI error codes.

See the Error Handling section of the MPI-3.1 standard for more information.

👀 SEE ALSO 👀

Go read these next, bestie — they're all connected:

  • MPI_Recv
  • MPI_Probe
  • MPI_Test
  • MPI_Testany
  • MPI_Wait
  • MPI_Waitany

2003-2026, The Open MPI Community. Like, they've been doing this since 2003 and still showing up. Respect. 🫶

And that's the page, bestie — brought to you by Open MPI, with the manpage date Sep 11, 2026. Catch you in the next recv, and remember: don't touch the buffer until it completes. 💖✨🎀

📦 where this page comes from