Re: PetSc

[Adam C Powell IV <hazelsct@mit.edu>]

"Eray Ozkural (exa)" wrote:

> Hi,
>
> I'm using PetSc for a CFD demo on our 32 node cluster here,
> and here are some comments regarding its use of mpich
>
> Well, for a real cluster we have found mpich to be an awful
> thing. We use LAM and avoid using mpich, it's not good enough
> for us. Thus, we were surprised to find petsc depending exclusively
> on mpich.

The reason the PETSc packages depend on mpich is that they can use some of its
profiling (?) features in libmpe, and it seemed this might be useful to some
people.  As for why it depends exclusively on mpich, there are various
incompatibilities which make it difficult to just drop in one or the other, and
though in the future it may be possible to just make the switch in
/etc/alternatives, that isn't practical for now.  So it must be one or the
other.

Also, I could not find any clear indication on this list that lam was so vastly
superior to mpich.  I would love to hear your (plural, the list's) thoughts and
experiences.

> I know that it is a TODO thing as I had to change the petsc
> build to use lam, but I think this needs some consideration.
> Would it be too expensive to include also the packages which depend
> on lam?

Well, it would be difficult but not impossible to build both sets of packages
from the same source package in one debian/rules, there would have to be a
*very* good reason to make it worth my extra time and doubling the load on the
autobuilders, disk space on the mirrors, etc.

But if you can convince me that it should be built with lam instead of mpich
(i.e. if lam's improved performance is worth dropping libmpe), I'd be glad to
make the switch.

Indeed, you can probably make the switch yourself- I've put sample lam settings
in bmake/linux*/base.site.  I haven't tested the lam settings yet though...

By the way, while you're here, I'd like to ask something unrelated: do you think
it's worth having versioned package names for the non-shlibs packages, when
upstream refuses to support old versions?  The original thought was that some
people might need to be able to build against old versions, but the same could
be said about any lib, and most only have the latest version in -dev.  But I'm
growing less convinced of this, and the packages do use a *lot* of disk space!

Thanks for the feedback,

-Adam P.

              Welcome to the best software in the world today cafe!