Re: mpi

[Charles Bouldin <charles.bouldin@nist.gov>]

>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.


Jim was just telling me how he likes the free exchange of views on 
this list, so unlike the much more, uhm, "restrained" atmosphere at a 
.gov institution :).

>
>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/
>>
>>  If you insist on public domain, I'd choose lam because it does include
>>  IMPI. But I vastly prefer vendor implementations, where they are available.
>>  I use SGI's (IRIX) version that comes with the box, so to speak, 
>>the same with an
>>  IBM SP2 (like gseaborg.nersc.gov). That's really why there was so 
>>much work put
>>  into creating a standard for interoperability, and so far implementations in
>>  LAM (public domain), HP/MPI for HP-UX, and MPI/Pro for Windows. See
>>
>>  http://www.lsc.nd.edu/research/impi/
>
>I know nothing about parallelization software and certainly not the
>details of how MPI differs from IMPI.  I have no problem with vendor
>software, but it's hard to count vendor software as "portable",
>which has traditionally been a priority for Feff.  Using open source
>software makes portability easier.

In the discussion of a "developer" Feff vs. "easy-end-user" Feff, I 
think the MPI version clearly falls into the developer category, at 
least for now. The issue has become a little muddled, because the MPI 
code is not merged into the 8.24 version of Feff, with two makefiles 
to build single processor and MPI versions of the code. That was 
viewed as essential so that we could have one version of the source 
and the single/MPI versions wouldn't be constantly drifting apart. 
However, it does lead to the possibility of some very perplexed users 
if they are not interested in MPI and look at the code and wonder, 
"What the devil is all this stuff?".

As for the intial MPI work being done without much 
consultation...that is certainly true, but it was done that way 
because it was totally experimental, and it was initially not totally 
clear that it would work. (Probably Jim never doubted it, but it was 
sure speculative for me!). At this point, the MPI bit is trying hard 
to become mainstream, so further changes can and will be done with 
consultation with all developers.

As for the developer vs. user versions...I am not terribly unhappy 
with what (I think)is done now: Users get a single, monolithic .f 
file, which they just compile, developers get the same source, but 
broken into include files, library files, etc. One can argue over how 
to do the developer version, in terms of perl/noperl, etc, but this 
isn't a bad model to start from. As long as the simple 
compile-it-and-go  version of feff is  derived from concatenating the 
latest stable version the developers are working with, this seems 
like an okay solution.

On standards...it's hard to be opposed to standards when you work at 
a place with the word "standards" in the name :). However, we must 
clearly tolerate some violations of the f77 standard, like double 
precision complex. Others, like looser commenting conventions, 
include files, long variable names, using characters that are not 
technically in the f77 collating set, these are somewhat more 
debatable. I favor a pragmatic approach in which we trade off 
practicality against strict adherence to the ANSI F77 document. So 
long as feff compiles and runs without complaint via g77, that may be 
a reasonable starting point? Perhaps there are other things we can 
think of, other compilers that have to work?

>Again, I'm perfectly willing to hear other ideas and opinions.  If
>Feff is going to distribute code that used MPI, it would be nice if
>there were automated ways to install and use it.  I would not want
to assume that Feff users know anything about parallelization.

At this point, I view the MPI version as still pretty much for 
developers. The exception is that we can start letting people run the 
MPI version as beta testers. I think we need some data on exactly 
what troubles folks encounter as they try to get the MPI version 
running. After that, we can hopefully take those reports and try to 
think about automated ways to get feffMPI installed. I think it is 
okay to take this approach because, (1) clusters to run feff are 
still a very small minority of the total number of feff 
installations, (2) where clusters do exist, they are still fairly 
large and medium-expensive operations and there is usually (but not 
always) a sys$admin or consultant to help out with the installation. 
We don't want to rely on that in the future, because clusters are 
rapidly becoming cheaper and more widely available, but it seems like 
a way to get some beta test feedback.

On mailing lists: Have all the feff users who might be reasonably 
regarded as developers been informed about this list? Should we have 
a separate list for feff users? I think putting everyone who's 
liscensed feff on a list like that would generate a lot of useful and 
interesting feedback about how the code is really used, what 
headaches people encounter, etc.

Chuck