Re: mpi

[James S Sims <jim.sims@nist.gov>]

Matt Newville wrote:
> 
> Hi Jim, Everyone,
> 
> I hope I'm not sounding too pissed off at any one person on this
> list.  I think there are serious problems with the Feff Project,
> but I wouldn't be wasting my (and your) time if I didn't want it
> to succeed.  I'll try to refrain from ranting too much.
> 

Hi Matt,

No problem, as far as I am concerned. As I told John, the thing I miss
most about academia is the free and open exchange of ideas and opinions :=)

> On Thu, 8 Mar 2001, James S Sims wrote:
> > >
> > > MPICH is non-GPL open-source, so why not include it with the Feff
> > > distribution and automatically build it for everyone who can use it?
> >
> > Because it doesn't include IMPI -
> >
> > http://impi.nist.gov/

guess I shouldn't have thrown in a plug for us :=)

> It looks to me like lam uses a BSD-like license, and even has an
> impi server associated with it. Is this server any good?  If lam
> uses a BSD-style license, then one option might be to bundle it with
> Feff, test whether a 'vendor-supplied' IMPI library is available on
> a system, and, if not, install and use lam (and the server if
> necessary???).  That way everyone could get at least a minimal IMPI
> implementation.  I don't know enough about it to know if that's
> really possible:  Does that seem reasonable to you?

lam or mpich really makes no difference to me, or public domain versus
vendor MPI. Hopefuuly the code is flexible enough to cover all situations.
One reason for preferring lam, if you require a public domain MPI, is that 
we have a project going with the lam team at Notre Dame, but that is just a 
personal reason.

Lam can be run with or without the impi server, but I see now that I took
the discussion down a path we don't want to go. Forget I brought up IMPI,
it really is not relevant to Feff or FeffMPI. My mistake.

While I understand where you are coming from, and I applaud your desire
to make FeffMPI as easy to use as it possibly can be, I also understand the
magnitude of the undertaking and I, for one, simply don't have the time. It all
comes down to a practical matter, in my opinion, which is, do the advantages
of the parallel gains outweigh the disadvantages that you are focusing on?

I like to think of MPI as being analogous to a Fortran compiler. You already
defer to local experts for how to best compile Feff on any given machine,
supplying, perhaps, a "best choice" for one or two machines, and making 
recommendations, where you can, but to meet the least common denominator 
just requiring a practical adherence to the Fortran standard (i.e., that it 
get past all Fortran compilers anyone has attempted to compile on). I propose 
that MPI
be treated in the same spirit. If my MPI code really is generic enough 
(and I think it is) that it will work on the MPI that anyone will try it on, then
I've done my part. Analogous to relying on local expertise for how to compile
and run Fortran programs on your particular computer, a certain level of local 
experience in how to compile and run MPI programs is also needed, to be able
to take advantage of the "parallel option".

Just my 2c.

Jim