Skip to content

Goals of the feff85exafs project

Bruce Ravel edited this page Feb 11, 2015 · 8 revisions

The feff85exafs project aims to provide high quality theoretical standards for EXAFS analysis within an open source, freely re-distributable framework.

We started with a copy of Feff 8.5 donated by The Feff Project which had most of the code for XANES and other spectroscopies stripped out. What remained was the code for self-consistent potentials, the pathfinder, and the code for computing and writing the components of F_eff.

To make Feff more attractive for developers of EXAFS analysis software, we want to move beyond a model where Feff is run by making a system call to a compiled program which uses quirky, ill-defined files for its input and output structure. We want to package the principle components of Feff into libraries that can be compiled against programs written in Fortran, C, or C++ or wrapped for use by interpreted languages such as Python, Perl, Ruby, and others.

To this end, these are the goals that we have been working towards:

Goals

  1. Build the components of Feff using a robust, extensible, well-tested, well-supported, cross-platform build system. The build system should manage both the compilation of Feff as conventional executable components and as libraries for use as described above. We have adopted the SCons software construction tool. This is somewhat complete. It works well on linux, has been tested Mac, and is partially implemented on Windows.

  2. Clean up existing code so that it compiles with few or no warnings, even with the compiler instructed to issue a high level of warnings. The code should also be cleaned up such that it triggers no memory usage warnings when programs are run using a memory checking tool such as Valgrind. Where possible, replace the use of common blocks with long argument lists. This makes it easier to develop C wrappers for the components of Feff. Substantial progress has been made, but work remains.

  3. Combine the roles of the POT and XSPH components of Feff into a single stand-alone library which, given the data contained in the feff.inp file, produces a file with potentials data which can be used to compute individual scattering paths. This has not been started.

  4. Combine the roles of the GENFMT and FF2X components of Feff into a single stand-alone library which, given the results of a potentials calculation and the Cartesian coordinates of the atoms in a scattering path, computes F_eff and returns the data table of contained in Feff's feffNNNN.dat file. This is largely complete.

  5. For each of the stand-alone libraries, provide an entry point in the form of a file of Fortran code which can be compiled into a shared library. For each of these Fortran entry points, provide a wrapper library written in C which can be compiled directly against programs written in C or C++. For each of these C wrappers, provide interfaces for Python, Perl, and possibly other languages so that the components of Feff are directly accessible to programs written in those languages. This is largely complete for the GENFMT/FF2X interface, but needs testing and development of wrappers.

  6. Provide a robust unit testing system to validate changes made to the code. This framework is based upon Feff's output being compared to calculations made using the code in the state it was in when delivered by The Feff Project. This unit testing framework uses Larch and Python's nose unit testing framework. The set of tests is quite comprehensive, involving Feff calculations on several material systems and extensive checks against various parts of Feff's outputs. The current test suite includes over 1400 individual tests. Running the test suite frequently against feff85exafs as it is developed guards against many kinds of mistakes from entering the code. This is partially complete, fully tested on linux, partially on Mac, not at all on Windows.

  7. Provide a useful, extensible fit testing framework to evaluate the effect of "things" on the quality of the EXAFS analysis. Examples of "things" to be tested are (1) self-consistency in the evaluation of the potential, (2) the choice of the k-grid used to save F_eff (see issue #25), (3) the choice of the IORDER parameter, (4) the choice of potential and self-energy models, and so on. Basically, if features are added to feff85exafs, this fit testing framework can be used to evaluate their use and effectiveness. Bruce has been working on this -- specifically looking into the effect of SCF -- but has not yet folded it into this repository.

Clone this wiki locally