On Sat, 2008-11-15 at 21:04 -0600, Dirk Eddelbuettel wrote: > On 14 November 2008 at 23:12, Steve M. Robbins wrote: > | Howdy, > | > | > | On Thu, Oct 30, 2008 at 07:48:19PM -0400, Adam C Powell IV wrote: > | > [Copying -beowulf as there's likely some interest there as well.] > | > > | > On Thu, 2008-10-30 at 15:21 +0100, Manuel Prinz wrote: > | > | > > When building against OpenMPI, there are a few choices: > | > > > | > > 1. Do not build packages using OpenMPI on the unsupported arches. > | > > 2. Build against OpenMPI on the supported ones, fall back to LAM on the > | > > unsupported ones. > | > | [ ... ] > | > | > As for -lam where there's no openmpi, I only know of petsc and babel. > > [ For r-cran-rmpi, I also fall back to using LAM where Open MPI is > missing. Perusing NEW today, I saw that Adam falls back to MPICH for the new > Arpack. May be a better fall-back, but I personally have used LAM and no > MPICH before Open MPI. I guess at some point we need to consolidate out MPI > efforts. ] > > | I have subsequently adopted this approach for minc, which uses MPI via > | hdf5. I will likely adopt it for boost, too, unless someone has a > | better idea. > | > | While reading this thread, however, I had an idle thought. Could we > | prepare an "mpi-default-dev" or "sensible-mpi-dev" package for us to > | build-depend on? This would be something like the gcc-defaults > | package and simply depend on the appropriate -dev pacakges (OpenMPI on > | some architectures, LAM on the rest). > | > | The idea is to put the messy details about which architectures support > | OpenMPI and which use LAM in one place. > > Sounds good to me, and I am cc'ing the pkg-openmpi list. I won't have spare > cycles to work on it, but it strikes as a fundamentally sound suggestion. I'm all set to make this happen. Manuel, you mentioned getting OpenMPI to work on all arches as your top priority; what's your expected timeframe? I know, "when it's ready" or "real soon now". But if this will happen in plenty of time for packages to transition before squeeze, then there's no point in doing mpi-defaults. > And while we're at it, it may also make sense to try to come to a consensus > of our MPI 'preferences' within Debian. I.e. which one should be the default > and own the 'highest' alternatives level. Good point. I'm happy to change mpich to below the priority of OpenMPI, maybe the same as lam? And within mpich, ch_p4 is the "default" but should be below ch_p4mpd (if you install mpd then you're probably running the daemons); I'll put ch_shmem between them. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
Attachment:
signature.asc
Description: This is a digitally signed message part