MPI_COMM_FREE(3)

πŸŽ€ MPI_COMM_FREE β‹†ο½‘Β°βœ© (from the Open MPI manual, section 3) πŸŽ€

okay bestie, pull up a chair and a lil snack because today's topic is MPI_Comm_free β€” Mark a communicator object for deallocation. Yes, this is the Open MPI version, and yes, it's lowkey iconic. Let's get into it. πŸ’–


✨ SYNTAX ✨

πŸ¦‹ C Syntax

#include <mpi.h>

int MPI_Comm_free(MPI_Comm *comm)

πŸ¦‹ Fortran Syntax

USE MPI
! or the older form: INCLUDE 'mpif.h'
MPI_COMM_FREE(COMM, IERROR)
     INTEGER COMM, IERROR

πŸ¦‹ Fortran 2008 Syntax

USE mpi_f08
MPI_Comm_free(comm, ierror)
     TYPE(MPI_Comm), INTENT(INOUT) :: comm
     INTEGER, OPTIONAL, INTENT(OUT) :: ierror

🌸 INPUT PARAMETER 🌸

  • comm β€” the communicator you're yeeting into the void, aka the communicator to be destroyed. It's a handle, bestie. ✨

🫢 OUTPUT PARAMETER 🫢

  • ierror β€” Fortran girlies only: this is the error status, and it's an integer. πŸ’…

πŸ‘‘ DESCRIPTION πŸ‘‘

So here's the tea. This operation marks the communicator object for deallocation. The handle itself gets set to MPI_COMM_NULL β€” no cap. πŸ«₯

Any pending operations that use this communicator? They complete normally, because we're not messy like that. The object is actually deallocated only if there are no other active references to it. So like… it enters its ghost era for a bit until everyone's done with it. πŸ’€

This call applies to intracommunicators and intercommunicators β€” equal opportunity destruction, we love to see it.

When actual deallocation finally happens, the delete callback functions for all cached attributes get called (peep the "Caching" section in the "Groups, Contexts, and Communicators" chapter of the MPI Standard, over at https://www.mpi-forum.org/docs/), and they run in arbitrary order. Which means: don't assume an order. There is no order. It's giving chaos, and that's just the deal. πŸ™ˆ


πŸ’€ NOTES πŸ’€

ngl, the MPI standard straight up does not define what happens if the delete_fn callback invokes other MPI functions. Undefined. Not a vibe we can help you with.

But here's the Open MPI specific rule, and listen closely: in Open MPI it is not valid for delete_fn callbacks (or any of their children) to add or delete attributes on the same object on which the delete_fn callback is being invoked. So don't do that. The object is already mid-transformation, it doesn't need you adding stuff to it. 🚫


😭 ERRORS 😭

Almost all MPI routines return an error value, bestie. How they return it depends on the language:

  • C routines β†’ it's the return result of the function.
  • Fortran routines β†’ it shows up in the last argument.

Before that error value comes back, the current MPI error handler associated with the communication object (so… communicator, window, file, whichever one it's attached to) gets called. And if no communication object is associated with the MPI call at all? Then the call is considered attached to MPI_COMM_SELF, and it calls the error handler hooked up to that. 🌸

When MPI_COMM_SELF isn't initialized β€” which happens before MPI_Init/MPI_Init_thread, after MPI_Finalize, or when you're using the Sessions Model exclusively β€” the error raises the initial error handler instead. You can change that initial error handler by:

  • calling MPI_Comm_set_errhandler on MPI_COMM_SELF when you're using the World model, or
  • using the mpi_initial_errhandler CLI argument to mpiexec, or
  • using the info key to MPI_Comm_spawn/MPI_Comm_spawn_multiple.

And if no other appropriate error handler has been set, then: the MPI_ERRORS_RETURN error handler gets called for MPI I/O functions, and the MPI_ERRORS_ABORT error handler gets called for all other MPI functions. Rules are rules. ✨

Open MPI ships with three predefined error handlers you can use:

  • MPI_ERRORS_ARE_FATAL β€” Causes the program to abort all connected MPI processes. Dramatic? yes. Effective? also yes. πŸ’€
  • 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, it 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, it aborts only the local process. 🌈
  • MPI_ERRORS_RETURN β€” Returns an error code to the application. Chill and polite. πŸŽ€

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
⚠️ Also, heads up: MPI does not guarantee that an MPI program can continue past an error. So like… don't count on it. 😭

See the MPI man page for a full list of MPI error codes. And see the Error Handling section of the MPI-3.1 standard for more information.

See also:

  • MPI_Comm_delete_attr

2003-2026, The Open MPI Community.


okay that's the whole page, bestie 🫢 this was the Open MPI MPI_COMM_FREE(3) man page, and the footer stamp on it says Sep 10, 2026 πŸ’– slay, go free your communicators responsibly, and remember: MPI_COMM_NULL is not a personality. ✨🧚

πŸ“¦ where this page comes from