Bug#586340: libelmersolver-5.5.0: should depend on mumps

[Adam C Powell IV]

tags 586340 pending
thanks

Hi Denis,

This fix has been in the alioth repository for some time, and I more
recently added a configure test for MUMPS in Elmer itself.  I've been
using it, it works quite well, going from 4 -> 8 cores in a 300k element
run roughly doubles the speed (but it should scale quite a bit larger
than this).

This will land in unstable as soon as it gets through NEW, but will
FTBFS because of bug 589763 which only requires a binNMU of ScaLAPACK.
I'll use that as an excuse to bump the severity of 589763 to serious, so
it finally gets some attention before the squeeze release.

Though this won't get into squeeze because of its freeze status, it
should get into Ubuntu Nutty, and is already in my Opennovation Ubuntu
Lucid repository at www.opennovation.org/ubuntu/ .

-Adam

On Sun, 2010-07-25 at 09:08 -0400, Denis Laxalde wrote:
> Adam C Powell IV a écrit :
> > block 586340 by 589763
> > thanks
> > 
> > On Fri, 2010-07-02 at 11:45 -0400, Adam C Powell IV wrote:
> > > Hello,
> > > 
> > > On Wed, 2010-06-30 at 15:23 +0200, Denis Laxalde wrote:
> > > > Hi Adam and thank you for your response.
> > > > 
> > > > Le mardi 22 juin 2010 à 18:10 -0400, Adam C Powell IV a écrit :
> > > > > Hi again,
> > > > > 
> > > > > On Tue, 2010-06-22 at 17:23 -0400, Adam C Powell IV wrote:
> > > > > > Hi and thank you for the report.
> > > > > > 
> > > > > > Looking at the forum [1], it seems that one needs to build Elmer with
> > > > > > METIS in order to have it link with MUMPS.  I link it with Scotch, but
> > > > > > even so Elmer never even tests MUMPS linkage.
> > > > > > 
> > > > > > [1] http://www.elmerfem.org/forum/viewtopic.php?f=2&t=234
> > > > > > 
> > > > > > Looking at fem/configure, there's no reference to mumps there either.
> > > > > > 
> > > > > > It looks like this is an "undocumented" feature, where one needs to
> > > > > > compile with -DHAVE_MUMPS and see if everything works.  Not a trivial
> > > > > > thing, but I'm willing to give it a try.
> > > > > 
> > > > > Looking again at the list of symbols which this needs, it requires
> > > > > metis_nodend_, ParMETIS_V3_NodeND and metis_nodewnd_ for which there are
> > > > > no templates in the Scotch headers.  So I'm afraid this won't be doable,
> > > > > without either extending scotch, or modifying the Elmer source to not
> > > > > require these.
> > > > > 
> > > > > Note that I have modified the Elmer source before to work around Scotch-
> > > > > Metis incompatibility, see debian/patches/no-metis-partmesh.patch .  But
> > > > > it's pretty involved, and I don't have the motivation right now.  Do you
> > > > > have some time to put into it?
> > > > 
> > > > I have to admit that all this is not that clear for me. But, as I am
> > > > interested in this issue, I think I can spend some time investigating.
> > > > However, given my actual knowledges (about packaging, building etc.),
> > > > it may take some time...
> > > 
> > > I just found a post from Monday on the Elmer forum which gave this link:
> > > http://sourceforge.net/apps/mediawiki/elmerfem/index.php?title=Elmer_compile_parallel
> > > 
> > > Let me see if I can use this info to patch Elmer to link successfully
> > > with MUMPS...
> > 
> > So I made a patch which makes the MUMPS linkage much easier, and the
> > package uses it.  Trouble is, there's a problem with the ScaLAPACK
> > package which prevents it from working now, hence the bug blockage (by a
> > new bug against scalapack which I filed this afternoon).
> > 
> > I'm working on editing the package slightly to work with the Scotch
> > version of MUMPS, which should work somewhat better, I think.
> > 
> > Okay, will upload when everything's in place.
> 
> Great news! I wish I had the opportunity to work on this myself, but you
> were definitely faster... Next time, hopefully.
> Thank you for your work!
> 
> Denis.
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20101029/67dfa415/attachment.pgp>