Regarding XANES fits, I'm glad to hear Bruce is working on adding a principal component analysis to IFEFFIT. Doing XANES fits ala Benfatto and Della Longa would also be desirable in the long run, i.e., fitting the XAS(x) with x standing for various parameters like interatomic distances. To do that would generally require looping over the FMS module in FEFF and could get time consuming. To avoid this, one needs something like a tensor XANES calculation, which computes d mu/ dx via multiple XAS calculations and hence permits fast linear interpolations. This is not implementable with IFEFFIT/ATHENA at present as far as I know. However, I don't see major difficulties in implementation (?). There are some other ways to go, including using the parallel version of FEFF8 (Bouldin for example has suggested using this approach for XANES fits). Also, one might even consider adding constraints ala Krappe and Rossner's Bayesean-Turchin approach for EXAFS analysis. John Rehr
From B. Ravel ...
My program, Athena, currently has the capability of fitting lineshapes (i.e. an arctangent and a number of Gaussians or Lorentzians) to normalized XANES data. In the not-too-distant future, Athena will be able to fit a linear combination of standards to a XANES spectrum and be able to do principle component analysis (PCA).
John, On Tue, 4 Mar 2003, John J. Rehr wrote:
Doing XANES fits ala Benfatto and Della Longa would also be desirable in the long run, i.e., fitting the XAS(x) with x standing for various parameters like interatomic distances. To do that would generally require looping over the FMS module in FEFF and could get time consuming. To avoid this, one needs something like a tensor XANES calculation, which computes d mu/ dx via multiple XAS calculations and hence permits fast linear interpolations. This is not implementable with IFEFFIT/ATHENA at present as far as I know. However, I don't see major difficulties in implementation (?).
Well, it wouldn't be easy, but it is technically feasible. Bruce and I have been pushing for changes to Feff that would facilitate these and other important capabilities for many years now. The main difficulty is a legal one. The Feff license forbids anyone from altering Feff8 and distributing the changes. So I agree when you say that these changes cannot be implemented within IFEFFIT. This is not for any technical reason, but simply because you do not allow it to happen. You are unwilling to change the code to allow these things, and forbd anyone else from making such changes. This is not an unfortunate but unavoidable consequence of an otherwise beneficial license. No, it is the entire point of the Feff license to restrict others from developing new capabilities exactly of this sort. There is no other explanation for the license. The scientific merit of this policy is beyond my comprehension, but the restriction is completely deliberate. Perhaps the more surprising thing is that Feff has never included analytic capabilities, but is widely used for EXAFS analysis. In this respect, Feff is very unusual for scientific software. Since those working on analysis codes are forbidden from changing Feff, it's not very likely that significant progress will be made in XANES analysis or other new areas unless you pay attention to the requests and suggestions of experimentalists and authors of analysis codes. History is does not on your side. And yet from the above statement, you see these capabilities for XANES analysis as technically possible and desirable. I agree with this, but don't see how they can possibly be done given the very clear intention of the Feff license. I cannot imagine anyone willing and able to make these changes. Since you think these capabilities for XANES analysis are both desirable and possible, it would be interesting to hear why you think it is in the best interest of the XAFS community for the Feff Project to prevent the development of such capabilities. --Matt
Hi Matt, It's not clear to me that FEFF has to be changed at all to get a tensor XANES calculation going. The code simply has to be rerun a few times with different input. Anyway, The FEFF8.2 license now allows users to make changes that improve input/output. Also various modules of FEFF are now redistributable in order to facilitate user developments in response to previous suggestions from Matt and Bruce. This seems to be a good way to go, since much of FEFF is an engine that shouldn't be messed with. Also much of FEFF6 is now distributed with IFEFFIT. These EXAFS parts of the code are very stable/reliable. It doesn't seem desirable to me to freely distribute more recent parts that are less well developed. On the other hand we will and do work with various collaborators on various code developments. I'd like to hear from other users/developers of their concerns about the FEFF license. Funds from the license fee do go to the UWOTT to support the FEFF project (equipment supplies, travel etc.). John
On Tue, 4 Mar 2003, John J. Rehr wrote:
Doing XANES fits ala Benfatto and Della Longa would also be desirable in the long run, i.e., fitting the XAS(x) with x standing for various parameters like interatomic distances. To do that would generally require looping over the FMS module in FEFF and could get time consuming. To avoid this, one needs something like a tensor XANES calculation, which computes d mu/ dx via multiple XAS calculations and hence permits fast linear interpolations. This is not implementable with IFEFFIT/ATHENA at present as far as I know. However, I don't see major difficulties in implementation (?).
Well, it wouldn't be easy, but it is technically feasible. Bruce and I have been pushing for changes to Feff that would facilitate these and other important capabilities for many years now.
The main difficulty is a legal one. The Feff license forbids anyone from altering Feff8 and distributing the changes. So I agree when you say that these changes cannot be implemented within IFEFFIT. This is not for any technical reason, but simply because you do not allow it to happen. You are unwilling to change the code to allow these things, and forbd anyone else from making such changes.
This is not an unfortunate but unavoidable consequence of an otherwise beneficial license. No, it is the entire point of the Feff license to restrict others from developing new capabilities exactly of this sort. There is no other explanation for the license. The scientific merit of this policy is beyond my comprehension, but the restriction is completely deliberate.
Perhaps the more surprising thing is that Feff has never included analytic capabilities, but is widely used for EXAFS analysis. In this respect, Feff is very unusual for scientific software. Since those working on analysis codes are forbidden from changing Feff, it's not very likely that significant progress will be made in XANES analysis or other new areas unless you pay attention to the requests and suggestions of experimentalists and authors of analysis codes. History is does not on your side.
And yet from the above statement, you see these capabilities for XANES analysis as technically possible and desirable. I agree with this, but don't see how they can possibly be done given the very clear intention of the Feff license. I cannot imagine anyone willing and able to make these changes.
Since you think these capabilities for XANES analysis are both desirable and possible, it would be interesting to hear why you think it is in the best interest of the XAFS community for the Feff Project to prevent the development of such capabilities.
--Matt
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Hi Prof. Rehr, Matt, Bruce This is in reference to distribution and changes of FEFF as discussed by Prof. Rehr and Matt.... Perhaps Matt you don't appreciate how liberal! Prof. Rehr is in distributing FEFF....A recent experience convinced me that it so! I was curious to check a calculation of Zn doping in LSCO system by performed by DCA [Dynamical Cluster Approximation] code. I contacted one of the authors , Thomas A. Maier, he said it is OK but he has to confirm with Mark Jarell......Then Mark Jarell sent me a list of reservations he has to make the code public, I answered his points, anyways despite my many assurances that it would not be distributed further he weasled out.......... Thus I personally appreciate Prof. Rehr to distribute and decimate the code so that others can benifit....... Plus yours and Bruce many efforts in developing Atoms, Athena, Artemis and Ifeffit................ thanks and regards sher "John J. Rehr" wrote:
Hi Matt,
It's not clear to me that FEFF has to be changed at all to get a tensor XANES calculation going. The code simply has to be rerun a few times with different input. Anyway, The FEFF8.2 license now allows users to make changes that improve input/output.
Also various modules of FEFF are now redistributable in order to facilitate user developments in response to previous suggestions from Matt and Bruce. This seems to be a good way to go, since much of FEFF is an engine that shouldn't be messed with. Also much of FEFF6 is now distributed with IFEFFIT. These EXAFS parts of the code are very stable/reliable. It doesn't seem desirable to me to freely distribute more recent parts that are less well developed. On the other hand we will and do work with various collaborators on various code developments.
I'd like to hear from other users/developers of their concerns about the FEFF license. Funds from the license fee do go to the UWOTT to support the FEFF project (equipment supplies, travel etc.).
John
On Tue, 4 Mar 2003, John J. Rehr wrote:
Doing XANES fits ala Benfatto and Della Longa would also be desirable in the long run, i.e., fitting the XAS(x) with x standing for various parameters like interatomic distances. To do that would generally require looping over the FMS module in FEFF and could get time consuming. To avoid this, one needs something like a tensor XANES calculation, which computes d mu/ dx via multiple XAS calculations and hence permits fast linear interpolations. This is not implementable with IFEFFIT/ATHENA at present as far as I know. However, I don't see major difficulties in implementation (?).
Well, it wouldn't be easy, but it is technically feasible. Bruce and I have been pushing for changes to Feff that would facilitate these and other important capabilities for many years now.
The main difficulty is a legal one. The Feff license forbids anyone from altering Feff8 and distributing the changes. So I agree when you say that these changes cannot be implemented within IFEFFIT. This is not for any technical reason, but simply because you do not allow it to happen. You are unwilling to change the code to allow these things, and forbd anyone else from making such changes.
This is not an unfortunate but unavoidable consequence of an otherwise beneficial license. No, it is the entire point of the Feff license to restrict others from developing new capabilities exactly of this sort. There is no other explanation for the license. The scientific merit of this policy is beyond my comprehension, but the restriction is completely deliberate.
Perhaps the more surprising thing is that Feff has never included analytic capabilities, but is widely used for EXAFS analysis. In this respect, Feff is very unusual for scientific software. Since those working on analysis codes are forbidden from changing Feff, it's not very likely that significant progress will be made in XANES analysis or other new areas unless you pay attention to the requests and suggestions of experimentalists and authors of analysis codes. History is does not on your side.
And yet from the above statement, you see these capabilities for XANES analysis as technically possible and desirable. I agree with this, but don't see how they can possibly be done given the very clear intention of the Feff license. I cannot imagine anyone willing and able to make these changes.
Since you think these capabilities for XANES analysis are both desirable and possible, it would be interesting to hear why you think it is in the best interest of the XAFS community for the Feff Project to prevent the development of such capabilities.
--Matt
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov 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
-- %Ins:::::::Prof. Dr. Sher Alam Work:Rm D-625 Photonics, Nat. Inst. of AIST, AIST Tsukuba Central 2, 1-1-1 Umezono Tsukuba, Ibaraki 305-8568 Japan [W]phone:+81-298-61-3478 fax:+81-298-61-3476 email:alam-sher@aist.go.jp
Hi folks, Last week we had a short but somewhat impassioned exchange on our mailing list between Matt, John, and longtime FEFF and IFEFFIT user Sher Alam. Matt made a claim (one with which I agree) that the license for FEFF is insufficiently liberal and that this has served to hinder certain developments over the years. Dr. Alam responded with this interesting comment: sa> Perhaps Matt you don't appreciate how liberal! Prof. Rehr is in sa> distributing FEFF....A recent experience convinced me that it so! <<snip snip>> sa> Thus I personally appreciate Prof. Rehr to distribute ... the sa> code so that others can benefit. I worry that people seeing the public side of this ongoing debate between Matt, John, and I may conflate criticism of FEFF's license with criticism of FEFF or of its authors. That would be an incorrect assessment and I would hasten to dissuade anyone of adopting it. I am currently hard at work on the document for Artemis. I refer to FEFF on virtually every page. This is because Artemis and FEFF are inextricably linked. My little greek goddess could not exist without FEFF. Indeed, virtually everything I have done as a professional has involved FEFF in some capacity. Obviously FEFF is something that I value and whose value I fully appreciate. Nonetheless I have a long standing complaint about its license. In last week's exchange, John said: jjr> Also various modules of FEFF are now redistributable in order to jjr> facilitate user developments in response to previous suggestions jjr> from Matt and Bruce. It takes some searching to find the license in the source code for tarball for FEFF8.28 (look for the file license.h -- there are several copies of it). You can find a copy in PDF and Word form at http://feff.phys.washington.edu/feff/html/obtain.html. The only clause in that license that, by my reading, relates to redistribution is section III.4: The End-user shall take reasonable precautions to ensure that neither the System nor its components are copied, or transferred out side [sic] of his/her current academic or government affiliated laboratory or disclosed to parties other than the End-user. That very clearly forbids redistribution either of FEFF8 in its entirety or of its modules. There is a legally confusing aspect to this due to the version of FEFF6 which is distributed with IFEFFIT and which is redistributable. That version of FEFF6 and the current version of FEFF8 do share some common code. I presume that, for common code, the more liberal FEFF6-with-IFEFFIT license trumps the highly controlling FEFF8 license. And there is the problem of no clear mechanism for rolling an improvement to FEFF6 back into the FEFF8 source code. As for the prospect of outside development, section III.2 is clearly chilling for anyone with an idea for how to use FEFF in a way not encompassed by its current functionality. Modification of the System is permitted, e.g., to facilitate its performance by the End-user. Use of the System or any of its components for any purpose other than that specified in this Agreement requires prior approval in writing from the University of Washington. As I read this, should I wish to modify FEFF to deal with, say XPS data, I would be in violation of the license because XPS is a new spectroscopy and not simply a matter of performance. I am fully aware that it is ridiculous to assume that either the FEFF developers or the University of Washington will *really* come after me if I do use FEFF to analyze my XPS data, but that's beside the point. The license, as written, forbids it. Another alarming clause in the license is the final one, VII.2. It says This Agreement contains the entire agreement between UW and LICENSEE, and supersedes all prior written or oral representations with respect to FEFF Software. This means that if you have a FEFF license, you may not redistribute or modify FEFF outside of the restrictions of clause III.2 even if John or Alex have told you that you have their permission to do so. Surprising, but apparently true. I presume that I have been quoting from the current license. Since it is the only license that can be found, that makes it the de facto license. John went on to say jjr> It doesn't seem desirable to me to freely distribute more recent jjr> parts that are less well developed. The implicit assumption here is that only the developers of FEFF should be touching the cutting edge portions of the code. I dispute this assumption. I dispute it NOT because it might be false, but because it is unproven. We do not know if smart scientists who are not in intimate contact with the FEFF developers could plausibly contribute significantly to the hairy, bleeding edge parts of FEFF because no one is currently doing so. Matt's suggestion in his email was that the chilling nature of the FEFF license is an impediment to anyone who wishes to try. Now, it may turn out to be true that the FEFF developers are singularly capable of being the stewards of the hairy, edgy parts of FEFF. That is entirely believable because John and Alex are singularly brilliant scientists. (I mean that plainly and without the vaguest hint of irony. I know them both very well, have shared both physics and beer extensively with both and will do so extensively in the future, and can attest to their brilliance with sincerity.) However, the singularity of their stewardship is not proven. Indeed, I suspect that the FEFF developers do themselves as well as their community a disservice by not allowing that assumption to be tested. After all, there are lots of clever people in this world who may have some profound ideas. I acknowledge that it is not for me to say how FEFF should be licensed. Its not mine, after all. (Well, some of the code in the FMS directory is mine, I suppose, but I am not at this time coding for FEFF itself.) I do not, therefore, dispute the right of the FEFF project to choose the current license. It is, however, most definitely within my bailiwick to express my opinion for what license *I* think would be best for FEFF and its user community. I agree with Dr. Alam that the FEFF community is well served by FEFF as it is. But I agree with Matt that it would be much better served by a very liberal, uncontrolling license. I feel compelled, in closing, to state something that I hope would be obvious. FEFF, the tools which use it, and XAFS in general are all things that I am most passionate about. I would not bother to form the opinions I have expressed here were FEFF not the object of my professional passions. I would not spend an hour and half on a Saturday afternoon putting this opinion into words were FEFF not the object of my professional passions. I debate with John because I care. Regards, B -- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
Thanks for your detailed explanation below. Actually my remarks were targeted to general FEFF , and related programs users and not to the internal developers of these packages....... Thus I agree with the jist of what you are saying, and moreover that is not my business, it is the business of the developers............ To summarize although FEFF and related programs have been developed after many years of hardwork these are easily available and useful for decimating physics research...........unlike many <<snip snip>>! thanks again sher Bruce Ravel wrote:
Hi folks,
Last week we had a short but somewhat impassioned exchange on our mailing list between Matt, John, and longtime FEFF and IFEFFIT user Sher Alam. Matt made a claim (one with which I agree) that the license for FEFF is insufficiently liberal and that this has served to hinder certain developments over the years.
Dr. Alam responded with this interesting comment:
sa> Perhaps Matt you don't appreciate how liberal! Prof. Rehr is in sa> distributing FEFF....A recent experience convinced me that it so! <<snip snip>> sa> Thus I personally appreciate Prof. Rehr to distribute ... the sa> code so that others can benefit.
I worry that people seeing the public side of this ongoing debate between Matt, John, and I may conflate criticism of FEFF's license with criticism of FEFF or of its authors. That would be an incorrect assessment and I would hasten to dissuade anyone of adopting it.
I am currently hard at work on the document for Artemis. I refer to FEFF on virtually every page. This is because Artemis and FEFF are inextricably linked. My little greek goddess could not exist without FEFF. Indeed, virtually everything I have done as a professional has involved FEFF in some capacity. Obviously FEFF is something that I value and whose value I fully appreciate.
Nonetheless I have a long standing complaint about its license.
In last week's exchange, John said:
jjr> Also various modules of FEFF are now redistributable in order to jjr> facilitate user developments in response to previous suggestions jjr> from Matt and Bruce.
It takes some searching to find the license in the source code for tarball for FEFF8.28 (look for the file license.h -- there are several copies of it). You can find a copy in PDF and Word form at http://feff.phys.washington.edu/feff/html/obtain.html. The only clause in that license that, by my reading, relates to redistribution is section III.4:
The End-user shall take reasonable precautions to ensure that neither the System nor its components are copied, or transferred out side [sic] of his/her current academic or government affiliated laboratory or disclosed to parties other than the End-user.
That very clearly forbids redistribution either of FEFF8 in its entirety or of its modules. There is a legally confusing aspect to this due to the version of FEFF6 which is distributed with IFEFFIT and which is redistributable. That version of FEFF6 and the current version of FEFF8 do share some common code. I presume that, for common code, the more liberal FEFF6-with-IFEFFIT license trumps the highly controlling FEFF8 license. And there is the problem of no clear mechanism for rolling an improvement to FEFF6 back into the FEFF8 source code.
As for the prospect of outside development, section III.2 is clearly chilling for anyone with an idea for how to use FEFF in a way not encompassed by its current functionality.
Modification of the System is permitted, e.g., to facilitate its performance by the End-user. Use of the System or any of its components for any purpose other than that specified in this Agreement requires prior approval in writing from the University of Washington.
As I read this, should I wish to modify FEFF to deal with, say XPS data, I would be in violation of the license because XPS is a new spectroscopy and not simply a matter of performance. I am fully aware that it is ridiculous to assume that either the FEFF developers or the University of Washington will *really* come after me if I do use FEFF to analyze my XPS data, but that's beside the point. The license, as written, forbids it.
Another alarming clause in the license is the final one, VII.2. It says
This Agreement contains the entire agreement between UW and LICENSEE, and supersedes all prior written or oral representations with respect to FEFF Software.
This means that if you have a FEFF license, you may not redistribute or modify FEFF outside of the restrictions of clause III.2 even if John or Alex have told you that you have their permission to do so. Surprising, but apparently true.
I presume that I have been quoting from the current license. Since it is the only license that can be found, that makes it the de facto license.
John went on to say
jjr> It doesn't seem desirable to me to freely distribute more recent jjr> parts that are less well developed.
The implicit assumption here is that only the developers of FEFF should be touching the cutting edge portions of the code.
I dispute this assumption. I dispute it NOT because it might be false, but because it is unproven. We do not know if smart scientists who are not in intimate contact with the FEFF developers could plausibly contribute significantly to the hairy, bleeding edge parts of FEFF because no one is currently doing so. Matt's suggestion in his email was that the chilling nature of the FEFF license is an impediment to anyone who wishes to try.
Now, it may turn out to be true that the FEFF developers are singularly capable of being the stewards of the hairy, edgy parts of FEFF. That is entirely believable because John and Alex are singularly brilliant scientists. (I mean that plainly and without the vaguest hint of irony. I know them both very well, have shared both physics and beer extensively with both and will do so extensively in the future, and can attest to their brilliance with sincerity.) However, the singularity of their stewardship is not proven. Indeed, I suspect that the FEFF developers do themselves as well as their community a disservice by not allowing that assumption to be tested. After all, there are lots of clever people in this world who may have some profound ideas.
I acknowledge that it is not for me to say how FEFF should be licensed. Its not mine, after all. (Well, some of the code in the FMS directory is mine, I suppose, but I am not at this time coding for FEFF itself.) I do not, therefore, dispute the right of the FEFF project to choose the current license.
It is, however, most definitely within my bailiwick to express my opinion for what license *I* think would be best for FEFF and its user community. I agree with Dr. Alam that the FEFF community is well served by FEFF as it is. But I agree with Matt that it would be much better served by a very liberal, uncontrolling license.
I feel compelled, in closing, to state something that I hope would be obvious. FEFF, the tools which use it, and XAFS in general are all things that I am most passionate about. I would not bother to form the opinions I have expressed here were FEFF not the object of my professional passions. I would not spend an hour and half on a Saturday afternoon putting this opinion into words were FEFF not the object of my professional passions. I debate with John because I care.
Regards, B
-- Bruce Ravel ----------------------------------- ravel@phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697
NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973
My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/
_______________________________________________ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
-- %Ins:::::::Prof. Dr. Sher Alam Work:Rm D-625 Photonics, Nat. Inst. of AIST, AIST Tsukuba Central 2, 1-1-1 Umezono Tsukuba, Ibaraki 305-8568 Japan [W]phone:+81-298-61-3478 fax:+81-298-61-3476 email:alam-sher@aist.go.jp
participants (4)
-
Bruce Ravel -
John J. Rehr -
Matt Newville -
Sher Alam