[Ifeffit] Ifeffit development tools?

[Matt Newville]

On Nov 20, 2007 8:13 AM, Webb, Adam <adamwebb at win.desy.de> wrote:
> Greetings,
>
> > 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?
> >
>
> I second the idea. A -dev list would also help avoid confusion. I can
> see that people might get really confused if one set of people are
> talking about some software in development and other people are talking
> about the program that people are using.
>

Agreed.  I will set up a devel list  (it may be a couple weeks).   The docs for
development should also be improved.

> For example, a plugin like structure might be used. Someone adding a new
> function could for example write a plugin to do something like:
>         1. ask ifeffit for data and other needed information
>         2. do some tranform/filter/magic on data
>         3. return data to ifeffit
> Other people could use plugin by calling it from within ifeffit. You can
> do this now with the wrappers but it appears to me that this might be
> easier to do with tdl and/or demeter as these things seem better
> designed to do just that. Perhaps Matt or Bruce would like to comment
> further.

As Bruce said, with the simple interfaces to Ifeffit from C/perl/python/tcl,
one can do the steps you outline, though they are perhaps at a lower
level than would be desirable.

One important missing item is that these interfaces only go to the base
library, and cannot connect to other libraries built on top of it.  While a
python script can call ifeffit, it cannot call Demeter or Hephaestus.  If
the idea is to use the ifeffit library for core XAFS functionality, this is not
a terrible approach, but it does have serious drawbacks if the goal is a
more comprehensive and extensible set of tools.

I think the problem is challenging but solvable.  With TDL, it will be much
easier to add functionality "to the core" -- as any python module can be
exposed to TDL.  But that doesn't solve all the problems, specifically the
cases where one would want to use procedures coded in a language
such as Perl or Java or Mathematica (ie, anything other than C, Fortran,
or Python), which Python cannot readily use.

And that, I think, may be a part of what both you and Mauro are struggling
with.  You'd like to use some "core functionality", but hopefully wrapped up
at a higher level as Demeter is, and perhaps some other libraries (DFT,
processing reflectivity data, etc) that may be implemented in a different
language.   At some point, we're going to have to figure out how to avoid
these language conflicts.  Again there are ways to solve them, but we haven't
gotten there yet.

I've struggled with this too.  I have some of Hephaestus' capabilities
in Python,
but by no means all of them.  I've been reluctant to re-code it all in
Python, but
at some point I might break down and do this.  Personally, I'd love to have a
web-based Hephaestus, with a documented API, so that I could get the data.

--Matt