Skip to content

Meeting 2021 07

Geoffrey Paulsen edited this page Jul 26, 2021 · 1 revision

Open MPI Developer's July 2021 Virtual Meeting

(due to COVID-19, this will be virtual instead of a face-to-face meeting)

The meeting will be determined by most availability. See https://doodle.com/poll/rd7szze3agmyq4m5?utm_source=poll&utm_medium=link

Meeting dates:

  • Thursday, July 22, 2021
    • 12-2pm US Pacific time.
    • 3-5pm US Eastern time.
    • 8-10pm GMT
  • Thursday, July 29, 2021
    • 8-10am US Pacific
    • 11am-1pm US Eastern
    • 4-6pm GMT

Webex information

This is a link to a non-public repo for the Webex info (posting Webex links publicly just invites spam; sorry folks).

If you do not have access to the non-public repo, please email Jeff Squyres to get the Webex info.

Attendance

Please put your name down here if you plan to attend. All rumors of snacks were greatly exaggerated.

  1. Geoff Paulsen (IBM)
  2. Josh Hursey (IBM)
  3. Jeff Squyres (Cisco)
  4. Michael Heinz, Brendan Cunningham (Cornelis)
  5. Raghu Raja (Enfabrica)
  6. Howard Pritchard (LANL)
  7. Ralph Castain (Nanook) (partial attendance)
  8. Austen Lauria (IBM)
  9. William Zhang (AWS)
  10. Brian Barrett (AWS, July 22 only)
  11. Nathan Hjelm (Google)
  12. Todd Kordenbrock (HPE/SNL)
  13. Thomas Naughton (ORNL)

Agenda items

Please add Agenda items we need to discuss here.

  • [Owner?] MPI 4.0 Compliance.
    • MPI-4 stuff we already have (either partially or completely - from the MPI-4.0 doc changelog):
    • MPI-4 stuff no one is working on yet (from the MPI-4.0 doc changelog):
      • 3: Embiggened bindings
      • 4: error handling (is this all done by the recent UT/FT work?)
      • 6: MPI_ISENDRECV and MPI_ISENDRECV_REPLACE
      • 9: Partitioned communication
      • 10+11: MPI_COMM_TYPE_HW_[UN]GUIDED
      • 12: Update COMM_[I]DUP w.r.t. info propagation
      • 13: MPI_COMM_IDUP_WITH_INFO
      • 15: new info hints
      • 16: updated semantics of MPI_*_[GET|SET]_INFO
      • 17: update MPI_DIMS_CREATE (this might be done?)
      • 18: alignment requirements for windows
      • 21: MPI_ERR_PROC_ABORTED error class (was this added by UT/FT work?)
      • 22: Add MPI_INFO_GET_STRING
      • 23: Deprecate MPI_INFO_GET[_VALUELEN]
      • 25: Add MPI_INFO_CREATE_ENV
      • 26: Error reporting before INIT / after FINALIZE (was this added by UT/FT work?)
      • 27: Updated error handling (was this done by UT/FT work?)
      • 28: Updated semantics in MPI_WIN_ALLOCATE_SHARED
      • 29: Audit F08 binding for MPI_STATUS_SET_CANCELED
      • 30: Add MPI_T_* callbacks
      • 32: Audit: have MPI_T functions return MPI_ERR_INVALID_INDEX instead of MPI_ERR_INVALID_ITEM
      • 33: Deprecate MPI_SIZEOF
  • [Howard] PMIx Event handling - which events do we want to handle?
  • [Jeff] Uniform application of OFI and UCX component selection mechanisms
    • What is the strategy that should be used for OFI and UCX components?
    • E.g., https://github.com/open-mpi/ompi/issues/9123
      • Summary: User builds a "universal" Open MPI to use across several different clusters, including support for both OFI and UCX.
      • Somehow the Wrong thing is happening by default in a UCX-based cluster
    • Action: Let's review what the current OFI / UCX selection mechanisms are
    • @rhc54's proposal for fabric selection: https://github.com/open-mpi/ompi/issues/9123#issuecomment-877824063
    • @jjhursey + @jsquyres proposal from 1+ year ago: mpirun --net TYPE where TYPE is defined in a text config file somewhere (i.e., customizable by the sysadmin), and basically gets transmorgaphied into a set of MCA params+values. E.g., mpirun --net TCP or mpirun --net UCX-TCP pulls the definition of those TYPEs from a config file containing:
      # Definitions for mpirun --net TYPE
      UCX-TCP = -mca plm ucx -x UCX_.._TLS tcp
      TCP = -mca plm ob1 -mca tcp,vader,self
      
      • Could easily amend: use --net CLI option as the highest priority, and then take info from PMIx as fallback if user CLI option is not specified.
    • @bosilca's thought that we should be using */mca/common/* more (e.g., have multiple components of the same network type share common functionality for selection)
    • @rhc54: Word of caution. This agenda item conflates two issues - the default selection of what should happen and the user-facing method of informing OMPI on what to do. We should resolve the default selection problem first and separately as this is what is causing the current problems. Default selection must work correctly whether you use "mpirun" or "srun" or "prun" (with a PRRTE DVM), and it should work correctly out-of-the-box without anyone (user or sysadmin) providing parameters.
  • [no particular owner] Plans for better support for GPU offload - do we have any? How important is this to our users?
  • [Josh] MPIR-Shim CI testing
  • [Ralph] Overhaul "mpirun --help"
    • Follow the Hydra model of a high-level help and then help/option (i.e., "mpirun --map-by --help"
Clone this wiki locally