towards feff8.2 release

[Alex Ankudinov <alex@leonardo.phys.washington.edu>]

Dear developers,

We need to make several changes before feff8.2 can be released to general
feff users.  We would greatly appreciate both comments and help on
any of the items, proposed  below.

A. Changes needed for feff8.20x5
   clean up I/O structure of the code and add comments for developers.

  Proposed structure:

  1) RDINP will read feff.inp and write separate module.inp files and 
  a separate geom.dat (ATOM card data).
    Each module reads geom.dat, one module.inp and several previous_module.bin
  files and writes single current_module.bin.
  Thus each module will be independent and only have it's own input and output.

  This also implies that we will get rid of all the IOR routines.
  IOR is not needed since each module.inp will have just a few variables,
  which are organized as in feff.inp, but in some fixed format:
    CARD  value1 value2 ..

  We understand that this is not a perfect solution for I/O structure, and
  would therefore appreciate some comments. Various I/O standards are being
  discussed for toolkit implementations, so we will probably change this structure
  sooner or later away from the current module.inp and/or module.bin in the future.

  2) Pass more variables (header lines, repetitive input data) through module.bin
  files. For example, the variable nph (number of different potentials) is set in
  the POT module, and passed to XSPH through pot.bin. From XSPH to FMS it will
  be passed through phase.bin, and so on until needed.

  3) Add README files in each directory of feff82/src/
  with basic information on the purpose of subroutines (program) in that directory.

  4) Each main subroutine(program) will have a generic structure; e.g.,

      subroutine genfmt
  c   program genfmt
  c   Description of the purpose.
  c   INPUT files
  c   OUTPUT files

     read module.inp
     read geom.dat (if needed)

     call genfmt(variable list)

  c   Description of the variable list and comments for code developers

B. Changes for feff8.20x6

   Implement new FMS algorithms:

  1) Implement efficient memory matrix inversion algorithm
     with recursion and Broyden methods for FMS

  2) Make a card for swithching between various FMS
     algorithms (the analog of the undocumented FMSTUNE card).

  3) Add MULTIPOLES card (code can already calculate elec.dip.,
     elec. quad. and mag.dip. transitions)

C. Release version of a monolithic feff8.20 code

  1) The advantages of modular code - the code needs less memory,
  but there is big disadvantage: it needs  run scripts for
  every possible machine (=>portability problem). Also we found our
  UNIX scripts unsatisfactory, since it is currently too primitive,
  and several times John and I were running code which was not in the
  right directory, and wondering e.g. I just fixed the bug, why does it show
  up again? Our UNIX script also disabled the CFAVERAGE card, which is
  used by several researchers (e.g. Farrel Lytle, Steve Wasserman)
  Also the 8.1 document would need fewer changes for release,
  as well as simpler installation instructions.
  

  Thus we want to make possible building a monolithic version of 8.2 (like 8.1)
  i.e. use feff8.1 feff.f main program

      program feff
      call ffread(nabs)
      call ffmod1
      call ffmod2
      do 900 iabs = 1, nabs
c        sort atoms for 'configuration average' according to absorber
         call ffsort (iabs)
         call ffmod3
         call ffmod4
         call ffmod5
         call ffmod6 (iabs)
  900 continue
      call wlog (' Feff done.  Have a nice day.')
      stop
      end

  Ideally, the change from modular to monolithic code can be handled
  with a Makefile: e.g. 'Make mono' could, for example, 
  concatenate all .f files in all directories, but would also need some
  script to read monolithic code and comment out lines program ffmod?
  and uncomment line below: e.g.
  c    subroutine ffmod6 ( iabs)
  Neither John nor I knows how to write such automatic scripts well. We would
  therefore like to have some help with that. Lacking that, we will have to be content
  with less automatic versions.  However, it will be advantageous for all
  developers to have it automated. 


  2) run test-suite on various platforms (e.g., SGI, LINUX gnu, pgf77, compaq,
     AIX, HP, and WIN-NT; sequential and MPI versions when possible.)
     These tests can/should be semi-automated, at least on unix boxes.

  3) update Feff8 document

We  estimate approximately 1 month for every version (8.20x5, 8.20x6, 8.20),
but this can be off by a factor of 2.

D)  Modular code and dynamic memory allocation will be goals for future versions.
We have had interesting discussions on a 'toolkit' approach to modular coding for
high performance computers with Stocks group (from ORNL) during the March meeting. 
The multiple scattering codes are good prototypes for this, and it appears that the
FMS codes in FEFF8 and Stocks LSMS codes can be constructed from rather similar
toolkit modules.  Of course, real advantages would come from the use of LSMS tools
in feff and vice versa.
Stocks group has a number of excellent computer scientists, so FEFF will likely
be able to benefit from their expertise, and vice versa. It will be important to
consider and test various I/O standards for this work. For example, it could be
useful to enable compatibility with XML format in the future.

Sincerely,
Alex Ankudinov
Research Assistant Professor

Lead FEFF8 Developer