[MacPorts] #40039: New port: mumps 4.10.0 - a library for solving sparse linear systems

[MacPorts]

#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