Re: perl problem on the HP is a false alarm

[Matt Newville <newville@cars.uchicago.edu>]

John,

> Francois Farges gave me a temporary account on the troublesome
> HP multi-processor machine femto, so I was able to troubleshoot
> the perl problem reported earlier.

BR> You certainly did a lot of work of work by hand investigating what
BR> was going on on that machine.  Wouldn't it be prudent to automate
BR> the tests you did so that they can be run on *any* machine *every
BR> time* the code is updated?

Perhaps getting a user account on every machine Feff is installed on
and running these tests by hand is a reasonable long-term solution.

> I was unable to test the parallel code on femto, since I couldn't find
> lam or mpich or any of the mpi utilities (like mpirun) and libraries
> needed for parallel execution.  If/when these become available, I will be
> glad to test the parallel code.

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?

> I am glad that this turned out to be a false alarm; it's a tribute to the
> care the developers of feff have taken in the past. I think the various
> reactions to the problem also indicate that all of us are concerned about
> such problems, real or potential. Thanks to everyone for their thoughts
> and comments.

It wasn't a false alarm.  Francois couldn't build Feff824.

> FF>"I only have a few comments : everytime one try to improve feff
> FF>it's getting really bad... ,and confusing, and complicated, and
> FF>working only on a few computers in the neighborhood of the
> FF>developpers.
> FF>
> FF>I think the future isn't only in MPI libraries sensu-stricto, but,
> FF>instead, OS that use MP properties, in a cluster enviornment (see the
> FF>APPLESEED project under BSD 4.4 that will be an hit soon, I'm sure).
> FF>That's maybe not as fast a real MPI stuff but that's processor
> FF>evolution that now make the big changes in speed.
>
> Francois has been using FEFF a long time, and although he is not a
> developer, I think his point is well taken. We really need two versions
> of the code(s).  One for developers (which should also be robust and
> portable), and a much more user-friendly, fool-proof version for users.
> Thus I think 8.24 should still be regarded as a developer version, until
> the MPI utilities become standard.

I agree completely with Francois, but come to a different conclusion
from John.  The past few years of the Feff Project do not suggest
that separate 'developer' and 'user' versions of Feff are likely.
I would advocate against attempting separate versions.

If anything, the prospects for a 'User Version' has gotten much
worse in the past years.  Let me re-iterate that Feff8 still reads
feff.inp twice, even though this problem was reported before
release.  The makefiles were recently changed from compiling and
linking isolated files into executables to building single-source
files and running f77 through a shell script, without discussion.
The latest Notes and Comments is from 1994.  This is the THIRD
attempt at a Feff mailing list in two years, and it's still not
listed on the Feff Web Page.  It is difficult for users to tell what
the latest version actually is from the Web Page.  A 'User Version'
would not appear to be a priority.

As for 'Developer Version', there is no mechanism for submitting bug
reports, essentially no documentation on what developments are being
done, and no plan for what is to be done.  I can't even get the code
from the CVS tree anymore.  MPI code was added with minimal testing
and discussion (and is, BTW, full of non-F77-standard code).

Since the Feff developers don't have time to fix year-old bugs (but
getting the latest developer version working for Francois happened
in a matter of days!), add 200 characters to the web page describing
this mailing list, or even participate in this mailing list, you'll
pardon my skepticism when I say that I doubt they're going to have
time to support two different versions of the code.  I'm still
waiting for them to start supporting one. Actually, I gave up hoping
for that long ago, and have advocated changing the license so that
they don't have to.

I'm with Francois.  It's getting really bad.

--Matt, Feff Novice