broken kwant builds because of MPI build

[basnijholt]

kwant currently has no MUMPS support (even though MUMPS should do nearly ALL the heavy lifting there), I thought I had fixed it in the latest build.

We used to link against mpiseq however that library isn't being build anymore. Linking against the MPI versions will result in errors.

Before we linked against: zmumps mumps_common pord metis esmumps scotch scotcherr gfortran

Now I did: ptesmumps ptscotch ptscotcherr mpi mpifort scalapack openblas pthread plus all the former libs.

When linking agaist the MPI libs, kwant test error on:

Attempting to use an MPI routine before initializing MPICH

@jbweston and @michaelwimmer do you think we should build the sequential version of MUMPS again?

Related: conda-forge/kwant-feedstock#34

[jbweston]

I think that this is the most sensible course of action. Debian has several different packages for MUMPS, each with a different build configuration (sequential/parallel, with/without scotch), so this seems something common

[basnijholt]

@pstjohn I see that ipopt is also linked against the sequential version of MUMPS.

@minrk do you think we should revert the MPI version MUMPS and make a separate package? And are there any libraries where you already use MUMPS with MPI support?

[pstjohn]

Despite maintaining the ipopt feedstock I don't have a great idea as to its particular requirements for the MPI build requirements. Is this related to #6?

[minrk]

That sounds like splitting serial and parallel mumps into separate packages is the right thing to do. I haven't used parallel mumps yet (PETSc is where I want to use it next).

[minrk]

I'd like to take another stab at getting parallel mumps. Scotch is currently building ptscotch in a branch. I could do the same with mumps-parallel here. However, looking at debian it seems like maybe mumps canonically should be parallel, and mumps-seq should be the non-mpi variant, or should we let history decide who gets 'mumps' and call it 'mumps-parallel' or 'mumps-mpi' or something?

[basnijholt]

should we let history decide who gets 'mumps'

That's probably a good idea, mostly for backward compatibility.

mumps-mpi or mumps-parallel, both sounds good to me.

[minrk]

mumps-mpi will be created by merging #24

[minrk]

This should be fixed by #24