search

conda-forge / mumps-feedstock

A conda-smithy repository for mumps.
BSD 3-Clause "New" or "Revised" License
5 stars 24 forks source link

broken kwant builds because of MPI build #21

Closed basnijholt closed 6 years ago

basnijholt commented 6 years ago

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: https://github.com/conda-forge/kwant-feedstock/issues/34

jbweston commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

mumps-mpi will be created by merging #24

minrk commented 6 years ago

This should be fixed by #24