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

Fwd: Line stlye in Artemis
by Bruce Ravel 24 Nov '03

24 Nov '03

> I am using Athena and Artemis to analysis my EXAFS data. I want to > plot the raw data in dashed line and the fitting in solid line. I > tried "settings","plot" selections in Artemis(version 1.2.4), but no > line style choice is available. Can you please tell me how to change > the settings? > -Chuanyong Jing Chuanyong, I am taking the liberty of replying to your email via the Ifeffit mailing list. There is currently no ability to change the linestyle in Artemis. Sorry. It would be resonable to have separate linestyles for the data, the fit, and the other components of the fit (i.e. background and paths). I will put that on the list of things to do. I should point out that I consider the graphics in Artemis and Athena (that is the pgplot graphics that are provided via ifeffit) to be for quick-n-dirty, on screen plotting. I don't make any great effort to provide graphics that are beautiful enough for publication. For that, I think it is better to export the components of the desired plot to column data files and use a program (Origin, Kaleidagraph, Igor, XMGrace, SciGraphica, or whatever) that is intended for making beautiful, publication-quality plots. The level of graphical sophistication that one expects for publication is beyond the scope of what Artemis and Athena are intended to do. Still, your request for different line types is a reasonable one and I will implement it eventually. Ragards, 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 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

Some direction
by H H 23 Nov '03

23 Nov '03

Since, I am new in doing XAFS fitting, I hope some one just direct me little bit. In order to my fitting, I always filter each individual shell and then fit the back scattering. When I do that I get a good result. However, after I fit each individual shell and get R and Sigma^2, then I try to combine the shells together. The resultant spectrum does not match the fit. Do I have to combine the shells together after I fit each one individually or it is possible to do each one by its own? __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

2 1

Re: [Ifeffit] Re: a question about EXAFS fitting result
by SCalvin100＠aol.com 12 Nov '03

12 Nov '03

My two cents (understanding that we have no specifics on Steven's particular sample): This particular comparison to a standard would make me exceedingly nervous as a general rule. Any sample which has a coordination 5/9 of the empirical standard is hardly a minor variation on the standard. And since the DW factor is likely to correlate highly to coordination number for a single-shell fit, part of an apparent change in coordination number might actually be due to a change in DW factor. Again, without knowing the details of the project, or even Bruce's reply as to what happened with the cobalt foil, I highly recommend analyzing more than just the nearest neighbor when trying to determine coordination number. For example, average coordination number for the first shell is theoretically reduced in nanoparticles, but due to other effects this is a highly unreliable measure of particle size. When the effect of scattering off of neighbors beyond the nearest is included, however, Anatoly Frenkel (among others) has demonstrated that particle size can often be determined with reasonable accuracy. --Scott Calvin Sarah Lawrence College In a message dated 11/12/03 8:45:45 AM Eastern Standard Time, ravel(a)phys.washington.edu writes: > I am analyzing cobalt. As I spoke with you before, I got the > coordination number of cobalt foil as around 9 instead of 12. You > explained me why it can happen. What I want to know is If we got > coordination number as 5 for a sample we are interested in and got > the cobalt foil coordination number as 9, can I proportionally > correct the value? (Consider 9 as 12 and multiply 5 by the ratio) Or > just disregard the foil's coordination number? Could you please let > me know what would be the better way to get the correct value? Steven, This is the sort of question for which we created the mailing list, so I am forwarding it and my brief answer there. If you are not already subscribed, you might find it useful to do so. The simple answer is "probably". The point of measuring a standard under identical conditions to the sample is to recognize any systematic effects in the measurement, the smaple, the detectors, or the theory. If all else besides the sample is equal, then you can probably make the argument you suggest above. It will be, of course, incumbant upon you to convince your reader that what you did was reasonable when you publish. You most certainly CANNOT cite "Bruce Ravel, private communication" as your justification!!! That said, if you want more specific help from the crowd on the mailing list, you may wish to provide some more specifics about the details of your problem.

1 0

RE: [Ifeffit] testing ravelware
by Kelly, Shelly D. 12 Nov '03

12 Nov '03

Hi Matt, > Hi Shelly, > > > > Bruce says: > > > P.S. Once again, on the topic of how people can contribute to the > > > ifeffit project without writing code, volunteering > to conceive of > > > a battery of tests and then actually running them would be an > > > excellent contribution. Any takers? > > > > I would think that someone would want to write a perl script to > > execute a bunch of Athena/Artimis commands and then check > the results. > > Then have the script write out a report. (Kind of like what tkperl > > does when you do install the software?) Can Athena/Airtimes > commands > > be executed from a script? If someone was willing to > figure out how > > to do this for one or two of the commands, I would be > willing to extend it to the rest. > > Testing ifeffit commands with the Ifeffit perl module is > definitely possible. That may miss some artemis/athena > capabilities and potential problems, but would still be > useful. You could certainly emulate much of athena's > functionality into perl scripts to do background subtraction, > FFTs, and merging of data with a wide range of parameters and > data sets. > > A script like the simple one below might be pretty good place > to start. (This could be done in languages other than perl > and English). There is also a test.pl with the ifeffit > source perl module (I think it's called t/ifeffit.t in > horae), which mostly tests passing of data between perl and > Ifeffit. Since the script below essentially runs an ifeffit > script, there are several test/example scripts in the > examples/ folder that could be used as the basis of other tests. > > The main difficulty is deciding when the analysis or > calculated values are "right", which makes detecting problems > hard to automate. > > If anyone wants more pointers on how to use the ifeffit from > scripts (perl, python, tcl, ...), please let us know. > > --Matt > > #! /usr/bin/perl > use Ifeffit; > use Ifeffit qw(get_scalar); > > my $xmu_file = "a.xmu"; > my $expected_e0 = 8980.0; > my $toler = 0.5; > > print "Test Finding E0 for $xmu_file: "; > > my $script =<<"END"; > read_data(file = $xmu_file, prefix = my, type = xmu) > pre_edge(my.energy, my.xmu) > END > > $ret = ifeffit($script); # should test $ret for errors. > $e0 = get_scalar("e0"); > print " found $e0, which is "; > > if ( abs($e0 - $expected_e0) le $toler) { > print "ok\n"; > } else { > print "outside of expected range\n"; > } > > ##---- end test_e0.pl This is the kind of script is what I had in mind. As you mentioned this script checks ifeffit directly. I would like to extend it so that Athena is checked. Does anyone know how to do that? This makes me think that if one was cleaver about the way that the test is written that it could be done to check both Athena and/or Ifeffit. That would make the tests more general diagnostic tools. Shelly

5 9

Re: a question about EXAFS fitting result
by Bruce Ravel 12 Nov '03

12 Nov '03

On Tuesday 11 November 2003 04:21 pm, Steven Sangyun Lim wrote: > I am analyzing cobalt. As I spoke with you before, I got the > coordination number of cobalt foil as around 9 instead of 12. You > explained me why it can happen. What I want to know is If we got > coordination number as 5 for a sample we are interested in and got > the cobalt foil coordination number as 9, can I proportionally > correct the value? (Consider 9 as 12 and multiply 5 by the ratio) Or > just disregard the foil's coordination number? Could you please let > me know what would be the better way to get the correct value? Steven, This is the sort of question for which we created the mailing list, so I am forwarding it and my brief answer there. If you are not already subscribed, you might find it useful to do so. The simple answer is "probably". The point of measuring a standard under identical conditions to the sample is to recognize any systematic effects in the measurement, the smaple, the detectors, or the theory. If all else besides the sample is equal, then you can probably make the argument you suggest above. It will be, of course, incumbant upon you to convince your reader that what you did was reasonable when you publish. You most certainly CANNOT cite "Bruce Ravel, private communication" as your justification!!! That said, if you want more specific help from the crowd on the mailing list, you may wish to provide some more specifics about the details of your problem. 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 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: [Ifeffit] testing ravelware
by Kelly, Shelly D. 10 Nov '03

10 Nov '03

Bruce writes: If enough people volunteered to check out some aspect of the code each time a new release comes out, then no one would actually have to do that much work [5]. Indeed, a network of use testing volunteers could be incorporated into the release process such that a version does not get released until the problems the testers uncover get fixed. Okay Bruce, I will volunteer to test part of Athena. I will work on whatever part you think would be the most helpful, assuming [5] from your previous message. Shelly

2 1

Tk804.025_beta, update
by Bruce Ravel 08 Nov '03

08 Nov '03

Hi folks, I just wanted to leave you all with an update as to the issue raised earlier this week by Joon and Paul regarding the use of perl/Tk 804.025. This message concerns linux and unix users and OSX users who know how to build everything from source. This is not an issue for Windows users because I have built the executables for the programs using an version of perl/Tk taht is not effected by the problems I will discuss below. The version of perl/Tk currently being distributed at www.cpan.org is version number 804.025_beta5. If you go to the CPAN website or use the CPAN interface to install perl/Tk from the command line, you will end up downloading that version of perl/Tk. In response to mail from Joon and Paul, I downloaded and installed that version of perl/Tk and have come to the conclusion that it is too unstable to be reliably used with Athena and Artemis. One of the problems raised by Joon and Paul was, in fact, my own bug. However, there are several other serious problems that are bugs in perl/Tk 804.025 and so are out of my control. For the foreseeable future, I urge everyone to use an older version of perl/Tk -- 800.024. I keep a copy at my web site: http://leonardo.phys.washington.edu/~ravel/misc/Tk-800.024.tar.gz Athena and Artemis are very well tested against this version and do not require any of the functionality offered by the more recent version of perl/Tk. I will keep my eye on the development of perl/Tk and let people know when I think it is acceptible to upgrade to the more recent version (which will have some nice features, such as unicode support allowing e.g. Japanese speakers to keep their project journals in Japanese). I hope this hasn't been too confusing for anyone and I want to again thank Joon and Paul for their input as I worked through this issue. 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 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/

2 1

RE: [Ifeffit] testing ravelware
by Kelly, Shelly D. 07 Nov '03

07 Nov '03

> Bruce says: > P.S. Once again, on the topic of how people can contribute to the > ifeffit project without writing code, volunteering to conceive of > a battery of tests and then actually running them would be an > excellent contribution. Any takers? I would think that someone would want to write a perl script to execute a bunch of Athena/Artimis commands and then check the results. Then have the script write out a report. (Kind of like what tkperl does when you do install the software?) Can Athena/Artimis commands be executed from a script? If someone was willing to figure out how to do this for one or two of the commands, I would be willing to extend it to the rest. Shelly

2 1

Carlo's problem with wurtzite
by Bruce Ravel 07 Nov '03

07 Nov '03

Hi folks, Last week Carlo posted a problem he was having with a hexagonal space group. He was getting different results when entering data directly into TkAtoms than when he saved the input data and reread it into TkAtoms. I finally found the source of the problem. All output files in TkAtoms are formatted according to "template files". The reason these template files exist is to make it easy for the user to tweak the appearence and content of the files Atoms writes out. Unfortunately there is a bug in the template that is used to save the input data to an atoms.inp file. In Carlo's example, one of the atoms was at the position (1/3,2/3,0). When Atoms save the data, it saved that position as (0.3333,0.3333,0), i.e. with four digits of precision. It turns out that Atoms considers *five* digits of precision, so it was not recognizing that 0.3333 was meant to represent 1/3. This lead directly to the problem that Carlo reported. Eventually Carlo was able to explain this to me in a way that made it into my very dense skull! ;-) This problem will be fixed in the next release of Atoms. Anyone who wants to fix this problem beforehand, here are the simple instructions: unix people: 1. Copy the atoms.atp file to your ~/.atoms/ directory. (Create it if it does not already exist.) The atoms.atp file will be found in someplace like /usr/lib/perl5/site_perl/5.8.0/Xray/atp/ 2. Edit ~/.atoms/atoms.atp and change the precision in the first non-comment line from 8.4 to 9.5. 3. Save the file and fire up TkAtoms. Should work now. windows people: 1. Using WordPad or NotePad, edit the file C:\Program Files\Ifeffit\perl\Xray\atp\atoms.atp 2. Change the precision in the first non-comment line from 8.4 to 9.5. 3. Save the file and fire up TkAtoms. Should work now. There is a moral to this story. Atoms handles numerical precision in a quirky manner. If it is possible to use a factional representation of a number, do so. (I.e. always use "1/3" rather than 0.33, 0.333, 0.3333, or 0.33333 -- even though the last one will, in fact, work correctly.) Thanks to Carlo for finding this problem and to Peter for a valient if unsuccessful stab at solving the problem. Thanks guys! 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 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/

2 1

Carlo's problem with wurtzite
by John J. Rehr 06 Nov '03

06 Nov '03

Hi everyone, We encountered a similar problem with the default atoms precision of 5 digits for the Ti-omega phase structure. For that structure atoms gave different results for the Wyckoff coordinates: 1/3 2/3 1/2 and ..3333 .6666 .5 This (apparently) confused the degeneracy checker in atoms causing atoms to print out pairs atoms at nearly identical points. Although there may be cases where a difference between say 0.67 and 2/3 is a significant distortion, I think it's very rare that crystallographic parameters are known to better to 4 digits. Thus I'm wondering whether reducing the precision that atoms demands of a user might be advantageous. J. Rehr

1 0