Plan

Development Plan for 2015

Now that we have successfully re-factored GENFMT and FF2X to make a callable, stand-alone version of GENFMT for use by analysis programs, it is time to make a plan for finishing the job of preparing feff85exafs for future use.

It would be useful to make GitHub milestones for everything on this list.

The following are chores of vastly different sizes.

They are presented, more or less, in the order of priority.

1. Re-factor POT and XSPH into a stand-alone potentials calculator with a C interface that can be used for language wrappers.

2. Rationalize the structure of the intermediate files that are used to pass information between the portions of the code. A well-defined, fully documented, single JSON file that all the different bits read to and write from would be a vast improvement on the current mess of tiny, arbitrarily structured files.

3. Modify the stand-alone RDINP program to write to newly defined JSON file. Provide a library with a C wrapper for converting between the JSON and a feff.inp. These are required for backwards compatibility. The "official" policy should be to encourage software authors to interact with the JSON file and to never use the feff.inp file.

4. Write feffNNNN.dat and others as XDI.

5. HDF5 output options for phases. That is, an option to store one or more phase calculations in an HDF5 file. This will require incorporating Fortran HDF5 support into the build system.

6. Stand-alone, callable pathfinder library with a C wrapper. This would use the newly defined JSON file. That said, the Fortran pathfinder is a dead-end. It is missing essential features, all of which would be a challenge to implement in Fortran. Software authors should be encourage to implement a more feature-full pathfinder (i.e. fuzzy degeneracy and memory of degenerate geometries) in their native language.

7. The build system needs extensive testing on different platforms and with different compilers.

8. Solicit more wrappers. What language are popular packages written in? Viper? WinXAS? etc

---

Matt's Comments (28-Apr-2015)

I think adding JSON or HDF5 would require F95 or later which could complicate support, though I really have no experience with these. But I think it re-iterates the point that we should figure out who or what the target audience is.

Personally, I don't actually intend to use Feff from Fortran, I just want callable libraries that can be used. So, I don't actually need it to do any I/O at all (I don't particularly want it to do I/O, and certainly do not want to have to maintain I/O in Fortran), I want to be able to pass in data arrays and get back data arrays. If the Feff interface was valid F77 that would be even better -- I know that will work.

So, while XDI is certainly better than feffNNNN.dat, and JSON is certainly better than feff.inp, and HDF5 is certainly better that phase.pad or phase.bin, I would live to see a lot less disk i/o from Fortran, and prefer long argument lists. I think none of the argument lists for the individual functions would be that long by themselves, especially if we can eliminate the concept of RDINP as a module. That way the I/O is handled entirely by the calling program (C, Perl, Python, whatever)...

I think my edits here might be incomplete.... Hopefully more later.