Many years back, when FEFF stopped being free, I was told that the decision was
not Rehr's but forced by the university. Blame them.
It's always easier and more pleasant for us to blame faceless university
beauraucrats than scientists anyway :-)
I agree that FEFF input is broken. This was, perhaps, inevitable as FEFF
evolved over the years. It may be (I haven't studied the matter)
that the old format, which was perfectly good in its day, simply can't
accommodate new features just by adding new keywords. I really
can't blame the Project very much for changing the format. Still, the formats
are documented, so I don't buy the idea that nothing can be
done with FEFF8 until the Project changes its format or goes open-source. I
can understand a reluctance to go open-source because they
now keep tight control over portability and the embodied physics, such that
everybody knows exactly what 'we used FEFF8.4' means. If it
went open-source, it may be imagined that there'd be a proliferation of
versions, some of them with dubious hacks. One fix I could imagine
the Project doing is to release as open-source an input module for FEFF9, which
is broken up into separate modules anyway. That way, people
could have whatever input format they wanted, but the integrity of FEFF would
be preserved.
As to dielectric response, what is the effect of improving that model on EXAFS
predictions? Does it affect the self-energy, hence
lifetime broadening and E0? I knbow it affects XANES, but that's a whole other
subject not covered by DemLarchTemis discussions.
mam
mam
On 3/27/2013 7:32 PM, Matt Newville wrote:
Hi Matthew, Bruce,
On Wed, Mar 27, 2013 at 10:33 AM, Matthew Marcus wrote:
Some users do have FEFFx (x>6l) on their own, so it would be useful to
prepare Artemis/Demeter/Larch... for them and provide
methods for using higher versions if an executable is present.
I completely agree that this would be valuable, and that it's not
quite moot because many people do have Feff8 or Feff9 available to
them.
But, I also want to be clear that I totally agree with Bruce's point
on this as well. It's really hard to support code that is actually
poorly defined and cannot be changed. The Feff input file format is a
complete mess, and it's not Bruce's (or my) fault. In fact, this *is*
what the original question was about. Feff changed form one awful
form to another -- why is this Bruce's problem to solve? There is
no API or library provided for reading feff.inp. We are forbidden
from changing it or redistributing a changed version of Feff8. It
is, to be very clear, the choice of the Feff project to break these
input files.If we had a "Feff8 for EXAFS" that could be relied
upon and redistributed, it would be a totally different story. We
don't.
We've lobbied (begged) for changes in the i/o and freer access to the
code for many, many years. I can't explain the restrictions in any
rational terms, fathom why this restriction is a priority for John or
anyone else, or understand how anyone who writes scientific software
would use anything except an open-source license. I've given up on
pestering them about it. I was told last summer that a version of
Feff8 for EXAFS that we can distribute would be made, but haven't
heard a thing about it since. It could happen soon that would be
great. The license they use is their choice, and I respect that even
if I don't actually like their choice, and actually have real
reservations about the choice being solely theirs to make.
Ultimately, science will demand that all versions of Feff will be made
free or be forgotten. It is completely believable that Feff6L will be
what is used twenty years from now. I expect that Feff8 for XANES
calculations codes will never be made free and will be forgotten in
time.
I actually don't have a copy of Feff9. Kevin J did a great job with
JFEFF, and emulating or including this approach of using a remote
cluster in the analysis codes would be interesting to think about.
From a practical point of view, it would be easier to reproduce a
similar system than to have to argue about licensing. Then again,
without the calculation engine being freely available, running it on a
cluster actually seems like a problem... wouldn't you need a license
key or something? Right, sorry, the Feff license actually makes no
sense -- it's better to not think about this.
What does the multipole self-energy do? Is that the thing that requires the
dielectric response? As you point out, the purpose of
the exercise is to analyze unknowns, so by definition one doesn't have the
dielectric response. We can't expect a program that runs on
a PC to do a proper, all-electrons, excited-state calculation.
Yes, the multipole self-energy uses a better model for the self-energy
based on the dielectric response of the system in the low (electron)
energy regime -- in short, how a "free" photo-electron will travel
through the multi
