Re: Bug#563705: MPI implementations in squeeze
Le vendredi 26 février 2010 à 09:54 +, Alastair McKinstry a écrit : Perhaps using pkg-config (an mpi.pc file) would be a better solution to this; it is more standard: the mpicc, etc. approach isn't very scalable, you can't wrap every complex library. Use mpi.pc to point to where includes, etc. are, and alternatives to change the mpi.pc between versions. You can then, if necessary, use dependencies and conflicts within the pkg-config mechanism if need be, which aren't available if you use mixed mpicc / gcc within Makefiles. The problem with .pc is that a lambda user will consider that it is provided by OpenMPI or MPICH2 and expect to find it on other distributions. Causing pkg-config to be useless... Sylvestre -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1267179697.14126.5131.ca...@korcula.inria.fr
Re: BLAS / LAPACK proposal
On Fri, 2010-02-26 at 11:57 +0100, Sylvestre Ledru wrote: Hello, After numerous discussions on this subject, I would like to propose a change on how linear algebra libraries (BLAS / LAPACK implementation) are handle in Debian. I tried to describe the proposal here: http://wiki.debian.org/DebianScience/LinearAlgebraLibraries Any comments ? +1 I would love to see this with atlas 3.8 in squeeze not sure if this is realistic though... Soeren -- For the one fact about the future of which we can be certain is that it will be utterly fantastic. -- Arthur C. Clarke, 1962 signature.asc Description: This is a digitally signed message part
Re: BLAS / LAPACK proposal
Le vendredi 26 février 2010 à 12:25 +0100, Soeren Sonnenburg a écrit : On Fri, 2010-02-26 at 11:57 +0100, Sylvestre Ledru wrote: Hello, After numerous discussions on this subject, I would like to propose a change on how linear algebra libraries (BLAS / LAPACK implementation) are handle in Debian. I tried to describe the proposal here: http://wiki.debian.org/DebianScience/LinearAlgebraLibraries Any comments ? +1 I would love to see this with atlas 3.8 in squeeze not sure if this is realistic though... Regarding the state of Atlas 3.6 in Debian, 3.8 should really make it to squeeze. I will probably fix more RC than creating... * By the way, I committed all the changes in BLAS, LAPACK and Atlas into the Debian Science SVN. It still needs some tweaking but it should be fine. I will be off for a few days (back on Tuesday). Cheers, Sylvestre * Especially when all archs will be built and green: https://buildd.debian.org/status/package.php?suite=experimentalp=atlas -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1267184979.14126.5490.ca...@korcula.inria.fr
Re: BLAS / LAPACK proposal
hallo, not knowing if this fits into this discussion i'd anyhow kindly ask you to have a look at the arpack library. i tried to compile calculix crunchix fe-solver using the provided libraries in lenny (libspooles-dev libarpack2-dev). spooles works perfectly but linking /usr/lib/libarpack.a gives some strange errors (undefined reference to 'd...'). 'cause they all start with d there might be some problem with the precision (calculix needs double ddrv), if i compile the library myself there are no errors like this. maybe this is not a bug but my own stupidity, but i thought these library packages are made for someone (like me) that doesnt know much about the internals of these libs. greetings and thanks in advance, pierrot Virus checked by G Data AntiVirus Version: AVA 19.10283 dated 26.02.2010 Virus news: www.antiviruslab.com #makefile for ccx - calculix solver CFLAGS = -Wall -O3 -I $()/usr/include/spooles -DARCH=Linux -DSPOOLES -DARPACK -DMATRIXSTORAGE FFLAGS = -Wall -O3 -fopenmp CC=cc FC=gfortran .c.o : $(CC) $(CFLAGS) -c $ .f.o : $(FC) $(FFLAGS) -c $ include Makefile.inc SCCXMAIN = ccx_2.0.c OCCXF = $(SCCXF:.f=.o) OCCXC = $(SCCXC:.c=.o) OCCXMAIN = $(SCCXMAIN:.c=.o) SPDIR=$()/usr/lib APDIR=$()/usr/lib LIBS = \ $(SPDIR)/libspooles.a \ $(APDIR)/libarpack.a \ -lm -lc ccx:$(OCCXMAIN) ccx_2.0.a $(LIBS) ./date.pl; $(CC) $(CFLAGS) -c ccx_2.0.c; $(FC) -Wall -O3 -o $@ $(OCCXMAIN) ccx_2.0.a -lpthread $(LIBS) ccx_2.0.a: $(OCCXF) $(OCCXC) ar vr $@ $?
Re: BLAS / LAPACK proposal
Sylvestre Ledru wrote: Hello, After numerous discussions on this subject, I would like to propose a change on how linear algebra libraries (BLAS / LAPACK implementation) are handle in Debian. I tried to describe the proposal here: http://wiki.debian.org/DebianScience/LinearAlgebraLibraries Any comments ? Does it mean now libatlas3gf-* will (also) provide the complete set of lapack subroutines? Would be great from a user's point of view! Thanks, Sylvestre Thanks for taking this up. Regards, ST -- -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4b87cdf8.3060...@gmail.com
Re: BLAS / LAPACK proposal
Le vendredi 26 février 2010 à 21:34 +0800, lukshun...@gmail.com a écrit : Sylvestre Ledru wrote: Hello, After numerous discussions on this subject, I would like to propose a change on how linear algebra libraries (BLAS / LAPACK implementation) are handle in Debian. I tried to describe the proposal here: http://wiki.debian.org/DebianScience/LinearAlgebraLibraries Any comments ? Does it mean now libatlas3gf-* will (also) provide the complete set of lapack subroutines? Would be great from a user's point of view! It is already the case even it is not trivial to use. And Atlas implements only a subset of lapack. On unsupported functions, atlas uses the lapack reference. Thanks, Sylvestre Thanks for taking this up. You are welcome. ;) Sylvestre -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1267191643.14126.6011.ca...@korcula.inria.fr
Fwd: 'vtkedge' uploaded to mentors.debian.net
Hi there, I made a package for VTKEdge. I did it using the umbrella of debian-med, but I am ok changing it to debian-science if people think this is required. I am looking for a sponsor BTW :) Thanks ! -- Forwarded message -- From: mentors.debian.net supp...@mentors.debian.net Date: Fri, Feb 26, 2010 at 4:09 PM Subject: 'vtkedge' uploaded to mentors.debian.net To: mathieu.malate...@gmail.com Your upload of the package 'vtkedge' to mentors.debian.net was successful. Sponsors can now download it. The URL of your package is: http://mentors.debian.net/debian/pool/main/v/vtkedge The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/v/vtkedge/vtkedge_0.1.0-1.dsc - Processing your upload took 16.0 seconds. - If you do not yet have a sponsor for your package you may want to go to http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=vtkedge and set the Seeking a sponsor option to hilight your package on the welcome page. You can also send an RFS (request for sponsorship) to the debian-mentors mailing list. Your package page will give your suggestions on how to send that mail. Good luck finding a sponsor! And thanks for using mentors.debian.net The mentors.debian.net team #Import run: 2010-02-26T16:09:06.759377 -- Mathieu -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/bf0c3b3f1002260710m6418f892q8c928b82af40c...@mail.gmail.com
Re: MPI implementations in squeeze
On Thu, 2010-02-25 at 20:49 +0100, Lucas Nussbaum wrote: On 25/02/10 at 14:22 -0500, Adam C Powell IV wrote: On Thu, 2010-02-25 at 18:10 +0100, Lucas Nussbaum wrote: There is not much progress so far with respect to changing mpi-defaults to use MPICH2 instead of LAM on the architectures where Open MPI is not available yet. This needs a round of binNMUs. Marc Brockschmidt said he will look at the request to debian-release in the next few days, so this might resolve soon as well. Something to consider: this will break a lot of packages which use FORTRAN until 563705 is fixed, and then that will require mods to packages. I understand that bug as: if mpich2 or openmpi don't do the right thing when calling mpif77/mpif90, then symlinks are needed. Is there a proof that either of them doesn't do the right thing? Wouldn't it be more appropriate to fix them to do the right thing? (Those are honest questions -- I don't know anything about fortran) As discussed before (including in the bug), when there are mixed FORTRAN and C++ symbols, it's not clear whether to use mpif77/90 or mpic++. Also, it's a big convenience: a lot of packages make multiple executables and/or libraries, some of which use MPI and some don't. Pointing them to -lmpi -lmpi++ -lmpif77 for the MPI execs/lib directories seems easier than telling them to use mpicc and friends for some targets and gcc for others. I'm not sure I buy that, since mpicc friends also hide include paths, which are not handled with alternatives currently. Are you sure? % update-alternatives --display mpi mpi - auto mode link currently points to /usr/lib/openmpi/include /usr/lib/openmpi/include - priority 40 slave libmpi++.so: /usr/lib/openmpi/lib/libmpi_cxx.so [And a bunch of other slaves] It sounds more like a way to break packages by getting them linked with the wrong version of MPI. Do you know of packages doing that already? I've used this in most of my packages: petsc, hypre, libmesh, the new netgen and med-fichier under development (pending togl and updated hdf5 respectively), and salomé under development. Why would this break packages, if they just build-depend on mpi-default-dev? If the mpicc/mpif77 etc. alternatives work, why not the includes and libs as well? And for something like med-fichier, wouldn't CC=mpicc and friends unnecessarily link a lot of non-MPI executables and libs to MPI libraries, causing memory bloat? Finally, are you sure mpif77 c++-object.o c-object.o f77-object.o -o executable will bring in all of the necessary libraries? I've never tried it, but I'd want to make sure it works for at least OpenMPI and MPICH2 before committing to use it. And we have libmpi.so and libmpi++.so symlinks, why not libmpif77.so? :) Well, maybe it might be a better idea to drop those links ;) Fair enough. :-) -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: Bug#563705: MPI implementations in squeeze
On Fri, 2010-02-26 at 11:21 +0100, Sylvestre Ledru wrote: Le vendredi 26 février 2010 à 09:54 +, Alastair McKinstry a écrit : Perhaps using pkg-config (an mpi.pc file) would be a better solution to this; it is more standard: the mpicc, etc. approach isn't very scalable, you can't wrap every complex library. Use mpi.pc to point to where includes, etc. are, and alternatives to change the mpi.pc between versions. You can then, if necessary, use dependencies and conflicts within the pkg-config mechanism if need be, which aren't available if you use mixed mpicc / gcc within Makefiles. The problem with .pc is that a lambda user will consider that it is provided by OpenMPI or MPICH2 and expect to find it on other distributions. Causing pkg-config to be useless... I'm pretty sure OpenMPI upstream would welcome such a contribution, and I'd be surprised if MPICH2 upstream didn't as well, so I don't think that should limit us. Long-term this is my favorite solution, as other upstreams would likely also welcome patches to their configuration systems to use pkg-config to detect MPI, and if they don't, it's not that hard to maintain those patches. If we commit to this I'd gladly drop the other library and header alternatives symlinks -- with one constraint: pkg-config would need to point to libraries in /usr/lib so libtool doesn't add -rpath /usr/lib/openmpi/lib . -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Re: MPI implementations in squeeze
On 26/02/10 at 10:46 -0500, Adam C Powell IV wrote: On Thu, 2010-02-25 at 20:49 +0100, Lucas Nussbaum wrote: On 25/02/10 at 14:22 -0500, Adam C Powell IV wrote: On Thu, 2010-02-25 at 18:10 +0100, Lucas Nussbaum wrote: There is not much progress so far with respect to changing mpi-defaults to use MPICH2 instead of LAM on the architectures where Open MPI is not available yet. This needs a round of binNMUs. Marc Brockschmidt said he will look at the request to debian-release in the next few days, so this might resolve soon as well. Something to consider: this will break a lot of packages which use FORTRAN until 563705 is fixed, and then that will require mods to packages. I understand that bug as: if mpich2 or openmpi don't do the right thing when calling mpif77/mpif90, then symlinks are needed. Is there a proof that either of them doesn't do the right thing? Wouldn't it be more appropriate to fix them to do the right thing? (Those are honest questions -- I don't know anything about fortran) As discussed before (including in the bug), when there are mixed FORTRAN and C++ symbols, it's not clear whether to use mpif77/90 or mpic++. Also, it's a big convenience: a lot of packages make multiple executables and/or libraries, some of which use MPI and some don't. Pointing them to -lmpi -lmpi++ -lmpif77 for the MPI execs/lib directories seems easier than telling them to use mpicc and friends for some targets and gcc for others. I'm not sure I buy that, since mpicc friends also hide include paths, which are not handled with alternatives currently. Are you sure? % update-alternatives --display mpi mpi - auto mode link currently points to /usr/lib/openmpi/include /usr/lib/openmpi/include - priority 40 slave libmpi++.so: /usr/lib/openmpi/lib/libmpi_cxx.so [And a bunch of other slaves] It sounds more like a way to break packages by getting them linked with the wrong version of MPI. Do you know of packages doing that already? I've used this in most of my packages: petsc, hypre, libmesh, the new netgen and med-fichier under development (pending togl and updated hdf5 respectively), and salomé under development. Why would this break packages, if they just build-depend on mpi-default-dev? If the mpicc/mpif77 etc. alternatives work, why not the includes and libs as well? OK. Since it's harmless anyway, could you prepare and test patches for openmpi and mpich2? Since it would be a slave alternative, it doesn't require any alternatives transition. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100226192228.gb5...@xanadu.blop.info
