Hi Kevin, On Sat, Jan 11, 2014 at 11:01 PM, Kevin Jorissen 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