[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

perl problem on the HP is a false alarm



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.

It turns out that there are two versions of perl on femto,
with a very old version 4. one in the default path,  /usr/contrib/bin/perl 
and an uptodate version 5.6  /usr/local/bin/perl

By altering the path, e.g. (in tcsh)
set path = (/usr/local/bin $path) 

so the uptodate version of perl is seen first, the problem with building
feff8.24 modules, goes away (i.e., the problem is with the old version 4.? 
of perl)!  That is, 

make -f Makefile.sequential src 

properly builds all the feff8.24 fortran modules.

Also, I verified that compiling the modules with default optimization (O2) e.g.,
with the compile script feff_comp.hp adapted for the f90 compiler on femto
compiles the code without errors.

$ cat feff_comp.hp
#!/bin/sh -v
 f90 rdinp_tot.f -o ../bin/rdinp
 f90 pot_tot.f -o ../bin/ffmod1
 f90 ldos_tot.f -o ../bin/ldos
 f90 xsph_tot.f -o ../bin/ffmod2
 f90 fms_tot.f -o ../bin/ffmod3
 f90 path_tot.f -o ../bin/ffmod4
 f90 genfmt_tot.f -o ../bin/ffmod5
 f90 ff2x_tot.f -o ../bin/ffmod6

Finally I tested the code with all three test cases Cu, GaN, and Gecl4 in the Test
subdirectory.

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.

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.

Finally I'd like to inject a comment from Francois Farges in one of his e-mails:

>"I only have a few comments : everytime one try to improve feff 
>it's getting really bad... ,and confusing, and complicated, and 
>working only on a few computers in the neighborhood of the 
>developpers.
>
>I think the future isn't only in MPI libraries sensu-stricto, but, 
>instead, OS that use MP properties, in a cluster enviornment (see the 
>APPLESEED project under BSD 4.4 that will be an hit soon, I'm sure). 
>That's maybe not as fast a real MPI stuff but that's processor 
>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.

  John Rehr
  Feff Project PI