Re: [Ifeffit] possible bug in Atoms
Bruce, thanks for taking a look at the problem- the effort is appreciated. Bests, Matt Frith On Thu, Apr 17, 2014 at 1:00 PM, ifeffit-requ...@millenia.cars.aps.anl.govwrote: Send Ifeffit mailing list submissions to ifeffit@millenia.cars.aps.anl.gov To subscribe or unsubscribe via the World Wide Web, visit http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit or, via email, send a message with subject or body 'help' to ifeffit-requ...@millenia.cars.aps.anl.gov You can reach the person managing the list at ifeffit-ow...@millenia.cars.aps.anl.gov When replying, please edit your Subject line so it is more specific than Re: Contents of Ifeffit digest... Today's Topics: 1. Re: Artemis Feature Request (Bruce Ravel) 2. Re: possible bug in Atoms (Bruce Ravel) -- Message: 1 Date: Wed, 16 Apr 2014 16:49:26 -0400 From: Bruce Ravel bra...@bnl.gov To: XAFS Analysis using Ifeffit ifeffit@millenia.cars.aps.anl.gov Subject: Re: [Ifeffit] Artemis Feature Request Message-ID: 534eecd6.2090...@bnl.gov Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 04/15/2014 01:12 PM, Shelly Kelly wrote: Does Artemis have the ability to save the path list information in a format similar to the old intrp.dat file to disk? Done. Will be in the next release. B -- Bruce Ravel bra...@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 -- Message: 2 Date: Thu, 17 Apr 2014 08:44:51 -0400 From: Bruce Ravel bra...@bnl.gov To: XAFS Analysis using Ifeffit ifeffit@millenia.cars.aps.anl.gov Subject: Re: [Ifeffit] possible bug in Atoms Message-ID: 534fccc3.9010...@bnl.gov Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 04/03/2014 02:19 AM, Matt Frith wrote: I think I may have found a possible bug with the stand-alone version of (D) Atoms. If I generate an inp file in atoms, save it and then try and run feff on it later, Atoms crashes without attempting the calculation. However, if I load that same input file in (D)Artemis it will run feff without crashing. Stand-alone atoms will also fail if I generate the input file in Artemis, save it and then try and later open it using Atoms. Only Atoms or Artemis is open at a time, This will be fixed in the next release. Thanks for the bug report. This problem is occurring on both 32 and 64 bit Windows 7 computers running the current (0.9.18.2) package. The problem occurred using 0.9.17 also. Any ideas of why I am all of a sudden having this issue when it has not been a problem before? I suspect that it has long been a problem, but it takes a particular action to trigger the problem. I think that you, like me, never noticed it before. Cheers, B -- Bruce Ravel bra...@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 End of Ifeffit Digest, Vol 134, Issue 16 ___ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Re: [Ifeffit] possible bug in Atoms
On 04/03/2014 02:19 AM, Matt Frith wrote: I think I may have found a possible bug with the stand-alone version of (D) Atoms. If I generate an inp file in atoms, save it and then try and run feff on it later, Atoms crashes without attempting the calculation. However, if I load that same input file in (D)Artemis it will run feff without crashing. Stand-alone atoms will also fail if I generate the input file in Artemis, save it and then try and later open it using Atoms. Only Atoms or Artemis is open at a time, This will be fixed in the next release. Thanks for the bug report. This problem is occurring on both 32 and 64 bit Windows 7 computers running the current (0.9.18.2) package. The problem occurred using 0.9.17 also. Any ideas of why I am all of a sudden having this issue when it has not been a problem before? I suspect that it has long been a problem, but it takes a particular action to trigger the problem. I think that you, like me, never noticed it before. Cheers, B -- Bruce Ravel bra...@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
Re: [Ifeffit] possible bug in Atoms
Hi Matt, Sorry I have been slow to respond. I've been in meetings all day long since Wednesday. I'll take a look at the problem over the weekend or early next week and let you know what I find. B On 04/03/2014 02:19 AM, Matt Frith wrote: I think I may have found a possible bug with the stand-alone version of (D) Atoms. If I generate an inp file in atoms, save it and then try and run feff on it later, Atoms crashes without attempting the calculation. However, if I load that same input file in (D)Artemis it will run feff without crashing. Stand-alone atoms will also fail if I generate the input file in Artemis, save it and then try and later open it using Atoms. Only Atoms or Artemis is open at a time, This problem is occurring on both 32 and 64 bit Windows 7 computers running the current (0.9.18.2) package. The problem occurred using 0.9.17 also. Any ideas of why I am all of a sudden having this issue when it has not been a problem before? The cif file, inp file, and atoms log file are all attached. -- Bruce Ravel bra...@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
[Ifeffit] possible bug in Atoms
Dear All, I think I may have found a possible bug with the stand-alone version of (D) Atoms. If I generate an inp file in atoms, save it and then try and run feff on it later, Atoms crashes without attempting the calculation. However, if I load that same input file in (D)Artemis it will run feff without crashing. Stand-alone atoms will also fail if I generate the input file in Artemis, save it and then try and later open it using Atoms. Only Atoms or Artemis is open at a time, This problem is occurring on both 32 and 64 bit Windows 7 computers running the current (0.9.18.2) package. The problem occurred using 0.9.17 also. Any ideas of why I am all of a sudden having this issue when it has not been a problem before? The cif file, inp file, and atoms log file are all attached. Sincerely, Matt Frith feff3.inp Description: Binary data AMS_DATA_Gualtieri.cif Description: Binary data datoms.log Description: Binary data ___ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Re: [Ifeffit] Possible bug in atoms files generation by Artemis
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 mamar...@lbl.gov wrote: Some users do have FEFFx (x6l) 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
Re: [Ifeffit] Possible bug in atoms files generation by Artemis
Hi Matthew, On Thu, Mar 28, 2013 at 11:04 AM, Matthew Marcus mamar...@lbl.gov wrote: 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 :-) Sure. I'm not actually trying to assign blame. The license exists, and we accept it. I'm just pointing out that the license and format are out of our control, and that they have real impacts. We've encouraged changes to be made, and would be happy to help in any way we can. Complaining further isn't really constructive. 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. Well, sure. In fairness, Bruce has tried to support both Feff6 and Feff8 files for many years. But it's certainly forgivable to not support all features of every version, especially when there is no support code provided for reading the input files, and there is little communication about changes made. Again, this is not saying that we refuse to support versions of Feff until it is released in a way we prefer, it's saying that we can't support things we don't know how to support. 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. I'm not worried about dubious hacks myself, but that's one possible rationale for not choosing an open source model. At this time, the number of scientists both interested in X-ray spectroscopy and fluent in Fortran is rapidly diminishing, so there are very fee people would able and willing to work on Feff. The code I've seen is not all that well commented. I'm more concerned that no one will be able to maintain Feff than I am that someone will break it. 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. Maybe. Bruce and I tried to pursue such a process many years ago. We begged them to make a library of modular routines that could be tied together better, and to get rid of the damn control cards. We tried, we failed, we've given up and moved on. We're not Feff developers, and we don't have any special insight on new versions or any influence on development. Indeed, they've reinvented wheels (reading CIF files, accessing remote servers) where they could have used Bruce's work and chose not to do so. When working on Bayesian analysis, they did not consult with me until well after publishing, then sent a hacked version of fefft well after ifeffit was out, as if I should add it to something. It sits on my shelf still. The Feff project very clearly wants to not work with us. Again, I don't mean to complain about this, just trying to set the record straight. --Matt ___ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Re: [Ifeffit] Possible bug in atoms files generation by Artemis
On Tuesday, March 26, 2013 01:21:58 PM Matthew Marcus wrote: Just to put my bit in, I believe that the most significant advantage of higher FEFF versions for EXAFS analysis is that it results in more reasonable values for E0 for high-Z elements. I forget whether the issue is high-Z scatterer or absorber. If you use any of the common prescriptions for defining E0 with, say, Pt metal in FEFF6l, your fit will want large values of enot. That said, I have not done a real test by comparing FEFF8 and FEFF6 paths. Has anyone done that? This is *exactly* my point. Except, as Matt said, for the rather limited, unpublished tests made by him and John many years ago, no one has reported on a substantive test comparing the efficacy of feff6 and feff8 for analysis of EXAFS. (Of course, computation of XANES and other spectroscopies is a different topic entirely.) Perhaps I would be more interested in fully implementing use of feff8 in my software if someone would offer a better justification than 8 is a bigger number than 6. FWIW, I agree with Matt that the multi-pole self-energies is a very promising thing that could have a substantial impact on EXAFS analysis. But few of those who claim to want to use feff8 with my software are actually computing and using the multi-pole self-energies. In any case, I do not have permission to redistribute feff8. So, on a very real level, this conversation is moot. B It would be interesting to know what happens if you simulate a k^n*chi(k) with one program and fit it with the other. -- Bruce Ravel bra...@bnl.gov National Institute of Standards and Technology Synchrotron Methods 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
Re: [Ifeffit] Possible bug in atoms files generation by Artemis
Some users do have FEFFx (x6l) 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. 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. 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. 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 On 3/26/2013 9:24 PM, Matt Newville wrote: Hi Matthew, On Tue, 26 Mar 2013, Matthew Marcus wrote: Just to put my bit in, I believe that the most significant advantage of higher FEFF versions for EXAFS analysis is that it results in more reasonable values for E0 for high-Z elements. I forget whether the issue is high-Z scatterer or absorber. If you use any of the common prescriptions for defining E0 with, say, Pt metal in FEFF6l, your fit will want large values of enot. That said, I have not done a real test by comparing FEFF8 and FEFF6 paths. Has anyone done that? It would be interesting to know what happens if you simulate a k^n*chi(k) with one program and fit it with the other. mam It's been a very long time since I've tried, but, yes I've made such comparisons in the past, as well as comparing Feff6 and Feff8 to the same very good data. Feff 8 actually has a long history. Initially, EXAFS was noticeably worse with Feff8, but it got better over the years to the point where I think it's hard to say that Feff8 is worse than Feff6 for EXAFS. As you say, E0 is better (though still needs refinement), as is S02. Feff8 also appears that it is better for heavy elements (perhaps Z 50, but I'm not sure anyone has looked at that carefully). But: the multi-pole self-energy introduced around Feff8.5 or so can make a very large improvement for the EXAFS. Whether this can be made generally applicable is a separate question. Just to echo some of Bruce's frustration and build on that (and, speaking only for myself): Basically, we're stuck with Feff6 because we do not have access to Feff8. Last I heard, John and Josh were working on this, so that Feff8-for-EXAFS would be made freely available. I haven't seen the code yet, but I'm optimistic that it will be released someday. Once this happens, I'll happily start incorporating this into Larch. I'd very much like to replace the pathfinder (as Bruce has done in Perl for Demeter) so that distortions are easier to track, and allow the EXAFS calculation for a Path to be done automatically inside the fitting loop. That will be some real work (anyone out there interested in helping?), and could take awhile, but could actually make a difference for modeling. I'm pretty sure that getting the multi-pole self-energies more universally useful would be a big help, but I think there still some unknowns there (basically -- how well do you have to know the dielectric response for a general system?) that have to be worked out. Getting 1/epsilon for Cu metal is one thing (a first step!), but getting it for As sorbed onto ferrihydrite or would be more challenging --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
Re: [Ifeffit] Possible bug in atoms files generation by Artemis
As I just mentioned to Matt, this conversation is NOT moot because a significant fraction of users have bought access. I wonder if it would be possible to make some sort of 'crippleware' version of FEFF(6) which ONLY runs from within DemLarchTemis? That might make the UW folks a little more comfortable with letting it be available. FEFF9+ will be a harder case because it seems to have been designed to be run by the jfeff interface and consists of separate programs which have to be run in sequence. I suppose a wrapper could be written to orchestrate that. mam On 3/27/2013 5:44 AM, Bruce Ravel wrote: On Tuesday, March 26, 2013 01:21:58 PM Matthew Marcus wrote: Just to put my bit in, I believe that the most significant advantage of higher FEFF versions for EXAFS analysis is that it results in more reasonable values for E0 for high-Z elements. I forget whether the issue is high-Z scatterer or absorber. If you use any of the common prescriptions for defining E0 with, say, Pt metal in FEFF6l, your fit will want large values of enot. That said, I have not done a real test by comparing FEFF8 and FEFF6 paths. Has anyone done that? This is *exactly* my point. Except, as Matt said, for the rather limited, unpublished tests made by him and John many years ago, no one has reported on a substantive test comparing the efficacy of feff6 and feff8 for analysis of EXAFS. (Of course, computation of XANES and other spectroscopies is a different topic entirely.) Perhaps I would be more interested in fully implementing use of feff8 in my software if someone would offer a better justification than 8 is a bigger number than 6. FWIW, I agree with Matt that the multi-pole self-energies is a very promising thing that could have a substantial impact on EXAFS analysis. But few of those who claim to want to use feff8 with my software are actually computing and using the multi-pole self-energies. In any case, I do not have permission to redistribute feff8. So, on a very real level, this conversation is moot. B It would be interesting to know what happens if you simulate a k^n*chi(k) with one program and fit it with the other. ___ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
[Ifeffit] Possible bug in atoms files generation by Artemis
Hi, I ran updater for Demeter 0.9.15. I was using Artemis to calculate paths for Bi L3 in Bi2Te3. I saw now the option of using both (FEFF 6 and FEFF 8 style) for atoms. Previously, I was using only available option of FEFF6 style. When I tried to run atoms selecting FEFF 8, it generated atoms files but when I tried to run FEFF calculations it produced following errors. Error#1 Unknown keyword: EDGE at line: EDGE L3 Error#2 Unknown keyword: exchange at line: exchange I worked around first error by replacing EDGE L3 S02 1.0 - which was generated by atoms when FEFF8 style is selected. with HOLE 4 1.0 and deleting Exchange keyword from feff file. After making these edits in feff files, I was able to run FEFF without showing any errors. I have attached all the files with appropriate name. -- Devender Graduate Student, Materials Science and Engineering Rensselaer Polytechnic Institute, Troy, NY Website https://sites.google.com/site/devendermaun/ feff8_user_generated_file_1.inp Description: Binary data feff8_user_generated_file_2.inp Description: Binary data feff6_auto_generated_file.inp Description: Binary data feff8_auto_generated_file.inp Description: Binary data ___ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Re: [Ifeffit] Possible bug in atoms files generation by Artemis
Hi Matthew, On Tue, 26 Mar 2013, Matthew Marcus wrote: Just to put my bit in, I believe that the most significant advantage of higher FEFF versions for EXAFS analysis is that it results in more reasonable values for E0 for high-Z elements. I forget whether the issue is high-Z scatterer or absorber. If you use any of the common prescriptions for defining E0 with, say, Pt metal in FEFF6l, your fit will want large values of enot. That said, I have not done a real test by comparing FEFF8 and FEFF6 paths. Has anyone done that? It would be interesting to know what happens if you simulate a k^n*chi(k) with one program and fit it with the other. mam It's been a very long time since I've tried, but, yes I've made such comparisons in the past, as well as comparing Feff6 and Feff8 to the same very good data. Feff 8 actually has a long history. Initially, EXAFS was noticeably worse with Feff8, but it got better over the years to the point where I think it's hard to say that Feff8 is worse than Feff6 for EXAFS. As you say, E0 is better (though still needs refinement), as is S02. Feff8 also appears that it is better for heavy elements (perhaps Z 50, but I'm not sure anyone has looked at that carefully). But: the multi-pole self-energy introduced around Feff8.5 or so can make a very large improvement for the EXAFS. Whether this can be made generally applicable is a separate question. Just to echo some of Bruce's frustration and build on that (and, speaking only for myself): Basically, we're stuck with Feff6 because we do not have access to Feff8. Last I heard, John and Josh were working on this, so that Feff8-for-EXAFS would be made freely available. I haven't seen the code yet, but I'm optimistic that it will be released someday. Once this happens, I'll happily start incorporating this into Larch. I'd very much like to replace the pathfinder (as Bruce has done in Perl for Demeter) so that distortions are easier to track, and allow the EXAFS calculation for a Path to be done automatically inside the fitting loop. That will be some real work (anyone out there interested in helping?), and could take awhile, but could actually make a difference for modeling. I'm pretty sure that getting the multi-pole self-energies more universally useful would be a big help, but I think there still some unknowns there (basically -- how well do you have to know the dielectric response for a general system?) that have to be worked out. Getting 1/epsilon for Cu metal is one thing (a first step!), but getting it for As sorbed onto ferrihydrite or would be more challenging --Matt ___ Ifeffit mailing list Ifeffit@millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
