Does MUMPSseq.jl build on Windows

[ViralBShah]

As I am working a bit on the sparse solvers in Base, I want to make them less dependent on SuiteSparse. We can then have a completely non-GPL sparse solver library.

Does MUMPS build on Windows? If so, it has all the features to replace SuiteSparse.

[ViralBShah]

Cc: @tkelman

[tkelman]

The package, no. The library itself, with difficulty, yes. Upstream only provides a 90's-style makefile-fragment build system, it's really not up to the portability we need to use in base in terms of building shared libraries across all systems. I am looking at packaging it via WinRPM so it can be usable for packages at least.

[tkelman]

I've also been told elsewhere that Mumps 5.0 should be released relatively soon, but they're not likely to improve much in their build system.

[ViralBShah]

Can we get our Makefile changes accepted upstream? At least the fact that it builds is good enough - and that it is worthwhile to abstract the sparse solvers from base, which are a bit too tightly integrated at the moment for my liking.

[tkelman]

There's no public version control. There's a mailing list but I have no idea whether patches would ever be incorporated. And it's in Fortran, I'd really rather not add more Fortran dependencies to base Julia.

[ViralBShah]

It really doesn't matter whether fortran dependencies are in base or not. We will want base to be GPL-free at some point, and we will also need sparse solvers. They can be provided as a package or as part of base, but the need will continue to remain.

Why do you not like Fortran dependencies?

[tkelman]

I've learned to live with them, but there is exactly 1 widely used open source Fortran-90-or-newer compiler that is available cross-platform (g95 technically also exists, but appears not to support win64 or recent osx), and that compiler and its runtime library are rarely, if ever, installed by default. The libgfortran dependency causes endless frustration - JuliaLang/julia#8442. Neither LLVM nor MSVC include a Fortran compiler, causing more compatibility headaches.

Just for reference here, COIN-OR has maintained its own autotools build harness for Mumps (just the double-precision, sequential parts) for at least 8 years. If the Mumps developers cared about shared libraries or building cross-platform with a build system more reasonable than manually copying around and editing makefile fragments, they probably would have incorporated something by now.

[ViralBShah]

Ah - I didn't know about the MSVC not having fortran. This makes sense.

[tkelman]

In an ideal world, Intel could be convinced by the scientific computing community to open-source their Fortran compiler front-end and it could be incorporated in LLVM the way they're slowly doing with their OpenMP runtime.

Or we eventually replace all our Fortran dependencies - help make BLIS/FLAME as good or better than OpenBLAS, Elemental as good or better than Mumps and Scalapack, IterativeSolvers.jl as good or better than Arpack, etc. Not exactly possible today, but give it another few years and maybe.

[ViralBShah]

Yes - few years and maybe. The challenge is that making these robust and production quality is not always the focus of the academic community, and doing the last bit of hard work takes a lot of time.

[tkelman]

Anyway I think modularizing the sparse stuff is a good idea, but Base needs to be in better shape for allowing different solvers to provide the functionality. Worth noting is JuliaSmoothOptimizers/MUMPS.jl@0222038, though that package's over-reliance on C wrappers and use of Linuxbrew and Makefiles instead of BinDeps is not great from a portability standpoint.

Can we please have one and only one MUMPS.jl package with a permissive license, no license violations by illegally redistributing Metis 4.0's source code (my bad on that one, nevermind), using best-practices BinDeps instead of C or Fortran wrappers, make it work cross-platform in serial, and work with MPI.jl on unices (to start with)?

Also base Julia's generic Linux binaries won't work with Mumps either, because of the libgfortran problem with the buildbots. We need to fix that or none of this is going to work.

[ViralBShah]

We should certainly do one MUMPS package and fix the libgfortran issue too.

[tkelman]

making these robust and production quality is not always the focus of the academic community

This is a much more tractable problem when these projects are using modern, open software development processes and willing to accept contributions. "Robust and production quality" Fortran code also comes with Fortran development practices that are just not sustainable in 2015.

[dmbates]

Totally agree with @tkelman about the modern, open software development processes and tools. I find it quite frustrating that most open-source sparse matrix systems do not even have a public repository, let alone a configuration mechanism of any sort.

[tkelman]

Related discussion (mostly me venting, let's be honest) here: JuliaInv/MUMPSjInv.jl#4

Debian, Fedora, openSUSE, Homebrew, COIN-OR, me (cross-compiling https://build.opensuse.org/package/show/home:kelman:mingw-coinor/mingw64-mumps), and probably several other distributions/projects all have patches or workarounds to build shared libraries of Mumps. All a little different.