[Ifeffit] Connecting Artemis to FEFF9.6.4

[Matt Newville]

 Hi Kevin,

On Sat, Jan 11, 2014 at 11:01 PM, Kevin Jorissen
<kevinjorissenpdx at gmail.com> wrote:
> Hi Bao and Bruce,
>
> There has indeed been progress since FEFF6 -- the newer versions of the
> program have new input options that the old program will not recognize.
> E.g., as described in the post Bruce linked to, we now generally use the
> EDGE card rather than the HOLE card to specify the absorption edge.  However
> the HOLE card is still recognized by the current FEFF9.  Someone mentioned
> FEFF breaking support for older input files.  To the contrary I expect FEFF6
> input files to work smoothly with the FEFF9 code.  E.g. the Cu example in
> the FEFF6 distribution works with today's FEFF9.  FEFF6 and FEFF9 may
> produce somewhat different output for the same input file because some
> internal defaults and algorithms have changed.

Bruce's complaint was not that changes gave no improvements in the
input file, but that he had no control over or even notification of
such changes.  Artemis generates an input file for Feff.  It needs to
be concerned with things like the spelling and order of keywords.   If
these change between versions, Artemis has to be changed accommodate
these changes.   So, when someone asks the seemingly reasonable
question of "Can I use the brand new shiny Feff X.Y.Z with Artemis",
the answer has to be "maybe".

Not only does Bruce not get a patch for Artemis to read Feff.inp for a
particular version, he does not even get a list of changes made, let
alone an advance copy for testing.   We often first hear of version
X.Y.Z when someone asks such a question on the list.  Honestly, I have
no idea what went into versions 9.0 through 9.5.   The first version
of Feff9 I ever saw run was in June 2013.  I don't know which versions
Bruce might have seen, but I believe he is similarly unfamiliar with
the Feff9 series.

It's OK if you want us to not be well-informed of these changes, but
you can't blame Bruce when he tells Artemis users that he really no
way to know if Artemis will work with the latest version of Feff.
You *could* tell Bruce what has changed in new versions, and/or give
him a copy to test.  You do neither.  It's not like this is the first
time this has happened or been discussed.

> FEFF9 is not meant to be run through the GUI exclusively.

You mean JFEFF?   In this context, most people do run Feff through
Artemis.  It actually pre-dates JFEFF by a number of years.

> Many users
> (myself included) love working from the command line, and that will always
> be 100% supported.  The GUI is just another way to control the input file
> and run the same compiled fortran executables.   Occasional users and users
> unfamiliar with the command-line terminal (the majority of our users work in
> a Windows environment) seem fairly happy with it.  But you can always do the
> same thing by typing "feff" on the command line.

OK, that's fine.

> Our interface still consists of a single text file with 10-20 lines of
> keywords with options; and then a list of x,y,z coordinates.  It's kind of
> old-fashioned; if something fancier is needed, I'm willing to help or
> translate it or show interested parties the code.

Bruce and I have been begging for improved i/o for ten or fifteen
years now.   I don't know what you consider fancy, but we desperately
need the routines that callable from other programs, with an API and
not a monolithic  input file.  Any help from anyone would be greatly
appreciated.

> On to the physics:
>
> I indeed expect that the improved self-energy (we call it MPSE, for
> Many-Pole Self-Energy) would improve EXAFS for many (not all) materials by
> shifting peak positions and correcting broadening.  Other improvements might
> come from new options for Debye-Waller factors, TDLDA, or self-consistent
> SCF potentials (I think some on this mailing may have questioned the value
> of SCF potentials).  The thread referenced by Bruce asks how well one would
> have to know the dielectric function of a material (that in itself may not
> be known very precisely) in order to get an advantage from the MPSE.  In my
> own calculations a primitive built-in model requiring no knowledge from the
> user already seems to provide some of the improvement.  It's not a
> conclusive answer, but it's encouraging.  My personal opinion is that the
> dielectric function does not need to be provided with high accuracy.  Josh
> Kas may be able to make a more qualified statement.

Sure, we all expect MPSE to be an improvement even with a simplistic
improvement to 1/epsilon.  The question is "how much of an
improvement"?    I'm not aware of any further tests beyond copper
metal from 5 years ago. At that time, my recollection is that Josh had
to run code to generate the exchange potentials. But now (as of a few
days) that we have the code for Feff85-for-EXAFS, and can start
getting to the point where we can run these tests.  It will be some
work to get there.

So, we will be able to get to a stable, distributable version of
Feff8, and that will give Bruce an input format to support.  Still,
people will come along and say, "I just got Feff X.Y.Z, can I use
that?"    I believe the correct answer should be No. Once Feff8 is
included with Larch and Demeter, any developments for EXAFS should
occur in the open source version, and we can simply refuse to support
other versions.  Personally, I think we should change the structure of
the input file(s), so that Feff85-for-EXAFS is not remotely like other
versions.

> Like Bruce, I would be delighted to see a comprehensive study done.  It's
> certainly on our minds and if anyone else has plans in this direction, I'm
> sure we would be glad to support the effort.

Again, we're just now ready to think about getting to a point where
reliable, verifiable testing can be done.   And, yes, free code
matters for testing because its the only way to guarantee that even
Bruce and I (and, without loss of generality, Matthew Marcus or Scott
Calvin or ...) were running the same code.  With the old license, I
could not give Bruce or anyone else a copy of any change I made to
Feff8.   There were no way to make changes or fix bugs except to
expect that someone in the Feff Project will decide to fix them.   Of
course, this is still the case for Feff9.  It is completely
counter-productive to testing and verifying code.  It is not only
unscientific, it is anti-scientific.   I'm willing to be believe this
is not your conscious choice, but the effect is independent of your
intentions.  Just to be clear, we asked for a Free Feff8-for-EXAFS
because we had given up pestering you for a truly open source model
for Feff development.   We would MUCH rather see Feff be truly open
source and with an open development model.

> Finally ...  Reading the referenced thread, I feel the need to clarify a few
> things about the FEFF group...  We care a lot about our users and in
> particular about this community.  It's a priority to make our codes useful
> to this community as well as the wider FEFF community.  Personally I spend
> loads of time responding to questions, testing other people's input files,
> implementing requests, teaching, ... and wishing I had more time to
> implement all the remaining things I would like to provide! -- just like
> Matt or Bruce.  I invite everyone to contact me with any FEFF requests that
> would benefit users, or to include me in ongoing developments.  And to end
> on a cheerful note, I can happily report that FEFF8 for ifeffit EXAFS
> analysis is ready to be given out!

OK, that's fine.  No one is saying that you don't support Feff.  We
are saying that *we* can't support Feff very  well.  Yes, we're also
saying that this is due in large part because of the choice the Feff
Project has made to not work with us, and to prevent us from working
on Feff.   Whether that is intentional is separate from the actual
effect of the Feff license.

I think most everything said in that thread (from March 2013) is still true.

Cheers,

--Matt