#40039: New port: mumps 4.10.0 - a library for solving sparse linear systems -------------------------+-------------------------------- Reporter: wimmer@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Resolution: | Keywords: Port: | -------------------------+-------------------------------- Comment (by wimmer@…): Sorry, was away for a few days, hence only now the reply (by the way - let me know if you think this discussion is not appropriate in the port submission ticket, although I think it is, as it's relevant for the port under consideration) Replying to [comment:5 sean@…]:
Replying to [comment:4 wimmer@…]:
As far as I've seen, you have the parallel version of Mumps in the
portfile, right? I'm personally more interested in the sequential version anyways.
[[BR]] They are the same.
It is actually not quite clear to me, if a single build of Mumps can be used both in parallel or in sequential - in the end the difference is just that dummy mpi library libmpiseq. Still, in the FAQ they say that one must decide between a parallel or sequential installation, and also Debian has two distinct versions of the library - so this might seem the best strategy for macports, too.
[[BR]] MUMPS only uses MPI code and loads a sequential version (libmpiseq) when using serial (as you note). I am against having two ports that do the same.
There's two things to note there: - the sequential mpiseq has its own mpif.h, with definitions that differ from e.g. openmpi. From the Mumps source code it's hard to tell if there is some dependency on that particular mpif.h. Presumably not, but without the developers confirming this ... In any case one has to be careful which mpif.h to use. - Mumps has the orderings it can use defined at compile-time (with -Dparmetis etc.). For a variant you'd want to use mostly in parallel, this means you want to compile it with the parallel parmetis and ptscotch. Now, assuming you can use the parallel version also in sequential mode by linking mpiseq, you still would have to link against parmetis and ptscotch although in the sequential version you wouldn't ever use it. Now, one could presumably fix this by adding dummy parmetis/ptscotch wrappers to mpiseq, but that's even more patching What's so bad about having both a sequential and a parallel version installed (from the same Portfile)? This is how Debian does it, so it's kind of a standard (with the sequential version having a trailing _seq in the library name)
As far as parmetis is concerned: Wouldn't it make sense anyways to keep a metis4 variant in macports? Many scentific programs use the old API, and although the changes are not big (i.e. patchable), it might be useful.
[[BR]] The changes to get scientific programs using the new METIS 5 api (and 64 bit ints) is pretty trivial. I see no reason to keep an old version around since the patches to fix these packages (MUMPS, SuiteSparse, etc.) are small.
I was mostly thinking about people wanting to compile software that uses metis v4 - those wouldn't want to patch everything themselves. (even for macports, if you can avoid patching stuff, I think it's better, with every patch you can make a mistake). -- Ticket URL: <https://trac.macports.org/ticket/40039#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X