Feff development

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

Hi All,

Thanks for the mailing list, and if I might stick my foot in the
middle of the fray about Atoms ...

On Tue, 30 Jan 2001 John J. Rehr wrote:

> br>  jjr> Would you agree that it's also desirable to add atoms to the
> br>  jjr> list (I think FEFF would benefit from that)?
> br>
> br> Ummm... no.  I agree neither with the main sentence nor with the
> br> parenthetical.
> br>
> br> I am confused why you think that is desirable.  It seems at odds with
> br> the notion of the pathfinder, genfmt, et al. as
> br> functions/modules/libraries/whatever.  You still seem to imagine FEFF
> br> as one big calculation.  Fine, but that is not the way I see it, nor,
>
>   Au contraire.  For analysis purposes I agree with your thinking. We will
> leave the ball and stick display etc to you. And no, I don't imagine FEFF
> as always one big calculation with a monolithic code. Nor is FEFF always used
> in an analysis mode. What we all are looking for is flexibility to design
> various codes.
>
>   For, example, if I want *only* to make an electronic structure code for
> *crystals* to compare say with LAPW, then I mostly need the stuff in the
> first module, plus atoms.  Indeed, all modern electronic structure codes
> contain crystallographic functionality, and they don't need the overhead of
> a GUI. All one needs in this case is subroutine that calls
> atoms(crystallographic parameters) and yields a list of positions and
> atomic numbers for the crystal structure (e.g. in the geom.dat file). The
> two representations of the structure are essentially equivalent, and it's
> superfluous to make a huge list of coordinates when a few crystallographic
> coordinates suffice.  Of course, one also needs the option to read in a set
> of aperiodic coordinates for general structures in a real space code. Right
> now we're constrained to the latter.
>
>   What's wrong with this argument? It seems to me to be parallel to the
> argument you and matt are making for turning the various FEFF modules into
> subroutines.  At least that's how I intended it!  There is also a
> reciprocity issue here.
>
> br> It seems to me that generating coordinates is an issue for the
> br> interface to the toolbox.  I said that crystallographic interpretation
>    In general I agree.
>    But sometimes one wants a stand alone code, with no fancy interface.
>    Doesn't that make sense too?

I think John has a convincing argument here.  If the idea is a toolkit (as
opposed to just a more convenient interface for Feff), then working with many
possible calculations goals is important.  In that case, a function to do
space-group -> atomic cluster / P1 / overfull unit cell / etc would be a useful
part of the toolkit.

One might argue that since this calculation is very fast and not done very
often, putting it in "the high level front-end" is preferrable to having it
"in the core".  I'm not entirely sure.  Certainly, if it's in the
front-end, then it won't be run very often. But if it is in the core, it
might make it easier to step through unit cell parameters or cell positions
and recalculate XAFS paths, |F*F| for mildly forbidden reflections, or seed
configuration of an MD calculation.  Yes, this could all be done from the
"high level front-end", but if it's in the core, then anyone can use it,
even those who aren't using a particular high level front-end.

That brings up a question of how to decide what goes "in the core library"
and what is left for high-level wrapper routines.  I've certainly struggled
with this for Ifeffit.  The convential wisdom of the scripting language
camp is to start with as little as possible in the core and have as much as
possible in the high-level wrapper.  Then, as time and the library evolves,
be willing to put the really important bits (or the bits really in need of
speed) back in the core.  A reasonable counter-argument is that, unless
you're willing to commit to (and enforce) the use of a single scripting
language, then _everything_ should be in the core library.  If (on the
other other-hand), you _are_ willing to commit to a single scripting
language, then you can have lots of stuff in the wrapper routines including
most file and system i/o, parameter parsing and management, etc.  At this
point, I wouldn't advocate enforcing a single scripting language, but I'd
be willing to consider it.

In short, I think an 'atoms()'-like function would be a useful part of a
solid-state toolkit, though I don't think it would be the highest priority.
That assumes a solid-state toolkit is the working model, of course.  Since
this new mailing list suggests that development will be a fairly open affair,
it might be good to first come to some basic idea of what the goals for Feff
development (and this list) are, and how to sort out issues like this.

Thanks,

--Matt