Re: User interface, client/server issues, and FEFF

[Matt Newville <newville@cars.uchicago.edu>]

Hi Bruce,

I read through most of Bruce's "white pages" and Chuck's recent
email and parallelization, and have a few comments and questions.
The client/server idea is interesting for large XANES calculation,
but I view that as only one possible front-ends to the set of
calculations currently called Feff.  I don't see a client/server
model as being especially appropriate for EXAFS calculations.

A client/server approach requires a) a server, and b) a program
(say, FEFF) running on that server.  Is the idea that a single
server be available for everyone in the world to run feff on?  Who
would pay for/maintain this?  Or is it expected that several groups
would set up Feff servers themselves with their own money?  There's
also a serious issue of who's going to do (and fund) this work, and
if it really is part of a 'Feff' program , a solid-state toolkit or
some front-end to one of these.

Despite the great work on parallelization, I might challenge the
idea the Feff8.00 is way ahead of hardware.  Feff8.0 runs on my
*home* machine, which happens to spend most of it's time idle and
could certainly be running batch jobs all day long if I wasn't so
lazy.  OK, XANES calculations with 400 atoms take time.  Unless your
research topic is XANES calculations (as opposed to using XANES
and/or EXAFS as one part of a chemical/physical characterization of
the system you're really working on), paying $US20K for a small
cluster (and $US5K to pay someone to set it up) doesn't seem likely,
especially if you can get a result from overnight runs on a desktop.
For that $US25K, you could get a high-end desktop and a lot of
beamtime to measure experimental standards.

Within the client/server model proposed, I don't fully understand
why the 'server', 'parser', and 'program' are all separate.  Why not
have a single program to open up a socket, listen for requests, and
do the calculation?  I'm also unsure about the use of XML.  I see
the advantage of XML is that many applications can handle the data
in the file as a data structure.  But unless many different client
programs need to exchange data with one another (and not just to a
single server), it mat not be an improvement of a simpler input
structure of, say, keyword/values in plain ASCII.  The disadvantages
of XML (overly verbose, difficult to use without pre-existing
library) seem large.  I don't have a strong objection to XML, but
can you say anything about why XML is right for this application?

Again, client/server and the whole of Bruce's proposal is fine with
me, but it's definitely not the only way to use Feff.  I'd prefer to
see effort put into a library with a simple API so that people can
'embed FEFF' into their own MD, XPS, EELS, and EXAFS Analysis codes.
I'd want programs or scripts to run on a local machine, but some of
these scripts/programs could use a client/server model too.  Unless
I really need a remote server, I do not want a 'wrapper program' to
generate a feff.inp, then run feff, and then read the results
packaged and sent back so I can read it into my analysis program.
I want one program that does the Feff calculation and analysis in
real time, at the beamline.

When-it-comes-to-Feff-I'm-definitely-a-novice,

--Matt Newville