[Ifeffit] Possible bug in atoms files generation by Artemis

[Matthew Marcus]

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 <mamarcus at lbl.gov> 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-electron system.  So, yes, in principle one needs to
> know the dielectric function.  That's conceivable for Cu metal, and
> maybe an ion in an aqueous solution, but not so much for lots of
> systems really studied.  Still, if you think that a single-pole model
> works pretty well (the current normal implementation of the
> self-energy), perhaps a mediocre dielectric response function (say,
> treating 'iron oxides' as all more or less the same) would be an
> improvement.
>
>> One thing I do is to use experimental data from models as sources of
>> amplitudes and phases.  At present, I do this using my own
>> multishell fit program.  Is there an easy way to do this in your programs?
>> What I think would be nice is a subsystem which allows one
>> to do the filtering and extraction of amp and phase from a model .chi file
>> from within the program, rather than having to create
>> FEFF-path-like files.
>
> Creating a model "Path" from experimental data is definitely possible,
> but not conveniently encapsulated in Larch -- it would not be hard to
> do, and is a fine idea.  It's now on the to-do list.  In years past,
> Anatoly has done similar things by making "fake feff.dat files" and
> using them in Feffit.  It can work, but it should be made easier.
>
>> As long as we're talking wish-list, I'd love to have some way of defining
>> atom positions using symbolic variables and have the system
>> compute the path distances automatically as functions of those variables.
>> That way, I could, for instance, define a dopant system in terms
>> of the displacements of the near-neighbors without having to do the geometry
>> by hand, which is difficult, tedious and error-prone.
>>          mam
>
> Oh yes, this is a major motivation for wanting to replace the
> PathFinder with a version that was reversible (ie, which atoms in the
> cluster correspond to this structure, and vice versa) and for wanting
> to move the GenerateFeff_MuffinTin(Potentials, Path) into the fitting
> loop.   Ultimately, we'd like to replace the sum-over-paths with a
> sum-over-atoms-in-a-cluster, where the x,y,z coordinates would be the
> variables.    I think it's completely possible, though a fair amount
> of work.   Probably needs a person to really dedicate some serious
> time to it...  Sorry to sound like a broken record, but if anyone is
> interested in this, let me know.
>
> Cheers,
>
> --Matt
> _______________________________________________
> Ifeffit mailing list
> Ifeffit at millenia.cars.aps.anl.gov
> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
>