-
Notifications
You must be signed in to change notification settings - Fork 1
2026 01 26 webex
AI can make mistakes. Review for accuracy.
The meeting focused on reviewing and discussing a proposal for new spawn functions in the Power Station MPI, with participants examining various aspects including documentation grammar, naming conventions, and error handling mechanisms. The team explored differences between MPI spawn and related functionalities, debating implementation details and discussing the trade-offs between granularity and overhead in error code handling. After reviewing example code and discussing completion criteria, the group decided to schedule a plenary discussion about the proposal in March rather than pursuing immediate standardization.
- Sonja: Fix grammar error - change "less" to "fewer" in the text about spawning processes
- Sonja: Consider renaming MPI_spawn to MPI_spawn_multiple for consistency with existing spawn functions
- Sonja: Fix error on line 3643 - change argument from "intercom" to "everyone
- Sonja: Give thought to comments and fix issues noted in GitLab
- Howard: Review and provide comments on the pull request regarding the text about what it means for the non-blocking spawn request to be complete
- Sonja: Prepare a plenary discussion for the forum in March about the spawn proposal
- Sonja: Consider filing a PR to upstream MPitch with the spawn implementation
The meeting participants waited for Howard to join, with the main purpose being to discuss a spawn proposal. Once Howard arrived, Sonja inquired about the preferred method to review her pull request, offering options between the PR itself, the diffs, or a PDF version.
Sonja presented a draft proposal for new spawn functions in the Para Station MPI, focusing on changes to the dynamic process model section of the standard. She explained modifications to text describing the procedures, emphasizing that the new functions are independent of any communicator and can be used with both the world and session process models. Howard approved of the use of the term "binaries" to maintain consistency with existing verbiage, and Sonja noted that the proposal was a starting point for further discussion.
Sonja presented a new section on MPI spawn, highlighting its differences from MPI Comm spawn (multiple), such as not requiring a communicator and allowing fine-grained control over connection establishment. The team discussed naming conventions, with Martin suggesting "MPI spawn Multiple" to maintain consistency with other MPI functions. They also debated the use of the "array of max procs" parameter, with Howard questioning its meaning. Sonja explained that it allows for soft spawning, where fewer processes than specified can be launched without an error. The team agreed to further consider the naming conventions and the implications of the max procs parameter.
Sonja and Howard discussed a grammar error in the MPI documentation, where "less" should be replaced with "fewer." They also reviewed the details of MPI spawn functionality, including the handling of info handles and error codes. Sonja explained the rationale behind not including a fine-grained error code array for MPI spawn, noting that runtime systems typically provide a single error code for the entire spawn operation. She advised users to use multiple calls to MPI spawn or MPI ISpawn if they require more detailed error checking.
Sonja and Howard discussed the differences between PIMIX and MPI CommSpawn, noting that PIMIX does not support per-executable error codes. They agreed that it would be clearer for implementers and users if they did not include an array of error codes for MPI ISpawn, as it lacks the connection establishment feature of MPI CommSpawn. Dominik suggested adding a user comment about the trade-off between granularity and overhead. Sonja explained the additional request parameter in MPI ISpawn, which allows for non-blocking spawn operations and provides a request handle for completion checking.
Sonja presented a proposal for new MPI spawn functionality, which would provide an asynchronous mechanism for process spawning without relying on communicators. The discussion focused on defining what constitutes successful completion of a spawn request, with agreement that completion should be determined solely by the runtime system's success in launching processes rather than their subsequent MPI communication. The group reviewed example code demonstrating how the new functionality could be used with MPI sessions, and Howard agreed to review the text around request completion criteria and provide comments on the pull request. The working group decided to schedule a plenary discussion about the proposal in March, rather than pursuing immediate standardization, with Dominik suggesting it would be better to focus on the pure spawning functionality first before adding additional complexity.