Hi Mauro, Thanks for the questions and comments. The short answer is that there currently are not very good 'development tools' for Ifeffit. This should change, and I'm happy that you (and several others) are interested in such things. I'm not sure how fast this will happen. The conversation between you and Bruce brings up several points. I'd like to touch on all of them, but one email may not be enough. Right now I'm in the midst of a long run of user-support, so I don't quite have the time to give these the attention they deserve. I do think an ifeffit-dev list and/or wiki area is a fine idea. I don't know how many others would be interested in this, but it might allow for more open development, and keep the ifeffit mailing list more for usage questions. Any other opinions on this? Mauro Rovezzi wrote:
For these reasons I would like to know your point of view on the idea to find a standard in the creation of Ifeffit applications in order to permit the interested community to contribute/share in the programming effort. Practically speaking, if someone would like to implement a new functionality based on the Ifeffit library which directives should follow to integrate the existing applications?
I think this depends on the application it is intended to be integrated with. As you know, the current model for Ifeffit applications is a "core library" which provides (most of) the basic XAFS functions and also provides a "user session" in which a user reads in and acts on data. The idea is to build applications on top of that library. It's served well, but it does suffer somewhat in that a) the "core library" is in Fortran, which is good for the basic XAFS functionality part, but poor for the "session" part -- sadly it is not easy to completely disentangle these in the current library. b) it is difficult to add new functionality to the core library. c) as with any "session" program (ftp, matlab), the session part really ends up being limited by the scripting language provided to the user. The Ifeffit "language" is not very rich, is pretty quirky. d) applications built on top of the library have not easy way to interact with one another (SixPack cannot call Hephaestus). I'd say these ares design flaws, but will be charitable and say that we did OK considering where we started.
TDL? Why creating a new language instead of using Python directly? Well, in any case TDL will be Python-compatible and this is (very) good in my point of view. I appreciate the Python-oriented Ifeffit 2.
Well, now that question (TDL?? Are you nuts??) is a fine and fair question, and one I've been asked before and in fact ask myself on a regular basis. I'll try At this point my general answer goes like this: First, the goal is somewhat larger than an XAFS analysis program. Ifeffit got away with a stinky-little-language implemented in Fortran, but for anything more serious, a more complete scripting language is needed. At the same time, I want a decent mini-language for data collection and for dealing with non-XAFS data too, just as you want to work with DFT calcs and data and analysis "not quite" supported by ifeffit. There are, admittedly, many good scripting languages out there. I'm particularly fond of Python, but I don't think that having Ifeffit2.0 use Python itself would be very good. We need something more domain-specific, with proper numerical arrays and operations that act on them. But having Ifeffit 2 being *implemented* in Python is another story -- and the current plan. This will need a "tiny domain-specific language with strong support for handling array data, name spaces for grouping data, a complete set of loops, conditionals, and functions, and be extensible". TDL is an attempt at that language, and seems close enough to use as a working model. All that said, I have not made much progress on any of this in recent months. Cheers, --Matt