Re: towards feff8.2 release

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

Hi Matt,

You raise very important questions. It's a pity you did not come
to the meeting with Stock's groop. I think you could greatly contribute
to discussion of Toolkit development.

On Thu, 22 Mar 2001, Matt Newville wrote:

> The larger picture is not very clear to me.  I missed the
> 'Toolkit' meeting in Seattle, and am not sure what you or John
> mean by 'Toolkit' or 'Modular Code'.

I think programmers in Stock's groop a better software engineers than me.
So I will just cite below from their Rationale towards a topical center
in Computational Material Science (CMS-TC). 
"the CMS-TC is not simply envisioned as collection of the existing
monolithic codes in high performance machines. Rather, it is a properly
software engineered collection of elements that collectively comprise a
tool set whose components can be rapidly assembled into codes to solve
complex problems."
" In the field such as CMS, where the science - as well as the mathematics
to describe it - is still under active development, the complete
understanding of the general problem is missing. (A.A. this is the
main contrast between feff and atoms) In such field frameworks
(A.A. monolithic codes) face the problem that they are outlived by the
time they are implemented, and researchers as well as HPC (high
performance computing) center personnel face a daunting task of overcoming
short software lifetime."
 (A.A. look at feff project. I am working on feff9 to include
nonsperical potential. We just released feff8.1 but still did not
release feff8.2.)
" Most existing CMS codes are simply frameworks because the high level
tool sets that are needed for CMS are almost impossible to develop within
traditional programming languages. However with the recent standardization
of C++ and compilers that support the full ANSI standard, object oriented
and generic programming techniques can be used to implement the high-level
tool-set needed for CMS."

I hope above citations may serve as a reasonble definition of Tool-set.
Individual tool is not a single subroutine, but rather a set of them
to perform one big task: e.g. solve Dirac equation for single cell
given potential, calculated self-energy given electron density, and so on.
The idea is first to break feff and LSMS (Stock's) code into tools.
Our tools should have a reasonble overlap, since both codes are
based on Multiple Scattering Theory, but will have nonoverlapping
tools. E.g. feff will have tools to calculate various spectroscopies,
while LSMS will have tools to deal with spin dynamics, and to handle
semiinfinite systems, etc..
Special tools will be written for pre/post-processing ( more general
than GUI). "there is a need for systems in which all these computational
components are linked, so that all aspects of the modeling and simulation
process can be controlled graphically within the context of an integrated
computational environment. Such and environment is refered to as a
problem-solving environment (PSE). A PSE is a complete, integrated
software environment for the computational solution of a particular
problem, or class of related problems."
E.g. feff and LSMS PSE will slightly differ in details, but
will be build from the same tools, and thus will look similar for users.
"Our plan is to build a computational environment or PSE specifically
tailored for CMS, using existing industry standard software. For example,
we might use Java 2.0 / Jave Beans for the client/server PSE ..."

 > I also do not understand
 > how you define 'developers' compared to 'users'.  Could you
> list the developers, and say what it means to be a developer?
 We typically define users those who use released products.
 The 'developers' probably include people who do real code
 writing ( latest coding was done by me, Alexei Nesvizhskii (rho_0/mu_0),
 Jim Sims (parallel staff), and Matt Newville (Makefiles, and some tools
to manipulate with the code, Packed ASCI format for .bin files),
Bruce Ravel (several input/output ideas)). But I think 'developers' also
include 'beta-testers'; i.e. people who use bugsy code before release and
greatly help us to find bugs. The most of testing work is currently done
by John Rehr, who test the code even before it goes to other beta-testers,
Probably, John can give a complete list of beta-testers.
> 
> It is unclear to me what role you and John see for developers
> outside UW Physics.  Do you want development open to anyone or
> 'invited collaborators' only?  You mention that Stocks' group
> at ORNL has people from whom Feff will likely benefit. How is
> this possible collaboration going to be implemented?  How do
> you plan to share and distribute the intellectual property
> generated from such a collaboration?
> 
> I don't see much in the Feff Project that encourages people to
> join in the development process.  I see (and have personally
> experienced) the opposite.  While claiming you want outside
> help, the contributions and suggestions given to you in the
> past have been routinely ignored and undervalued. Makefiles and
> scripts to help compile and run Feff and contributions to Feff
> code have been written and donated.  The Feff Project has
> chosen to ignore a substantial portion of this work.  It has
> steadfastly refused to use an open development model and has
> stuck with an anti-intellectual license and distribution policy
> that greatly hinders outside collaboration.

  Yes feff is under UW OTT license. The license question also was 
discussed at the Tool-set meeting, since tools are intended for
the use by other people. The Stock's group want to run tool-set
under open source BSD or GPL license. They lean toward BSD, by some
conributors want to have it under GPL. However, the idea is that
all tools should under the same license, so that outside
developers should read it once for the whole tool-set.
> 
> And yet, the plan put forth now seems to DEPEND on work being
> done outside UW Physics.  I'm must say I'm impressed!  Of
> course you'd like volunteer help for your work.  Who wouldn't?
> We can all see that outside developers could help you.  The
> question is:  What do you have to offer outside developers?
> 
> A project like Feff is critically dependent on who is involved.
> I think you would do well to identify potential developers and
> get their feedback on what they would like to see and what they
> would want in return before you decide what is going to be done
> and ask for volunteers to do work that you want done but do not
> want to do yourselves.

  Most of outside development help and criticism we get from
Matt Newville and Bruce Ravel. So we would like to ask you first
what do you want in return. The steps toward open licence need to be 
done during the tool-set development anyhow. We still need to wait
to find out what license will be used for the tool-set. GUI development
is also a part of tool-set, so we don't want you to spend a lot of time
on developing special feff GUI. But I think both atoms and ifeffit
GUI can serve as a prototype for PSE in a toolkit. Or may be even
some elements from your programs can be used in a tool-set?

 It was my undesire to ask for volunteer help, that lead to
'disingeneous' decision to leave feff8.2 as a monolithic code.
The difference is only in 10 lines of the code, but the size
of executable and necessary memory will go up. I hope this is
only a temporary step back. The proposed tool-set seems the way to
go for the future developments.

Alex