FEFF report: Hard tests failed in fovrg.

Naumova, Maria

6 Aug 2013 6 Aug '13

3:55 p.m.

Dear EXAFS people, I have a question that appeared in FEFF and IFEFFIT several times. Still I didn't get an answer. Here are some links to this question discussed or asked previously: http://cars9.uchicago.edu/feff/feffusers/msg00255.html http://www.mail-archive.com/ifeffit@millenia.cars.aps.anl.gov/msg02675.html http://www.mail-archive.com/ifeffit@millenia.cars.aps.anl.gov/msg01532.html http://millenia.cars.aps.anl.gov/pipermail/ifeffit/2005-October/002080.html I have EXAFS of several similar organic complexes - copper which has S, N and Hal (Cl or I), and sometimes copper in its first coordination shell and more C and N in ligands. I have structural data for them which I use as a model for FEFF. When I run FEFF via Artemis I get the following report for all my substances (I have 6 potentials in the list): Calculating potentials and phases... free atom potential and density for atom type 0 free atom potential and density for atom type 1 ...and so on... overlapped potential and density for unique potential 0 overlapped potential and density for unique potential 1 ...and so on... muffin tin radii and interstitial parameters phase shifts for unique potential 0 Hard tests failed in fovrg. Muffin-tin radius may be too large; coordination number too small. phase shifts for unique potential 1 Hard tests failed in fovrg. Muffin-tin radius may be too large; coordination number too small. ...and so on... Feff done. Have a nice day. In FEFF documentation I read the following: "To save time the code calculates the overlapped atom potential for each unique potential only once, using as a sample geometry the first atom in the atom list with a given unique potential index. Thus it is essential that the neighborhood of that sample atom be representative. Failure to do so may cause the code to perform poorly. " http://leonardo.phys.washington.edu/feff/Docs/feff6/feff6-4.html#pot I think that at least for copper and halogen or sulfur geometry of every atom in the atom list is representative. "Often we receive reports by users of older versions of FEFF of bugs that are fixed in the latest releases. Other code failures can often be traced to input file errors, sometimes quite subtle. An example would be non-physical widely spaced distributions of atoms. Symptoms of this common problem are very large muffin-tin radii (see the header of any .dat file) and possibly a failure of the phase-shift program to converge." http://millenia.cars.aps.anl.gov/pipermail/ifeffit/2005-October/002080.html Here the reason is explained. Since it's an organic complex local distances between neighrours are small, but distances between parts of molecule can be quite big. Still it's not "non-physical widely spaced distributions of atoms". For example distance from copper to the first shell is 2 - 2.3 A (2.6-2.7 to I and Cu). To the "second shell" (ligand atoms connected to the first shell atoms or not connected but close to central atom) - 2.9 - 3.4 A. Finally what I want to know: May I use this FEFF calculation as a valid base for future fit? Or this error means that FEFF doesn't work correct and I can't rely on its output? If the phase-shift program failed to converge does it mean that it could stop in some completely unrealistic result? I attach several FEFF inp files which have this problem. Thanks for your help, Maria Naumova PhD student in DESY

Attachments:

FEFFinp.tar.gz (application/x-gzip — 7.8 KB)

Show replies by date

Bruce Ravel

7 Aug 7 Aug

3:24 p.m.

On 08/06/2013 11:55 AM, Naumova, Maria wrote:

...

May I use this FEFF calculation as a valid base for future fit? Or this error means that FEFF doesn't work correct and I can't rely on its output? If the phase-shift program failed to converge does it mean that it could stop in some completely unrealistic result?

Maria, You are correct that the version of Feff6 that we are allowed to give away for free reliably complains about failing something called a "hard test". This is some kind of convergence test on the computation of the muffin tin potential. The test is made in the lines just prior to this: https://github.com/newville/ifeffit/blob/master/src/feff6/fovrg.f#L158 The error is reported here: https://github.com/newville/ifeffit/blob/master/src/feff6/phase.f#L127 If you can make heads to tails out of the calculation in fovrg.f, you are vastly smarter than me, vastly more patient than me, or both! I have 2 comments on the main point of your post: 1. As you noted, this question has been asked many times before. Not once has anyone from the Feff project (i.e. anyone who might actually have a working knowledge of that bit of code) bothered to comment. It would be lovely to hear from one of them. 2. This very version of Feff has been included with Ifeffit and with the packages I build for my software for years. Over a decade, in fact. In that time, Feff, Ifeffit, and my software have been used for defensible data analysis thousands of times and by hundreds of practitioners. That does not mean that any part of the software stack is actually correct. But it does mean that lots of article writers and lots of article reviewers have accepted the results coming from this stack of software. That does not mean that you should accept it. Quite the contrary -- you would be wise to question every part of the software stack. You may even find that you will need to discard any or all parts of that software stack and replace them with something you trust more -- perhaps even with something that you, yourself have written. To summarize, I am saying the same thing I have said in the past. I don't understand the code that generates that message. No one from the Feff project has ever bothered weighing in on what it means. No one has demonstrated that it represents an actionable problem. The codes which use Feff have been in use for years to produce defensible science. So, in conclusion, what should you do? I have no idea. My advice is to continue using the software, but my advice may not be any more reliable than the software itself. I hope that helps. Probably doesn't, but it's the best I can do. B -- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel

Kevin Jorissen

6:29 p.m.

Dear Ifeffit community, a short reaction from the FEFFgroup. 1/ It's true that we don't follow up on the ifeffit ML 100%. Important issues usually do get through to us. We highly value the ifeffit community. We can also be contacted directly for problems that are FEFF related rather than iFEFFit related ( contacthttp://www.feffproject.org/feffproject-contact.html ). We'll likely ask you for the feff.inp file that generates the problem. 2/ We're glad that FEFF6 is so successful. Meanwhile FEFF6 is about as old as Windows95, and development is now focused on FEFF9http://www.feffproject.org/feffproject-feff.html, which has 15-20 years of improvements over FEFF6. It's a big improvement for anyone running FEFF calculations. It costs $500, or $250 upgrade from any paid version of FEFF. 3/ The OP posted 5 input files. 4 of these run without problems in FEFF9. The last has I atoms (Z=53) at a spacing of 0.8A, and doesn't run out of the box. I expect the same result from FEFF8. 4/ There has been some effort to bring a "FEFF9lite" to the analysis codes, analogous to the FEFF6lite discussed here. We would be very happy to see that effort succeed. 5/ FWIW the fovrg routine was retired in 1996 and replaced by a relativistic version called "dfovrg". The "hard error" does not exist anymore. 6/ We're a small team; we apologize for all the 'bothering' we don't get around to. We do care about supporting our users and put a lot of energy into support. Please reach out ot us when you need us. Cheers from Seattle, Kevin Jorissen PS I posted a while back about a problem with JFEFF and Java updates but I'm not sure the message made it through: I asked the mod, but no reply. I hope this msg makes it :). On Wed, Aug 7, 2013 at 8:24 AM, Bruce Ravel wrote:

...

On 08/06/2013 11:55 AM, Naumova, Maria wrote:

...
May I use this FEFF calculation as a valid base for future fit? Or this error means that FEFF doesn't work correct and I can't rely on its output? If the phase-shift program failed to converge does it mean that it could stop in some completely unrealistic result?

Maria,

You are correct that the version of Feff6 that we are allowed to give away for free reliably complains about failing something called a "hard test". This is some kind of convergence test on the computation of the muffin tin potential.

The test is made in the lines just prior to this:

https://github.com/newville/**ifeffit/blob/master/src/feff6/**fovrg.f#L158 https://github.com/newville/ifeffit/blob/master/src/feff6/fovrg.f#L158

The error is reported here:

https://github.com/newville/**ifeffit/blob/master/src/feff6/**phase.f#L127 https://github.com/newville/ifeffit/blob/master/src/feff6/phase.f#L127

If you can make heads to tails out of the calculation in fovrg.f, you are vastly smarter than me, vastly more patient than me, or both!

I have 2 comments on the main point of your post:

1. As you noted, this question has been asked many times before. Not once has anyone from the Feff project (i.e. anyone who might actually have a working knowledge of that bit of code) bothered to comment. It would be lovely to hear from one of them.

2. This very version of Feff has been included with Ifeffit and with the packages I build for my software for years. Over a decade, in fact. In that time, Feff, Ifeffit, and my software have been used for defensible data analysis thousands of times and by hundreds of practitioners.

That does not mean that any part of the software stack is actually correct. But it does mean that lots of article writers and lots of article reviewers have accepted the results coming from this stack of software.

That does not mean that you should accept it. Quite the contrary -- you would be wise to question every part of the software stack. You may even find that you will need to discard any or all parts of that software stack and replace them with something you trust more -- perhaps even with something that you, yourself have written.

To summarize, I am saying the same thing I have said in the past. I don't understand the code that generates that message. No one from the Feff project has ever bothered weighing in on what it means. No one has demonstrated that it represents an actionable problem. The codes which use Feff have been in use for years to produce defensible science.

So, in conclusion, what should you do? I have no idea. My advice is to continue using the software, but my advice may not be any more reliable than the software itself.

I hope that helps. Probably doesn't, but it's the best I can do. B

-- Bruce Ravel ------------------------------**------ bravel@bnl.gov

National Institute of Standards and Technology Synchrotron Science Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973

Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel ______________________________**_________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.**gov http://millenia.cars.aps.anl.**gov/mailman/listinfo/ifeffit http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Bruce Ravel

6:58 p.m.

Kevin, Thank you for your email. I apologize if I expressed myself in a way that was too mean-spirited in my earlier email, but the basic point was true. The "hard test in fovrg" question has been asked repeatedly. Your response today is, by my memory, the first we've seen on this topic, from your group, and on this mailing list. I have a few comments. 1. The original question remains unanswered. 2. A lot of people use the software stack at the top of which Artemis sits. For many of those people a $250 or $500 expense is completely out of reach. Not a few. Lots. We have users who are impoverished grad students. We have users who are researchers in developing countries. To be so blithe about a $500 expense is unfair to those people. 3. Feff6 is unambiguously not dead. Feff6L is the only version (the *ONLY* version) I am allowed to package with my software. That not only makes it alive -- it makes it the de-facto version for many people. 4. Is Feff9L a thing? I would be thrilled to put Feff6L out of our misery and replace it with something that post-dates Windows 95. I agree that it has been discussed, but no one has ever asked me to take a look at such a thing. Perhaps I flatter myself, but I would think that I would be involved somehow, given that one of the main reasons to make Feff9L is to see it included in a package with Artemis. So, let me end this on a positive note by reaching out to you with some actionable questions: 1. What should I tell my users who ask about the hard test failure in fovrg that is not a solicitation to spend money on Feff9? 2. Can I take a look at Feff9L? Cheers, B On 08/07/2013 02:29 PM, Kevin Jorissen wrote:

...

Dear Ifeffit community,

a short reaction from the FEFFgroup.

1/ It's true that we don't follow up on the ifeffit ML 100%. Important issues usually do get through to us. We highly value the ifeffit community. We can also be contacted directly for problems that are FEFF related rather than iFEFFit related ( contact http://www.feffproject.org/feffproject-contact.html ). We'll likely ask you for the feff.inp file that generates the problem.

2/ We're glad that FEFF6 is so successful. Meanwhile FEFF6 is about as old as Windows95, and development is now focused on FEFF9 http://www.feffproject.org/feffproject-feff.html, which has 15-20 years of improvements over FEFF6. It's a big improvement for anyone running FEFF calculations. It costs $500, or $250 upgrade from any paid version of FEFF.

3/ The OP posted 5 input files. 4 of these run without problems in FEFF9. The last has I atoms (Z=53) at a spacing of 0.8A, and doesn't run out of the box. I expect the same result from FEFF8.

4/ There has been some effort to bring a "FEFF9lite" to the analysis codes, analogous to the FEFF6lite discussed here. We would be very happy to see that effort succeed.

5/ FWIW the fovrg routine was retired in 1996 and replaced by a relativistic version called "dfovrg". The "hard error" does not exist anymore.

6/ We're a small team; we apologize for all the 'bothering' we don't get around to. We do care about supporting our users and put a lot of energy into support. Please reach out ot us when you need us.

-- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel

Kevin Jorissen

7:27 p.m.

Hi Bruce, thanks for your answer. I'm glad that we seem to be in agreement about the main point, which is that a FEFF9L is the best way forward (integrates with analysis tools; has all improvements and bugfixes; free). I'll fire up developer communication about this (including you). Thank you for bringing the $$ problem to my attention; I did not know that it was a problem for a large number of users. As for the original question, the algorithm "fovrg" had some problems (meaning that it would fail; not that it would produce bad results), as explained by John Rehr in the 2005 message cited by the OP. The needed improvements are exactly those changes made in later versions. That is why I am more drawn to a FEFF9L than to fitting some of the improvements into the old FEFF6L, but I will discuss it with the other developers. I have not tried to make the OP's files work in FEFF6L. I would look at the RGRID/AFOLP/FOLP/POTENTIALS cards first. I'll give this a try later myself, but it's possible that there is no solution within FEFF6L. Let me finish by reiterating that people are welcome to contact us directly with FEFF questions, as we may not see all messages reported here. Cheers, Kevin On Wed, Aug 7, 2013 at 11:58 AM, Bruce Ravel wrote:

...

Kevin,

Thank you for your email. I apologize if I expressed myself in a way that was too mean-spirited in my earlier email, but the basic point was true. The "hard test in fovrg" question has been asked repeatedly. Your response today is, by my memory, the first we've seen on this topic, from your group, and on this mailing list.

I have a few comments.

1. The original question remains unanswered.

2. A lot of people use the software stack at the top of which Artemis sits. For many of those people a $250 or $500 expense is completely out of reach. Not a few. Lots. We have users who are impoverished grad students. We have users who are researchers in developing countries. To be so blithe about a $500 expense is unfair to those people.

3. Feff6 is unambiguously not dead. Feff6L is the only version (the *ONLY* version) I am allowed to package with my software. That not only makes it alive -- it makes it the de-facto version for many people.

4. Is Feff9L a thing? I would be thrilled to put Feff6L out of our misery and replace it with something that post-dates Windows 95.

I agree that it has been discussed, but no one has ever asked me to take a look at such a thing. Perhaps I flatter myself, but I would think that I would be involved somehow, given that one of the main reasons to make Feff9L is to see it included in a package with Artemis.

So, let me end this on a positive note by reaching out to you with some actionable questions:

1. What should I tell my users who ask about the hard test failure in fovrg that is not a solicitation to spend money on Feff9?

2. Can I take a look at Feff9L?

Cheers, B

On 08/07/2013 02:29 PM, Kevin Jorissen wrote:

...
Dear Ifeffit community,

a short reaction from the FEFFgroup.

1/ It's true that we don't follow up on the ifeffit ML 100%. Important issues usually do get through to us. We highly value the ifeffit community. We can also be contacted directly for problems that are FEFF related rather than iFEFFit related ( contact <http://www.feffproject.org/**feffproject-contact.html http://www.feffproject.org/feffproject-contact.html> ). We'll likely

ask you for the feff.inp file that generates the problem.

2/ We're glad that FEFF6 is so successful. Meanwhile FEFF6 is about as old as Windows95, and development is now focused on FEFF9 <http://www.feffproject.org/**feffproject-feff.html http://www.feffproject.org/feffproject-feff.html>, which has 15-20

years of improvements over FEFF6. It's a big improvement for anyone running FEFF calculations. It costs $500, or $250 upgrade from any paid version of FEFF.

3/ The OP posted 5 input files. 4 of these run without problems in FEFF9. The last has I atoms (Z=53) at a spacing of 0.8A, and doesn't run out of the box. I expect the same result from FEFF8.

4/ There has been some effort to bring a "FEFF9lite" to the analysis codes, analogous to the FEFF6lite discussed here. We would be very happy to see that effort succeed.

5/ FWIW the fovrg routine was retired in 1996 and replaced by a relativistic version called "dfovrg". The "hard error" does not exist anymore.

6/ We're a small team; we apologize for all the 'bothering' we don't get around to. We do care about supporting our users and put a lot of energy into support. Please reach out ot us when you need us.

-- Bruce Ravel ------------------------------**------ bravel@bnl.gov

National Institute of Standards and Technology Synchrotron Science Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973

Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel ______________________________**_________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.**gov http://millenia.cars.aps.anl.**gov/mailman/listinfo/ifeffit http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Bruce Ravel

7:38 p.m.

On 08/07/2013 03:27 PM, Kevin Jorissen wrote:

...

The needed improvements are exactly those changes made in later versions. That is why I am more drawn to a FEFF9L than to fitting some of the improvements into the old FEFF6L, but I will discuss it with the other developers.

My vast preference is to see Feff9L happen rather than to back port things to Feff6L. Can't imagine anyone would disagree with that. B -- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel

Matthew Marcus

7:35 p.m.

To extend Bruce's points a little: 1. It's not always trivial to plug in a different version of FEFF. The input files are not always compatible, and there's a bit of screwing with settings required to make it work. It would be nice to have a plug-compatible version with more advanced code under the hood. Is that what FEFF9L is, assuming it exists? 2. The later FEFFs use a different structure, in which the modules are separate programs. Can this be integrated into Artemis? Going back to point 1, any "FEFF9L" would need to be a wrapper which executes the modules in correct sequence. 3. Who is it who decides what version is allowed to be freely released? Perhaps that person or entity should be approached? 4. In some institutions, ordering software is a special hassle, however little it costs. 5. Is there some documentation showimg how FEFF(>6) is better than FEFF6L for EXAFS alone? Under what conditions should we be dissatisfied with FEFF6L? I know that FEFF9 has all kinds of nice things that it does, but many of these are irrelevant for Artemis use. mam On 8/7/2013 11:58 AM, Bruce Ravel wrote:

...

Kevin,

Thank you for your email. I apologize if I expressed myself in a way that was too mean-spirited in my earlier email, but the basic point was true. The "hard test in fovrg" question has been asked repeatedly. Your response today is, by my memory, the first we've seen on this topic, from your group, and on this mailing list.

I have a few comments.

1. The original question remains unanswered.

2. A lot of people use the software stack at the top of which Artemis sits. For many of those people a $250 or $500 expense is completely out of reach. Not a few. Lots. We have users who are impoverished grad students. We have users who are researchers in developing countries. To be so blithe about a $500 expense is unfair to those people.

3. Feff6 is unambiguously not dead. Feff6L is the only version (the *ONLY* version) I am allowed to package with my software. That not only makes it alive -- it makes it the de-facto version for many people.

4. Is Feff9L a thing? I would be thrilled to put Feff6L out of our misery and replace it with something that post-dates Windows 95.

I agree that it has been discussed, but no one has ever asked me to take a look at such a thing. Perhaps I flatter myself, but I would think that I would be involved somehow, given that one of the main reasons to make Feff9L is to see it included in a package with Artemis.

So, let me end this on a positive note by reaching out to you with some actionable questions:

1. What should I tell my users who ask about the hard test failure in fovrg that is not a solicitation to spend money on Feff9?

2. Can I take a look at Feff9L?

Cheers, B

On 08/07/2013 02:29 PM, Kevin Jorissen wrote:

...
Dear Ifeffit community,

a short reaction from the FEFFgroup.

1/ It's true that we don't follow up on the ifeffit ML 100%. Important issues usually do get through to us. We highly value the ifeffit community. We can also be contacted directly for problems that are FEFF related rather than iFEFFit related ( contact http://www.feffproject.org/feffproject-contact.html ). We'll likely ask you for the feff.inp file that generates the problem.

2/ We're glad that FEFF6 is so successful. Meanwhile FEFF6 is about as old as Windows95, and development is now focused on FEFF9 http://www.feffproject.org/feffproject-feff.html, which has 15-20 years of improvements over FEFF6. It's a big improvement for anyone running FEFF calculations. It costs $500, or $250 upgrade from any paid version of FEFF.

3/ The OP posted 5 input files. 4 of these run without problems in FEFF9. The last has I atoms (Z=53) at a spacing of 0.8A, and doesn't run out of the box. I expect the same result from FEFF8.

4/ There has been some effort to bring a "FEFF9lite" to the analysis codes, analogous to the FEFF6lite discussed here. We would be very happy to see that effort succeed.

5/ FWIW the fovrg routine was retired in 1996 and replaced by a relativistic version called "dfovrg". The "hard error" does not exist anymore.

6/ We're a small team; we apologize for all the 'bothering' we don't get around to. We do care about supporting our users and put a lot of energy into support. Please reach out ot us when you need us.

Bruce Ravel

7:47 p.m.

Hi Matthew, On 08/07/2013 03:35 PM, Matthew Marcus wrote:

...

2. The later FEFFs use a different structure, in which the modules are separate programs. Can this be integrated into Artemis?

I don't see that as a problem. Demeter already does a lot of crazy things, including playing around with the CONTROL values and replacing Feff's pathfinder with one that I wrote.

...

Going back to point 1, any "FEFF9L" would need to be a wrapper which executes the modules in correct sequence.

I doubt that Feff9L would be a drop-in replacement in Artemis, but if Feff9L were a defined thing, then I (and other software authors -- yourself, for example) would have a defined target to work against.

...

5. Is there some documentation showimg how FEFF(>6) is better than FEFF6L for EXAFS alone? Under what conditions should we be dissatisfied with FEFF6L?

Umm ... well ... perhaps when fovrg fails its hard test? :)

...

I know that FEFF9 has all kinds of nice things that it does, but many of these are irrelevant for Artemis use.

This is a recurring topic on this list and a most excellent question. As I have written before, there is some anecdotal evidence that self consistent muffin tins are an improvement in terms of the values of E0 needed for a good fit. But I am not aware of a rigorous investigation that has been published in any form (journal article on down to wiki page). I think that simply having a version of FeffN (with N>6) in a form that I can properly target in Demeter would be a real boon in that it would be a lot easier to automate such tests. B -- Bruce Ravel ------------------------------------ bravel@bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel

Kevin Jorissen

7:55 p.m.

Hi all, I think that several of the points raised in the last few replies will be better addressed off-ML. (See above) As for the benefits of FEFF9: * calculation of potentials is more stable and more accurate * improved self-energy (-> better peak positions and widths) * ability to use high-quality ab initio Debye-Waller factors (this will currently be beyond the skill of many users, but will be semi-automated in an upcoming release of FEFF9) * alternative "RPA" core hole * ... and don't forget: * 15 years of ironing out problems Cheers, Kevin Jorissen On Wed, Aug 7, 2013 at 12:47 PM, Bruce Ravel wrote:

...

Hi Matthew,

On 08/07/2013 03:35 PM, Matthew Marcus wrote:

...
2. The later FEFFs use a different structure, in which the modules are separate programs. Can this be integrated into Artemis?

I don't see that as a problem. Demeter already does a lot of crazy things, including playing around with the CONTROL values and replacing Feff's pathfinder with one that I wrote.

Going back to point 1, any "FEFF9L" would need to be a

...
wrapper which executes the modules in correct sequence.

I doubt that Feff9L would be a drop-in replacement in Artemis, but if Feff9L were a defined thing, then I (and other software authors -- yourself, for example) would have a defined target to work against.

5. Is there some documentation showimg how FEFF(>6) is better than

...
FEFF6L for EXAFS alone? Under what conditions should we be dissatisfied with FEFF6L?

Umm ... well ... perhaps when fovrg fails its hard test? :)

I know that FEFF9 has all kinds of nice things that it does, but

...
many of these are irrelevant for Artemis use.

This is a recurring topic on this list and a most excellent question. As I have written before, there is some anecdotal evidence that self consistent muffin tins are an improvement in terms of the values of E0 needed for a good fit. But I am not aware of a rigorous investigation that has been published in any form (journal article on down to wiki page).

I think that simply having a version of FeffN (with N>6) in a form that I can properly target in Demeter would be a real boon in that it would be a lot easier to automate such tests.

B

-- Bruce Ravel ------------------------------**------ bravel@bnl.gov

National Institute of Standards and Technology Synchrotron Science Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973

Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel ______________________________**_________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.**gov http://millenia.cars.aps.anl.**gov/mailman/listinfo/ifeffit http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Matthew Marcus

8:09 p.m.

But what is the practical effect of these for users of Artemis? For instance, Artemis doesn't do XANES calculations. I suppose the improved XANES-region calculation may become relevant for EXAFS data taken down to low k, where it's essentially XANES. Ab-initio DWFs are certainly beyond the scope of Artemis fitting. That said, it would be nice to have an approximate means of linking the DWFs for MS paths with those of related SS paths. Anybody have any idea how to do that? One approach might be to assume independent atomic motions. What would be the benefit of the RPA core hole? Under what circumstances would one want to use it? mam On 8/7/2013 12:55 PM, Kevin Jorissen wrote:

...

Hi all,

I think that several of the points raised in the last few replies will be better addressed off-ML. (See above)

As for the benefits of FEFF9:

* calculation of potentials is more stable and more accurate * improved self-energy (-> better peak positions and widths) * ability to use high-quality ab initio Debye-Waller factors (this will currently be beyond the skill of many users, but will be semi-automated in an upcoming release of FEFF9) * alternative "RPA" core hole * ... and don't forget: * 15 years of ironing out problems

Cheers,

Kevin Jorissen

On Wed, Aug 7, 2013 at 12:47 PM, Bruce Ravel mailto:bravel@bnl.gov> wrote:

Hi Matthew,

On 08/07/2013 03:35 PM, Matthew Marcus wrote:

2. The later FEFFs use a different structure, in which the modules are separate programs. Can this be integrated into Artemis?

I don't see that as a problem. Demeter already does a lot of crazy things, including playing around with the CONTROL values and replacing Feff's pathfinder with one that I wrote.

Going back to point 1, any "FEFF9L" would need to be a wrapper which executes the modules in correct sequence.

I doubt that Feff9L would be a drop-in replacement in Artemis, but if Feff9L were a defined thing, then I (and other software authors -- yourself, for example) would have a defined target to work against.

5. Is there some documentation showimg how FEFF(>6) is better than FEFF6L for EXAFS alone? Under what conditions should we be dissatisfied with FEFF6L?

Umm ... well ... perhaps when fovrg fails its hard test? :)

I know that FEFF9 has all kinds of nice things that it does, but many of these are irrelevant for Artemis use.

This is a recurring topic on this list and a most excellent question. As I have written before, there is some anecdotal evidence that self consistent muffin tins are an improvement in terms of the values of E0 needed for a good fit. But I am not aware of a rigorous investigation that has been published in any form (journal article on down to wiki page).

I think that simply having a version of FeffN (with N>6) in a form that I can properly target in Demeter would be a real boon in that it would be a lot easier to automate such tests.

B

-- Bruce Ravel ------------------------------__------ bravel@bnl.gov mailto:bravel@bnl.gov

National Institute of Standards and Technology Synchrotron Science Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973

Homepage: http://xafs.org/BruceRavel Software: https://github.com/bruceravel _________________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.__gov mailto:Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.__gov/mailman/listinfo/ifeffit http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Matthew Marcus

8:18 p.m.

New subject: A potentially useful feature in Artemis

As it is now, if you want to describe your unknown structure as a distorted version of the one for which FEFF was run, you have to enter formulas for distances by hand. For instance, suppose you're doing a substitutional dopant and you want to use Artemis to fit the displacement of the impurity off-site and the dilation/contraction of the first-neighbor shell. As it is now, you have to do the algebra yourself to compute all the distances in terms of the distortion parameters. It would be really nice if there were some syntax for describing the alteration of atom positions, from which Artemis would automatically compute the displacements. This might have to be a new class of parameters. Such a computation would cover the MS paths as well. What it would still NOT do is account for the effect of leg-to-leg angles on MS paths (deviation from focusing/backscatter), but it would be a step. I realize that this would be a big job to implement in a nice way that wouldn't break everything that came before, but it would be super useful and make the IFEFFIT team (yet again) heros to the community. mam

Matthew Marcus

8:03 p.m.

OK. I still use old Artemis. I haven't tried DArtemis, especially in terms of integrating newer versions of FEFF. Is the procedure for doing this documented somewhere? The folklore, with which my experience is consistent, is that FEFF6L reqires large values of E0 relative to the edge in order to fit when the central atom is heavy, such as Pt. What I don't know is how the accuracy varies with FEFF version. I would think that the FEFF group must have made those tests, and they're probably published somewhere in the many papers that have come out describing the newer FEFFs, but I'm too lazy to search for them. As for me being a software developer, I'm not about to screw with the excellent work you've done on the IFEFFIT suite. For one thing, that would require learning Python. mam On 8/7/2013 12:47 PM, Bruce Ravel wrote:

...

Hi Matthew,

On 08/07/2013 03:35 PM, Matthew Marcus wrote:

...
2. The later FEFFs use a different structure, in which the modules are separate programs. Can this be integrated into Artemis?

I don't see that as a problem. Demeter already does a lot of crazy things, including playing around with the CONTROL values and replacing Feff's pathfinder with one that I wrote.

...
Going back to point 1, any "FEFF9L" would need to be a wrapper which executes the modules in correct sequence.

I doubt that Feff9L would be a drop-in replacement in Artemis, but if Feff9L were a defined thing, then I (and other software authors -- yourself, for example) would have a defined target to work against.

...
5. Is there some documentation showimg how FEFF(>6) is better than FEFF6L for EXAFS alone? Under what conditions should we be dissatisfied with FEFF6L?

Umm ... well ... perhaps when fovrg fails its hard test? :)

...
I know that FEFF9 has all kinds of nice things that it does, but many of these are irrelevant for Artemis use.

This is a recurring topic on this list and a most excellent question. As I have written before, there is some anecdotal evidence that self consistent muffin tins are an improvement in terms of the values of E0 needed for a good fit. But I am not aware of a rigorous investigation that has been published in any form (journal article on down to wiki page).

I think that simply having a version of FeffN (with N>6) in a form that I can properly target in Demeter would be a real boon in that it would be a lot easier to automate such tests.

B

4126

Age (days ago)

4127

Last active (days ago)

List overview

Download

11 comments

4 participants

participants (4)

Bruce Ravel
Kevin Jorissen
Matthew Marcus
Naumova, Maria

FEFF report: Hard tests failed in fovrg.

tags

participants (4)