Hello, ParMetis is a parallel graph partitioning and sparse matrix ordering. Provides the following key components: * Static graph partitioning * Static mesh partitioning * Dynamic graph partitioning * Fill-reducing reordering It is available as an MPI-based library. I wrote an ebuild (with my limited knowledge) because I think to install metis in some other places, but concerns remains about the license. I have to see in /usr/portage/license which one is suited and in any case it is necessary to contact the developers for having permission of distributing the ebuild with portage. See http://packages.debian.org/changelogs/pool/non-free/p/parmetis/parmetis_3.1-1/copyright. I do not think posting this ebuild here violates the terms of the license, and I will, depending from your comments, contact the developers to ask proper permission. Best Regards
Created attachment 30686 [details] parmetis-3.1.ebuild (New Package) I suggest app-sci, since one can use libmetis.a in a serial context, so putting it is sys-cluster will not go.
Created attachment 30701 [details] parmetis-3.1 (New Package, revised ebuild) Forgot a subdir, sorry.
I was missing this package very much. Thanks for making the ebuild. I do have some comments: 1) mpicc did not use my compilation optimization options. 2) I had to edit the ebuild DEPEND field in order to use lam-mpi instead of mpich 3) parmetis is only a library. A package for metis would be much apreciated. Maybe I do it myself. Tiago
I'v added an improved version of this ebuild to the sunrise overlay.
Hi, I am planning to push parmetis to the main tree very soon. I changed quite a bit the ebuild in the sunrise overlay and put a revision in the science overlay. Please test it at much as you can. Also could someone tell me if the metis library that this package installs actually conflicts with the metis library from the main tree? Thanks for any contribution.
Hi Sebastien, yes your version of the ebuild actually conflicts with the libmetis from the metis package. Just look at your shell: * Detected file collision(s): * * /usr/include/metis.h * /usr/lib/libmetis.la * /usr/lib/libmetis.so.0.0.0 * /usr/lib/libmetis.a * /usr/lib/libmetis.so.0 * /usr/lib/libmetis.so I don't know the exact difference between these two metis libraries, but it should be possible to install both on the same system. So I've changed the libmetis from the parmetis package to libMETIS in the ebuild in the sunrise overlay. That solved the problem for me. Because OpenFOAM bug 104257 may depend on the metis AND parmetis package, please improve your package in the science overlay.
Hi Olivier, Yes I know the files conflict. I would like to know what is really the difference between the metis library included in the parmetis and the standard metis one. A quick diff does not show much differences. It could be a candidate for virtual if needed, or simply remove the metis lib in the parmetis one. Anyone knowing this package could help. Concerning openfoam, are you sure it does not require metis>=5 in which case it probably does not even need parmetis?
Hi Sebastien, OpenFOAM comes with parmetis-3.1 and metis-5.0pre2. As I read directly on the OpenFOAm forum and checked by myself (http://openfoam.cfd-online.com/forum/messages/126/6497.html and http://openfoam.cfd-online.com/forum/messages/126/6260.html) the libmetis from the metis package is overwritten by the libmetis from the parmetis package. These two libmetis seems to be very similar but they are not exact identical (even the size of each lib is different). The statement was, that metis is still in development but parmetis isn't. So the suggestion was to RENAME one of the libraries to avoid conflicts. Oliver
I contacted upstream for the state of metis/parmetis, and these are the answers I got: "The Metis library provided in parmetis can be used to replace the library in Metis 4.0.1 (but not the other way around). Metis 5.0 is a major change and is incompatible with both... I'm actually in the process of re-writing the re-write, so do not spend any time on the 5.0." So what I'm thinking is to do a revision bump to metis-4.0.1 to build it from the metis included in parmetis, and make parmetis only build the mpi part, dependending on metis-4.0.1-r1. Does this sound reasonable?
It sounds reasonable to me.
Just for clarification, you want to put in: - metis-4.0.1-r1 the libmetis.so from parmetis-3.1 - parmetis-3.1 just the libparmetis.so from parmetis-3.1 - metis-5.0_pre2 the libmetis.so from metis-5.0_pre2 ? If you install libmetis.so from parmetis-3.1 as libmetis.so.4.0.1 and libmetis.so from metis-5.0_pre2 as libmetis.so.5.0 for example, then it should be possible that one can install metis-4.0.1-r1 and metis-5.0_pre2 at the same time. And then it sounds ok for me.
Folks, I added parmetis to the main tree. I finally decided to go for blocking, since the slotting/virtual did not make much sense and splitting the internal metis in parmetis required too much patching. So the deal is: * if a package depend on any metis, change your deps as DEPEND="|| ( sci-libs/parmetis sci-libs/metis )" (like cholmod) * metis-4.0.1-r1 updated without slotting but blocking parmetis * metis-5.0_pre2-r1 stays masked (upstream advice, comment #9) Oliver, for what I've read in the links you mentioned and elsewhere, openfoam could depend on parmetis only. I am not sure if metis-4 could work with openfoam, but metis-5.0_pre2 is better avoided.
