On 2025-11-11 10:38, Alastair McKinstry wrote:
Hi Drew Yes, I think this would be a good idea. Incidentally, I've just uploaded mpich 5.0.0b to experimental.5.0 should enable GPUs as an option (by default the previous versions failed if built for GPUs and no GPU was present at runtime, environmental variable as a control only, no config file), so it would be good to get a salsa pipeline working for experimental , with and without GPUs, for MPI testing.
Sounds good. It's good raise the level of gpu support in Debian generally, it was a bit underdone in past years.
Also I think it would be good to put mpi_testsuite back into forky.
our Google Summer scholar helped us develop a framework for keeping a record of MPI package performance monitoring scaling over time. Need to activate it to give routine reports, then we can extend it to more packages like mpi_testsuite
(the framework was constructed around the FEniCS testsuite) Drew
Best regards Alastair On 10/11/2025 13:52, Drew Parsons wrote:Hi Alastair (and cc: Debian Science) I raised our current pmix problem (Bug#1120424, #1120413) upstream. Ralph Castain upstream raises an interesting question, https://github.com/openpmix/openpmix/issues/3717#issuecomment-3511548113 He suspect PRRTE might be at the heart of the problems we've got running in buildd chroots with not internet interface (lo only). His recommendation is to package PRRTE separately instead of usingthe bundled source that comes with openmpi, just as we've started doingwith PMIx. Would that work for us? Hard to say if it would make MPI packagingharder or simpler, but might make it easier to backport upstream patches.Cheers, Drew