[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@…):

 Replying to [comment:7 sean@…]:
 > Replying to [comment:6 wimmer@…]:
 > > - 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
 >
 > [[BR]]
 > Dummy wrappers for parmet… what? You can compile all the optional
 orderings and decide on which one to use at run-time. You can also compile
 MUMPS for parallel and use its sequential algorithm at run-time. As
 homework, you can try it out:
 > [[BR]]
 >
 > * running mpi-mumps + parmetis with 'mpiexec -n 1 ./test_prog'
 > * running mpi-mumps + ptscotch with 'mpiexec -n 1 ./test_prog'
 > * running mpi-mumps + parmetis with 'mpiexec -n 2 ./test_prog'
 > * running mpi-mumps + ptscotch with 'mpiexec -n 2 ./test_prog'
 > * running mpi-mumps + internal ordering with 'mpiexec -n 1 ./test_prog'
 > * running mpi-mumps + internal ordering with 'mpiexec -n 2 ./test_prog'
 >
 > And then try all of that again with sequentially built MUMPS.

 Sure you can do that, but this wasn't my point. My point was that after
 you specified for which orderings MUMPS is built by specifying any
 combination of "-Dpord -Dmetis -Dparmetis -Dscotch -Dptscotch", you have
 to always link against all of these libraries.

 Now, it is worth noting that the parmetis switch does not include all of
 the functionality of the metis switch, as MUMPS offers more functionality
 when only sequential analysis is used (see documentation of the ICNTL(28)
 parameter). Hence, one would like to include both parmetis and metis at
 the same time anyways (I noticed that your Portfile only had parmetis
 included). If a user would want to use the sequential version, there is
 not reason for him to use the parallel analysis at all (it gives no
 additional functionality, but even reduces it), but he/she would always
 need to link against parmetis/ptscotch.

 This is, in my opinion, a good reason to have separate sequential and
 parallel versions.

 That in addition to the fact that while I believe that it is probably
 possible to use the parallel version in sequential mode without mpi (by
 linking against mpiseq and dealing with different mpi's properly), the
 MUMPS web page does advocate separate sequential and parallel versions
 (http://graal.ens-lyon.fr/MUMPS/index.php?page=faq#5).

 > > 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)
 >
 > [[BR]]
 > Well, for one, I don't like having an unnecessary port (sequential
 MUMPS) since all its functionality would be provided by the parallel
 version.
 >
 > > 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).
 >
 > [[BR]]
 > Instead of a hypothetical situation, do you have any examples? I have
 updated most of the ports (in my side repo) to use the newest version of
 MeTiS / ParMeTiS but might have missed some. Since it's a very, very
 simple change (usually two lines of code change), I would rather push
 others to update their code.

 I don't have a particular example (except MUMPS itself), but suppose I
 want to install versions of Mumps, SuiteSparse, SuperLU, ... not provided
 by macports - then I have to do the patching myself (or manually install
 metis 4). Metis 4 was the standard for more than 10 years when there was
 no development there; scientific codes are usually conservative in that
 you don't want to touch what works, so people do not easily change to
 metis 4 (look at Mumps and SuiteSparse).

-- 
Ticket URL: <https://trac.macports.org/ticket/40039#comment:8>
MacPorts <http://www.macports.org/>
Ports system for OS X