From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JYt0W-0005Zg-8w for garchives@archives.gentoo.org; Tue, 11 Mar 2008 01:10:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0380CE03F2; Tue, 11 Mar 2008 01:10:19 +0000 (UTC) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.176]) by pigeon.gentoo.org (Postfix) with ESMTP id C156EE03F2 for ; Tue, 11 Mar 2008 01:10:18 +0000 (UTC) Received: by el-out-1112.google.com with SMTP id j27so1399654elf.14 for ; Mon, 10 Mar 2008 18:10:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; bh=ZJmuc2Y4sVu2St6XywvIFbvrTfIVLyQxFyb/aC6S/Og=; b=b5/ELkdbC5vcrQfwHnmxVUaT13XcHseoeiE0Bd525L+Y/zxwSnK7zv4Cd3x0LQ23/DJFUm8bJoINRR5yi/53m+bowlq3A0OzoCX4yTm+D279s9Y++AVBRzn38vTOTql9Gs3DlEqomq2nmKAl8BBw82SAE55hM+QTllULIrWfHjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; b=eLXk8JBYO9LN2aGy0IcS89F92xG4nkyEZC9w7j2Yp1MFmiBf8ZU8tnm9xdxohKpurC04IaVx5x768AQzX1PyTP9Dn5qP8Tj44L0Eoblyl6bjsp0AESMbt3FjI+X4/k1klcfDjTchWm0qbYVwdL2H0qgVZXd/Tc9imaEVQ3qC50o= Received: by 10.151.9.1 with SMTP id m1mr3205629ybi.81.1205197818198; Mon, 10 Mar 2008 18:10:18 -0700 (PDT) Received: from mejis.cold-front ( [71.232.26.219]) by mx.google.com with ESMTPS id a44sm16963359rne.2.2008.03.10.18.10.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 10 Mar 2008 18:10:16 -0700 (PDT) Received: by mejis.cold-front (Postfix, from userid 1000) id BED7854050; Mon, 10 Mar 2008 21:07:32 -0400 (EDT) Date: Mon, 10 Mar 2008 21:07:32 -0400 From: Justin Bronder To: gentoo-cluster@lists.gentoo.org Subject: [gentoo-cluster] Re: Installing and using multiple MPI implementations at the same time. Message-ID: <20080311010732.GA26618@mejis.cold-front> References: <20080208031923.GA27361@mejis.cold-front> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-cluster@lists.gentoo.org Reply-to: gentoo-cluster@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) Sender: Justin Bronder X-Archives-Salt: b16bed66-00b5-42a4-af21-8514ba4e293a X-Archives-Hash: 554760921c72ba05cac03815573565ca --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/03/08 18:31 +0200, Alexander Piavka wrote: > > Hi Justin, > > I've started playing with your empi implementation. > > Some problems & suggestions: > > 1)'eselect mpi set ...' does not check for existance of ~/.env.d dir > and fails if one does not exists. Fixed in eselect-mpi-0.0.2 > > It creates ~/.env.d/mpi which looks like this: > ---------------------- > PATH=3D"/usr/lib64/mpi/mpi-openmpi/usr/bin:/usr/local/sbin:/usr/local/bin= :/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.= 1.2:/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin" > MANPATH=3D"/usr/lib64/mpi/mpi-openmpi/usr/share/man:/etc/java-config-2/cu= rrent-system-vm/man:/usr/local/share/man:/usr/share/man:/usr/share/binutils= -data/x86_64-pc-linux-gnu/2.18/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/= 4.1.2/man:/opt/blackdown-jdk-1.4.2.03/man:/etc/java-config/system-vm/man/" > LD_LIBRARY_PATH=3D"/usr/lib64/mpi/mpi-openmpi/usr/lib64:" > ESELECT_MPI_IMP=3D"mpi-openmpi" > export LD_LIBRARY_PATH > export PATH > export MANPATH > export ESELECT_MPI_IMP > ---------------------- > > while the following would be better: > ---------------------- > PATH=3D"/usr/lib64/mpi/mpi-openmpi/usr/bin:${PATH}" > MANPATH=3D"/usr/lib64/mpi/mpi-openmpi/usr/share/man:${MANPATH}" > LD_LIBRARY_PATH=3D"/usr/lib64/mpi/mpi-openmpi/usr/lib64:${LD_LIBRARY_PATH= }" > ESELECT_MPI_IMP=3D"mpi-openmpi" > export LD_LIBRARY_PATH > export PATH > export MANPATH > export ESELECT_MPI_IMP > ---------------------- > > maybe even > ---------------------- > if [ "X${PATH}" !=3D "X" ]; then > export PATH=3D"/usr/lib64/mpi/mpi-openmpi/usr/bin:${PATH}" > else > export PATH=3D"/usr/lib64/mpi/mpi-openmpi/usr/bin" > fi > if [ "X${MANPATH}" !=3D "X" ]; then > export MANPATH=3D"/usr/lib64/mpi/mpi-openmpi/usr/share/man:${MANPATH}" > else > export MANPATH=3D"/usr/lib64/mpi/mpi-openmpi/usr/share/man" > fi > if [ "X${LD_LIBRARY_PATH}" !=3D "X" ]; then > export=20 > LD_LIBRARY_PATH=3D"/usr/lib64/mpi/mpi-openmpi/usr/lib64:${LD_LIBRARY_PATH= }" > else > export LD_LIBRARY_PATH=3D"/usr/lib64/mpi/mpi-openmpi/usr/lib64" > fi > export ESELECT_MPI_IMP > ---------------------- Yeah, you're probably right. However, I need a way to deal with cleaning o= ut the environment when the user calls the unset action, or changes from one implementation to the other. Using what you have above, if the user then called 'eselect mpi set mpi-lam' and sourced ~/.env.d/mpi, they would first have the correct paths for mpi-openmpi followed by the ones for mpi-lam in their environment. See below for why this scares me. > > Also, probably . besides /etc/env.d/mpi/mpi-openmpi the /etc/env.d/XXmpi > file should also be created with the default empi profile then 'eselect m= pi=20 > set ' > is run. I'm willing to be told why I'm wrong, but I left out the above for what I believe is a good reason. If you set say, openmpi to be your default implementation on the system level, then a user eselects lam-mpi, the user will still have mpif90 in their path. This is a big deal because lam-mpi does not provide bindings for f90, hence the user could quite quickly become confused as to why their code using f90 and c is in shambles when they try = to compile. The above can still happen if openmpi is emerged normally. I have no clue how to deal with that yet either. If we keep the ugly ~/.env.d/mpi file, along with the environment stripping ability, there is no reason that a global mpi profile couldn't be used. Wh= at do you think? > > 2)another problem is a failure to install binpkg of openmpi on another=20 > identical systems, the error is > > * > * ERROR: mpi-openmpi/openmpi-1.2.5-r1 failed. > * Call stack: > * ebuild.sh, line 1717: Called dyn_setup > * ebuild.sh, line 768: Called qa_call 'pkg_setup' > * ebuild.sh, line 44: Called pkg_setup > * openmpi-1.2.5-r1.ebuild, line 23: Called mpi_pkg_setup > * mpi.eclass, line 306: Called die > * The specific snippet of code: > * [[ -f "${FILESDIR}"/${MPI_ESELECT_FILE} ]] \ > * || die "MPI_ESELECT_FILE is not defined/found.=20 > ${MPI_ESELECT_FILE}" > * The die message: > * MPI_ESELECT_FILE is not defined/found. eselect.mpi.openmpi > * > * If you need support, post the topmost build error, and the call stack = if=20 > relevant. > * A complete build log is located at=20 > '/var/tmp/portage/mpi-openmpi/openmpi-1.2.5-r1/temp/build.log'. > * > > I thinks this is due to MPI_ESELECT_FILE being defined in pkg_setup() of= =20 > openmpi ebuild and not in top of ebuild (will check if this would help=20 > later) Foolish mistake on my part. MPI_ESELECT_FILE can be defined in pkg_setup as that always gets called (I believe). However I can't check that file there as emerging binpkgs doesn't give access to FILESDIR. I've committed a fix = to the overlay. > > 3) If i have PORTDIR_OVERLAY=3D"/usr/local/overlays/csbgu /tmp/empi" > empi --create --implementation mpi-openmpi =3Dsys-cluster/openmpi-1.2.5-r1 > would create mpi-openmpi category tree under=20 > /usr/local/overlays/csbgu/mpi-openmpi > since it's first overlay in PORTDIR_OVERLAY, it would be nice if it could= =20 > ALWAYS be created under the empi overlay i.e /tmp/empi/mpi-openmpi > Of couse i can put the empi overlay first in PORTDIR_OVERLAY instead > but i want to avoid manual tweaking as much as possible. > With all mpi-implementation residing in the same overlay tree as empi > it would much more convienient , for me, to auto distribute single overla= y=20 > among cluster hosts and avoid possible need for commands > like 'empi --create --implementation mpi-openmpi ...' Also fixed, added the --overlaydir to the command line arguments. Thanks for trying this out, it makes me feel useful :) --=20 Justin Bronder --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFH1dtU4MrvBE1wQ8kRAhjoAJ9qRhr/BHdavp9P44QN61AAMnw6fgCgrqKg K7VItSDXW0QkmxRIYPh16Go= =f+Mo -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- -- gentoo-cluster@lists.gentoo.org mailing list