Bugzilla Bug 49953

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 an attachment (id=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 an attachment (id=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.