- Ifeffit - millenia.cars.aps.anl.gov

Virus Found in message "Application"
by Joe 10 Jul '03

10 Jul '03

Norton AntiVirus found a virus in an attachment you (ifeffit(a)millenia.cars.aps.anl.gov) sent to Joe. To ensure the recipient(s) are able to use the files you sent, perform a virus scan on your computer, clean any infected files, then resend this attachment. Attachment: your_details.zip Virus name: Multiple viruses found. Please see individual log messages. Action taken: Clean failed : Quarantine succeeded : File status: Still contains 1 infected items

1 0

Re: Ifeffit Digest, Vol 5, Issue 4
by Grant Bunker 09 Jul '03

09 Jul '03

In regard to global fitting, there are much better algorithms than a simple grid search, something we stared with the 70's. More recently I have had some good results with a very simple genetic algorithm called "differential evolution" by storn and price. It seems to be faster than simulated annealing, and it has the advantage of being very robust. It behaves well with hard constraints (e.g. integer programming) included by penalty functions (or if you like, terms incorporating a priori knowledge, from a bayesian point of view). It also looks to me like it would be trivial to parallelize for using multiple processors. I think the easiest thing to implement in feffit however would be simply to do a series of minimizations with (say, 1000) random starting points in the parameter space. This would just entail wrapping the minimization in a loop, and adding a way to summarize the results. Minimizations starting at differentpoints may end up in the same or different "attractors". If those corresponded to bad fits, throw them out. If they are adequate fits, keep them. Quite possibly more than one attractor could fit the data adequately. A cluster analysis of the results should indicate whether different solutions are equivalent (belong to the same attractor) or not. I don't think this should be very hard to do. Of course it easy to suggest that other people do the work, so I've been playing with these approaches myself using mathematica as my sandbox. The minimization code in feffit would have to be robust enough that it would give up gracefully (not crash) if it became numerically unstable. I think it should be fast enough that a global solution could be obtained in a couple of hours on a modern machine. If not, it could be done in an intrinsically parallel way on multiple machines. thanks - grant On Tue, 8 Jul 2003 ifeffit-request(a)millenia.cars.aps.anl.gov wrote: > Send Ifeffit mailing list submissions to > ifeffit(a)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-request(a)millenia.cars.aps.anl.gov > > You can reach the person managing the list at > ifeffit-owner(a)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: ARE: [Ifeffit] Re: Ifeffit Digest, Vol 5, Issue 1 > (Bruce Ravel) > 2. Re: Estimating error in XAS (Scott Calvin) > 3. Re: Re: Estimating error in XAS (Matt Newville) > 4. Re: Estimating error in XAS (Scott Calvin) > 5. Scanning of "Potential Surfaces" in EXAFS (Norbert Weiher) > 6. Re: Scanning of "Potential Surfaces" in EXAFS (Bruce Ravel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Jul 2003 13:11:08 -0400 > From: Bruce Ravel <ravel(a)phys.washington.edu> > Subject: Re: ARE: [Ifeffit] Re: Ifeffit Digest, Vol 5, Issue 1 > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Message-ID: <200307071311.08259.ravel(a)phys.washington.edu> > Content-Type: text/plain; charset="iso-8859-1" > > On Monday 07 July 2003 12:45 pm, Matt Newville wrote: > > Anyway, I think using the 'epsilon_k' that chi_noise() estimates as > > the noise in chi(k) is a fine way to do a weighted averages of data. > > It's not perfect, but neither is anything else. > > Exactly right! As Matt explained, there are reasons to believe that > the measurement uncertainty is dominated by things that Parsival's > theorem doesn't address and that measuring those problems is hard. > > As Matt said, weighting by 1/chi_noise() is OK. As Scott said, > weighting uniformly is OK. Those are two choices are the most OK I > can think of, so Athena will let you choose between them. > > While I am of the chorus of people agreeing with Grant that mu is not > equal to <If>/<I0>, I can see no reason why Athena should actively > prevent the user from looking at <If> or <I0>, if that is what he > wants to do. The *current* version of Athena prevents this, but > that's a bug not a feature! ;-) > > B > > > > -- > Bruce Ravel ----------------------------------- ravel(a)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/ > > > ------------------------------ > > Message: 2 > Date: Mon, 7 Jul 2003 13:15:45 -0400 > From: Scott Calvin <scalvin(a)anvil.nrl.navy.mil> > Subject: [Ifeffit] Re: Estimating error in XAS > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Message-ID: <p05210602bb2f56d34214(a)[132.250.126.21]> > Content-Type: text/plain; charset="us-ascii" > > In the anecdotal category, I've seen some fairly bizarre high-r > behavior on beamline X23B at the NSLS, which I tentatively attribute > to feedback problems. That line, as many of you know, can be a little > pathological at times. I've also collected some data to examine this > issue on X11A, a more conventional beamline, but have never gotten > around to looking at it--I hope to soon. > > In any case, I don't really understand the logic of averaging scans > based on some estimate of the noise. For that to be appropriate, > you'd have to believe there was some systematic difference in the > noise between scans. What's causing that difference, if they're > collected on the same beamline on the same sample? (Or did I > misunderstand Michel's comment--was he talking about averaging data > from different beamlines or something?) If there is no systematic > changes during data collection, then the noise level should be the > same, and any attempt to weight by some proxy for the actual noise > will actually decrease the statistical content of the averaged data > by overweighting some scans (i. e. random fluctuations in the > quantity being used to estimate the uncertainty will cause some scans > to dominate the average more heavily, which is not ideal if the > actual noise level is the same). If, on the other hand, there is a > systematic difference between subsequent scans, it is fairly unlikely > to be "white," and thus will not be addressed by this scheme anyway. > Perhaps one of you can give me examples where this kind of variation > in data quality is found. > > So right now I don't see the benefit to this method. Particularly if > it's automated, I hesitate to add hidden complexity to my data > reduction without a clear rationale for it. > > --Scott Calvin > Naval Research Lab > Code 6344 > > Matt Newville wrote: > > > > >I'd assumed that vibrations would actually cause fairly white noise, > >though feedback mechanisms could skew towards high frequency. Other > >effects (temperature/pressure/flow fluctuations in ion chamber gases > >and optics) might skew toward low-frequency noises. I have not seen > >many studies of vibrations, feedback mechanism, or other > >beamline-specific effects on data quality, and none discussing the > >spectral weight of the beamline-specific noise. > > > >On the other hand, all data interpolation schemes do some smoothing, > >which suppresses high frequency components. And it usually appears > >that the high-frequency estimate of the noise from chi_noise() or > >Feffit gives an estimate that is significantly *low*. > > > >Anyway, I think using the 'epsilon_k' that chi_noise() estimates as > >the noise in chi(k) is a fine way to do a weighted averages of data. > >It's not perfect, but neither is anything else. > > > >--Matt > > > >_______________________________________________ > >Ifeffit mailing list > >Ifeffit(a)millenia.cars.aps.anl.gov > >http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >

4 3

ARE: [Ifeffit] Re: Ifeffit Digest, Vol 5, Issue 1
by SCHLEGEL Michel 177447 07 Jul '03

07 Jul '03

Hello everyone, > > I would second Matt's reservations about averaging I0 for > > different XAFS scans. The main reason we record I0 is to > > compensate for fluctuations in I0, which are mirrored in > > If (statistically they are highly correlated) so the ratio > > If/I0 eliminates the variation (as long as the > detector chain is linear). > I totally agree. This can lead to big problems in the data. We > accidentally tried it once and then made sure that the > <If/Io> average was performed instead. I think the best way to do it statistically is to weight each individual XAS spectrum with 1/s^2, where s is an estimate of the noise in the spectrum. This makes sure that a noisy spectrum does not alter the overall quality of the fit . Of course, a simpler way to do it is to retain only the spectra of overall similar -and hopefully good - quality, and discard the noisy ones. I think an evaluation of the spectrum noise may be obtained from the FT contributions peaking at high 'distances' (e.g., > 10Å). Hence, with a correct script, we should be able to: - extract chi(k) functions from individual XAS spectra - perform FTs for these spectra, - perform inverse FT on the spectra over a given limit, and calculate s from that, - usecalculated s values to sum weight-average individual XAS spectra. As I'm a very lousy IFEFFIT user (means that I've stopped short from hitting buttons on Athena and Artemis), I would humbly ask Bruce if there's any chance to see such a methodology implemented on Athena one of these days (not in a hurry, though) Best regards, Michel Schlegel

4 7

Re: Ifeffit Digest, Vol 5, Issue 1
by Grant Bunker 03 Jul '03

03 Jul '03

I would second Matt's reservations about averaging I0 for different XAFS scans. The main reason we record I0 is to compensate for fluctuations in I0, which are mirrored in If (statistically they are highly correlated) so the ratio If/I0 eliminates the variation (as long as the detector chain is linear). In short <If/I0> is not equal to <If>/<I0> where < > indicates the average. thanks - grant On Thu, 3 Jul 2003 ifeffit-request(a)millenia.cars.aps.anl.gov wrote: > Send Ifeffit mailing list submissions to > ifeffit(a)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-request(a)millenia.cars.aps.anl.gov > > You can reach the person managing the list at > ifeffit-owner(a)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: your mail (Matt Newville) > 2. merging I0 (Bruce Ravel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 2 Jul 2003 16:20:47 -0500 (CDT) > From: Matt Newville <newville(a)cars.uchicago.edu> > Subject: [Ifeffit] Re: your mail > To: jshokes(a)sunchem.chem.uga.edu > Cc: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Message-ID: > <Pine.LNX.4.44.0307021605120.12464-100000(a)millenia.cars.aps.anl.gov> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Hi Jacob, > > Jacob Shokes (jshokes(a)chem.uga.edu) wrote: > > > I had a question I was hoping you could help me with. I have imported a > > bunch of ASCII type files into Athena and averaged them all together. The > > ASCII files contain the Energy, detector file, I0, I1, and I2. After I > > average the files together, I want to save the file and export it as an > > ASCII file. I understand how to do this, but when I do it I only obtain > > the Energy, [detector/IO], and background in column three (like it states > > in the manual). Now what I want to do, is extract the averaged I0 column > > from the process. Is there anyway to do this or will I just have to > > average I0 in another software. Any help with this would be appreciated. > > Sorry for the delay - I was away at the EXAFS conference, and am > still catching up on email. I hope it's OK that I forward this > question to the ifeffit mailing list, as others might have similar > questions, and Bruce Ravel might have a better answer. > > I believe you'd have to average all the I0 values yourself, and that > athena cannot do this easily. Bruce might correct me on this.... > It would be possible to do this using the Ifeffit commands directly > (including in the athena command window), something like this: > > read_data(mydat.001, group=a001, label='energy if i0') > read_data(mydat.002, group=a002, label='energy if i0') > read_data(mydat.003, group=a003, label='energy if i0') > ave.energy = (a001.energy + a002.energy + a003.energy ) / 3 > ave.if = (a001.if + a002.if + a003.if ) / 3 > ave.i0 = (a001.i0 + a002.i0 + a003.i0 ) / 3 > write_data(file= ave.dat, ave.energy, ave.if, ave.i0) > > In most cases I don't think you really want to do this, or use an > averaged I0 signal. For EXAFS data in transmission or fluorescence > (or electron yield), log(I0/I1) or IF/I0 can be averaged and merged, > but averaging I0 may not be meaningful. On the other hand, you might > be looking for typical I0 count rates, and the variations in I0, in > which case such averages might be useful. > > Hope that helps, > > --Matt > > > > > ------------------------------ > > Message: 2 > Date: Wed, 2 Jul 2003 17:55:43 -0400 > From: Bruce Ravel <ravel(a)phys.washington.edu> > Subject: [Ifeffit] merging I0 > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Cc: jshokes(a)sunchem.chem.uga.edu > Message-ID: <200307021755.43883.ravel(a)phys.washington.edu> > Content-Type: text/plain; charset="us-ascii" > > > Hi folks, > > As Matt suggested, I will take a stab at this question. > > > > I had a question I was hoping you could help me with. I have imported a > > > bunch of ASCII type files into Athena and averaged them all together. The > > > ASCII files contain the Energy, detector file, I0, I1, and I2. After I > > > average the files together, I want to save the file and export it as an > > > ASCII file. I understand how to do this, but when I do it I only obtain > > > the Energy, [detector/IO], and background in column three (like it states > > > in the manual). Now what I want to do, is extract the averaged I0 column > > > from the process. Is there anyway to do this or will I just have to > > > average I0 in another software. Any help with this would be appreciated. > > > I believe you'd have to average all the I0 values yourself, and that > > athena cannot do this easily. Bruce might correct me on this.... > > It would be possible to do this using the Ifeffit commands directly > > (including in the athena command window), something like this: > > Matt's suggeted sequence of raw ifeffit commands is certainly a fine > way of doing what Jacob asked for. Averaging I0 alone is not > something I had in mind when I designed Athena's basic interface > features, but it should be possible. > > As is the case when one tries to explain a sequence of mouse clicks, > this will be rather wordy. Sorry.... > > As all Athena users know, the first thing that happens when you import > a data file is to interact with the file selection dialog: > > http://leonardo.phys.washington.edu/~ravel/software/exafs/images/athena/col… > Athena remembers which columns were used to make the numerator and > denominator of the expression that constructs mu(E) from the column > data. (Note that the ability to make detector groups is lost once the > data are saved to a project file. Making detector groups is something > that must be done during the session in which the raw data are > imported.) > > In the Group menu is a option for "Make detector groups". This will > make entries in the Data groups list for the numerator and denominator > used to make the original data group. > > So my solution to Jacob's problem was to import data files one-by-one. > Each time, I made the detector groups. Once all the data was imported > and the detector groups were made, I marked the denominator groups (my > test data were all transmission, so I0 was in the denominator). Then, > in principle, one could select "Merge marked data in mu(E)" from the > Merge menu and have the merged I0 data that Jacob was looking for. > > *In principle*. In fact, there is a bug in the current version of > Athena and the merge of the I0 data failed. That bug will, however, > be fixed soon. Once that is done, it will be possible, albeit > inconvenient, to merge I0 data as Jacob wants. You may wish to try > working through the procedure that I described to understand how the > detector group feature of Athena works, even if the final step will > fail in the current version. > > B > > P.S. I am pretty certain that this will be fixed in time for the next > release of Athena and that the next release will be before Friday the > 11th. > > > -- > Bruce Ravel ----------------------------------- ravel(a)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(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > End of Ifeffit Digest, Vol 5, Issue 1 > ************************************* >

2 1

merging I0
by Bruce Ravel 02 Jul '03

02 Jul '03

Hi folks, As Matt suggested, I will take a stab at this question. > > I had a question I was hoping you could help me with. I have imported a > > bunch of ASCII type files into Athena and averaged them all together. The > > ASCII files contain the Energy, detector file, I0, I1, and I2. After I > > average the files together, I want to save the file and export it as an > > ASCII file. I understand how to do this, but when I do it I only obtain > > the Energy, [detector/IO], and background in column three (like it states > > in the manual). Now what I want to do, is extract the averaged I0 column > > from the process. Is there anyway to do this or will I just have to > > average I0 in another software. Any help with this would be appreciated. > I believe you'd have to average all the I0 values yourself, and that > athena cannot do this easily. Bruce might correct me on this.... > It would be possible to do this using the Ifeffit commands directly > (including in the athena command window), something like this: Matt's suggeted sequence of raw ifeffit commands is certainly a fine way of doing what Jacob asked for. Averaging I0 alone is not something I had in mind when I designed Athena's basic interface features, but it should be possible. As is the case when one tries to explain a sequence of mouse clicks, this will be rather wordy. Sorry.... As all Athena users know, the first thing that happens when you import a data file is to interact with the file selection dialog: http://leonardo.phys.washington.edu/~ravel/software/exafs/images/athena/col… Athena remembers which columns were used to make the numerator and denominator of the expression that constructs mu(E) from the column data. (Note that the ability to make detector groups is lost once the data are saved to a project file. Making detector groups is something that must be done during the session in which the raw data are imported.) In the Group menu is a option for "Make detector groups". This will make entries in the Data groups list for the numerator and denominator used to make the original data group. So my solution to Jacob's problem was to import data files one-by-one. Each time, I made the detector groups. Once all the data was imported and the detector groups were made, I marked the denominator groups (my test data were all transmission, so I0 was in the denominator). Then, in principle, one could select "Merge marked data in mu(E)" from the Merge menu and have the merged I0 data that Jacob was looking for. *In principle*. In fact, there is a bug in the current version of Athena and the merge of the I0 data failed. That bug will, however, be fixed soon. Once that is done, it will be possible, albeit inconvenient, to merge I0 data as Jacob wants. You may wish to try working through the procedure that I described to understand how the detector group feature of Athena works, even if the final step will fail in the current version. B P.S. I am pretty certain that this will be fixed in time for the next release of Athena and that the next release will be before Friday the 11th. -- Bruce Ravel ----------------------------------- ravel(a)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/

1 0

Re: your mail
by Matt Newville 02 Jul '03

02 Jul '03

Hi Jacob, Jacob Shokes (jshokes(a)chem.uga.edu) wrote: > I had a question I was hoping you could help me with. I have imported a > bunch of ASCII type files into Athena and averaged them all together. The > ASCII files contain the Energy, detector file, I0, I1, and I2. After I > average the files together, I want to save the file and export it as an > ASCII file. I understand how to do this, but when I do it I only obtain > the Energy, [detector/IO], and background in column three (like it states > in the manual). Now what I want to do, is extract the averaged I0 column > from the process. Is there anyway to do this or will I just have to > average I0 in another software. Any help with this would be appreciated. Sorry for the delay - I was away at the EXAFS conference, and am still catching up on email. I hope it's OK that I forward this question to the ifeffit mailing list, as others might have similar questions, and Bruce Ravel might have a better answer. I believe you'd have to average all the I0 values yourself, and that athena cannot do this easily. Bruce might correct me on this.... It would be possible to do this using the Ifeffit commands directly (including in the athena command window), something like this: read_data(mydat.001, group=a001, label='energy if i0') read_data(mydat.002, group=a002, label='energy if i0') read_data(mydat.003, group=a003, label='energy if i0') ave.energy = (a001.energy + a002.energy + a003.energy ) / 3 ave.if = (a001.if + a002.if + a003.if ) / 3 ave.i0 = (a001.i0 + a002.i0 + a003.i0 ) / 3 write_data(file= ave.dat, ave.energy, ave.if, ave.i0) In most cases I don't think you really want to do this, or use an averaged I0 signal. For EXAFS data in transmission or fluorescence (or electron yield), log(I0/I1) or IF/I0 can be averaged and merged, but averaging I0 may not be meaningful. On the other hand, you might be looking for typical I0 count rates, and the variations in I0, in which case such averages might be useful. Hope that helps, --Matt

1 0

a limitation of Athena, Artemis, and Ifeffit
by Bruce Ravel 17 Jun '03

17 Jun '03

Hi folks, An irritating limitation of the codes was just brought to my attention. My colleague here at NRL had his data file in a deeply nested folder and each folder name was long and descriptive. The end result was that the fully resolved file names (i.e. path and name) was many dozens of characters. When he tried to import these data into Athena, Athena failed silently. That is, Athena failed to import the data and failed to report a reason why. The reason is that there is, in ifeffit, a limit to the total number of characters for the fully resolved filename. My colleague, with his long, descriptive folder names, had exceeded this limit. In that situation, the current version of Athena (and Artemis, as well) fails silently. In the next versions of the codes, they will issue a warning if your fully resolved filename is too long. For the moment, however, the best I can do is to make you all aware of the problem and to suggest either short folder names or placing your data high up in the file tree. Regards, B -- Bruce Ravel ----------------------------------- ravel(a)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/

1 0

athena 0.8.020 and artemis 0.6.005
by Bruce Ravel 16 Jun '03

16 Jun '03

Hi folks, Just in time for the XAFS conference, I am announcing new releases of Athena and Artemis. There are not many major new features this time, but there is a long list of bug fixes and usability enhancements. If you have not yet upgraded to Ifeffit 1.2.1, you should do so, then download the latest versions of my codes. As always, new source code tarballs and windows executables can be found on my downloads page. For those Windows users new to the mailing list, I'll explain how to install the new executables. It's quite simple. Grab the .exe files from my downloads page and drop them in the C:\Program Files\Ifeffit\ folder on top of the old versions. If you installed to some other location, then drop th new executables there. Doing this is enough to leave the desktop and Start Menu icons functional. The one major new feature in Artemis is the ability to set restraints on your parameters. It's as simple as setting a math expression on the "Guess. Def, Set" page and flagging the parameter as a restraint. The restraint defined this way will then be used in the fit. If you are interested in using restraints, you should read the following: http://cars9.uchicago.edu/ifeffit/refman/node55.html http://cars9.uchicago.edu/xafs/Advanced_Methods/BNLworkshop2001/newville.pdf There is an example project file using a restraint in the source code tarball which follows very closely the restraints example from the ifeffit source code tarball. There really are a lot of improvements this time around and it is well worth updating. Check out the change logs on my web site for all the details. The acknowledgment list is a long one this time. Among those with helpful bug reports and good suggestions: Scott Calvin, Vince Harris, Dale Brewe, Adam Webb, Mark Jensen, Paul Fons, and Grazia Proietti. Thanks to all of you. The award for the loopiest suggestion which I had no good reason to refuse goes to Mark Bondin, who wants to use Athena for background removal and Xfit for data analysis! B P.S. There are a few of you who have expressed an interest in using Artemis to analyze your DAFS data. It was pointed out to me that I had forgotten to include the dphase path parameter in Artemis. That has been fixed, although the dphase parameter is hidden along with the k_array, amp_array, and phase_array path parameters. If you want to use dphase or any of the other three "hidden" parameters, go to the Paths menu and click on the button at the bottom of the menu that reads "Extended path parameters". When you click it on, text boxes for dphase and the _array path parameters will be displayed on the paths page in Artemis. P.P.S. I am giving a poster about Athena and Artemis at the XAFS conference. My time is Wednesday during the 16.15 to 17.45 session. If you'll be at the conference, stop by and say hi. I'd enjoy meeting those of you I don't already know and would enjoy catching up with those I do. -- Bruce Ravel ----------------------------------- ravel(a)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/

1 0

XAFS 12
by Matt Newville 07 Jun '03

07 Jun '03

Hi Everyone, Many people on this list will be at the upcoming XAFS 12 conference, and have probably seen the notice for the microsymposium on XAFS analysis programs. Bruce will talk about the 'Ravelware', I'll talk about Ifeffit etal, and several real luminaries in the field will talk about XAFS and XANES analysis. The conference is a great chance for many informal discussions about the ifeffit programs. At this point, there are many possible directions for development and improvement and I (and I assume Bruce and Sam) would love to hear feedback on what the priorities for new functionality and development should be. It might be good to set aside a lunch time (or beer-time?) to talk about development priorities. I'd tenatively pick Thursday lunch (after the analysis symposium and most posters/talks to be able to learn some things from the conference), but maybe we can finalize the time and place at the Tuesday evening analysis symposium. A few possible topics of discussion are 'Installation on MacOS X' and 'Getting GUIs that run Feff6', but there may be other issues. If you're interested, please feel free to join the discussion, and see you in Malmo! --Matt

1 0

ifeffit 1.2.1
by Matt Newville 28 May '03

28 May '03

Hi again, Well, it was supposed to be the 'stable' release, but a few large bugs were noticed quickly in ifeffit 1.2.0: - Feff6L didn't make it past the pathfinder before dying. - some of the output arrays for feffit() with multiple k-weights were still messed up. These turned out to be easy to track down (and the Feff problem was all mine -- not native to Feff!!!), so I fixed these to make version 1.2.1 (both source and Window exe), which is now available at http://cars.uchicago.edu/ifeffit/download.html and at Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=80919&release_id=1603… It usually takes a day for Sourceforge's mirrors to get new files. Since this is supposed to be the 'stable' version, I don't intend to be making releases every 5 days. These problems were big and easy to fix, and I'll be away for a week so thought I should post these now. Really, it will calm down. As others have suggested, I like the idea of being able to update the individual files (athena.exe, ifeffit.dll, feff6l.exe) to an already-installed Windows tree. It should be fairly easy to write a program that looks at some webpage for a zip file with the changes since version "1.2.X" and update the needed files. --Matt

5 10