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

RE: [Ifeffit] starting artemis
by Kelly, Shelly D. 09 Jun '04

09 Jun '04

-----Original Message----- From: doug pease [mailto:dougpease@comcast.net] Sent: Wednesday, June 09, 2004 6:57 AM To: ifeffit(a)millenia.cars.aps.anl.gov Subject: [Ifeffit] starting artemis Hello All, My oversight not specifying the platform. When the ATOMS in ARTEMIS fills up the whole screen and the run button is off screen I am in Windows XP. I also have a - perhaps non standard - ViewSonic flat screen monitor, for what that is worth. Carlo, thank you for your interest. Do you or anyone else have a suggestion? Overnight I thought of perhaps trying to change my monitor settings to shrink my monitor display?? Sincerely, Doug Pease Hi Doug, If you can, you should increase the resolution of the display. On a win2k machine you go to the control panel and choose the Display icon. >From there you can increase the resolution by going to the setting tab and increase the screen area to be 1280 by 1024 pixels. (-I think that winXP should be similar.:) Shelly

1 0

beginning with ARTEMIS
by doug pease 09 Jun '04

09 Jun '04

Hello All, Just starting ARTEMIS for first time. Seems o.k. until I come to the place where I am to run ATOMS in ARTEMIS. The ATOMS view in ARTEMIS takes up the whole monitor screen and the button for running ATOMS is out of site. I cannot drag the view high enough to reveal the ATOMS run button. Any suggestions? Sincerely, Doug Pease

2 1

Re: [Ifeffit] more fun with FFTs
by Scott Calvin 08 Jun '04

08 Jun '04

First of all, thanks to Matt for the info--this seems to me to be a very sensible way for Ifeffit to handle the issue. In terms of Grant's comments, the interesting part to me (and I admit I am getting esoteric here) is that zero-padding has the potential to change the cutoff effects in some circumstances. If you're using a window that goes to zero anyway, then I think it has exactly the effect that Grant describes. But not all windows do this. As a particularly simple example, consider a perfect cosine function over an integer number of periods, with no window. Even though the transform is applied to a finite interval, the result is a spike to within the resolution discussed in Grant's post. (As I recall, the finite sampling also causes the transform to be periodic, but the period is large enough to be disregarded in EXAFS analysis.) But now consider the identical function over the identical interval with zero-padding. This introduces a sharp discontinuity, and causes lots of sidebands on the Fourier transform. Of course, I chose a very special case. Windows reduce this effect considerably, so I would certainly agree that zero-padding does not "botch up" the data. But I wonder if some reduction in sidebands could be achieved by, for example, using a window that goes to the average of the values of the function at the two ends of the interval rather than to 0 (and adjusting the windowing function accordingly). It's on my list of things to try when I get the chance...I don't expect it will make a dramatic difference, but it might make an incremental one. --Scott Calvin Sarah Lawrence College At 12:34 PM 6/8/2004 -0500, Grant wrote: >You might ask whether zero padding botches up the data. It can be shown >(I worked it out once) that zero padding is exactly equivalent to >an interpolation of the unpadded data witha specific interpolation kernel >(a sinc function or something as I recall). What happens is that as you >pad with more zeros into a longer array, the sampling in r-space increases, >and ultimately the curve looks just like what you would get with a continuous >fourier transform (with cutoff effects from the finite k-space window). >

1 0

more fun with FFTs
by Grant Bunker 08 Jun '04

08 Jun '04

Just to amplify Matt's remarks - the purpose of padding with zeros is to deliver a finer grid in r-space. There is a relationship between the r-space grid dr, the k-space grid dk, and the number of points in the array (N): N dk dR = Pi. So, for a k-space grid of .05/A and 2048 points, you get an r-grid spacing of .0307 A. This gives pretty good sampling of the fourier transform. If you only use say 256 points in your array (i.e. you don't pad with zeroes) the r-space sampling is .245 A, which is too coarse to be useful. You might ask whether zero padding botches up the data. It can be shown (I worked it out once) that zero padding is exactly equivalent to an interpolation of the unpadded data witha specific interpolation kernel (a sinc function or something as I recall). What happens is that as you pad with more zeros into a longer array, the sampling in r-space increases, and ultimately the curve looks just like what you would get with a continuous fourier transform (with cutoff effects from the finite k-space window). grant On Tue, 8 Jun 2004 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: FFT in Ifeffit (Matt Newville) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Jun 2004 22:55:28 -0500 (CDT) > From: Matt Newville <newville(a)cars.uchicago.edu> > Subject: Re: [Ifeffit] FFT in Ifeffit > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Message-ID: <Pine.LNX.4.44.0406072214290.13810-100000@corvette> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Hi Scott, > > All Fourier transforms in Ifeffit use arrays of length 2048, > padding with zeros as needed. > > In earlier versions of Feffit, doing repeated FTs in the fitting > loop was noticeably slow. This is probably one of the reasons > fitting in R-space was uncommon. Anyway, using arrays of length > N_fft = 1024, 512, or 256 definitely helped speed things up. > > In principle, one could use N_fft ~= N_idp, but it turns out that > if you use too few FT points, you can easily get into a real > 'false, local, minima'. So Feffit used 1024,512,or 256 for fits, > and then go back to 2048 to write out the data. Strictly speaking, > the FFT doesn't need to use an array size that is a power of 2, > but it turns out to make a very noticeable difference with the FFT > routines used. > > With Ifeffit, several "anti-optimizations" were made that make > the fits slightly slower but be more straightforward and simple > (relatively speaking, anyway!). The use of double precision and > N_fft=2048 being the main examples. Part of the reason for > sticking with 2048 is that you want to be able to view the data at > any point in the process so 'pretty output' is always needed. > Also, I doubt many people will be trying to run artemis on a 386 > or a microVAX. > > --Matt > > > As I was working on my talk for the EXAFS workshop, I came across a > > rather technical question: how does Ifeffit choose the number of > > points for the Fourier transforms? As I recall, FEFFIT used an > > algorithm which required an integer power of 2, so its default > > behavior was to use the smallest integer power of 2 greater than the > > number of points in the chi(k) data, and then pad the rest with 0's. > > This default behavior could also be over-ridden if desired. > > > > It doesn't look to me like Ifeffit is handling that in the same > > way--is it always using a very large number of points and padding > > with 0's, or is it using an algorithm that doesn't require the > > integer power of 2, or is it interpolating the chi(k) on to a grid of > > the appropriate size first, or...? > > > > I appreciate any info you can give me on this. > > > > --Scott Calvin > > Sarah Lawrence College > > _______________________________________________ > > Ifeffit mailing list > > Ifeffit(a)millenia.cars.aps.anl.gov > > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > > > > ------------------------------ > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > End of Ifeffit Digest, Vol 16, Issue 7 > ************************************** >

1 0

Re: [Ifeffit] Using more than one E0
by Scott Calvin 08 Jun '04

08 Jun '04

Hi Wojciech, I have another suggestion. It is my secret, completely untested belief (which I am now revealing to everyone on this mailing list!), that some of the cases of "successful" fits using multiple E0's are masking problems caused by not considering a third cumulant. For those who may not know the role of this parameter, it in essence measures asymmetry in the distribution associated with a path. For example, if a pair of atoms are more likely to separated by a distance considerably larger than the mean separation than by a distance considerably smaller than the mean separation, then the third cumulant is positive. (The mathematical definition is that the third cumulant is the mean cube of the difference from the mean, in the same sense that sigma2 is the mean square of the difference from the mean.) In most cases, the third cumulant is small. Nevertheless, if it were 0 in all cases, then materials would not show any expansion with temperature! Through symmetry arguments, it is pretty clear that the third cumulant is most likely to be significantly nonzero for nearest-neighbor paths. What does this have to do with fitting different E0's? E0 and the third cumulant both affect the phase of the EXAFS signal, although they are weighted in different ways by k. Nevertheless, if a nonzero nearest-neighbor third cumulant is called for, allowing a different E0 for the nearest-neighbor instead would probably also improve the fit statistically. In this case, however, while the use of a third cumulant can be justified on physical grounds relatively easily, the use of a separate E0 is an arbitrary non-physical attempt to improve the statistics. So as far as I am concerned, I am more inclined, if my fit is not quite working out, to try allowing the third cumulant for paths in the first coordination shell to vary than I am to introduce multiple E0's. In fact, I usually do this at some point during the fitting process even if my fit is behaving fairly well to reassure myself that the third cumulant is 0 to within the uncertainty of the fit, and that constraining it to 0 is not distorting the values of the parameters I am interested it. Take all of this with a grain of salt; I wrote my dissertation on the third cumulant, and, to paraphrase Bruce, since I've spent a lot of time making a nice hammer, everything tends to look like a nail... --Scott Calvin Sarah Lawrence College > >I would like to address a couple of questions which are partially >related to my recent struggles in fitting some EXAFS data. I'm >trying to fit my data using several shells of different neighbors >including a few single scattering paths and also so multiple >scattering contributions (mainly collinear multiple scattering >paths) all calculated with the help of FEFF 8.20. Now, I found once >in the FEFFIT manual the following suggestion: one might consider >using several different E0's for different paths in order to improve >the fit. Ok, the explanation was based on some approximations coming >from FEFF code which include incomplete core-hole shielding, lack of >angular variations of the valence charge distribution and charge >transfer between atoms in polar materials. >My question is the following: does anyone of you have some >experience with such procedure? And if yes, shall than distinguish >between the first shell of nearest neighbors and the rest of the >atoms in terms of their E0 corrections (using 2 parameters)? Or >perhaps one can use separate E0's for each path?

3 6

trouble with Atoms on Mac OSX
by Michel Jaouen 04 Jun '04

04 Jun '04

Hi folks, I'm using a PM (2X1.8 MHz processors) under OSX v 10.3.4 (Panther latest version). I have installed ifeffit-1.2.5a two weeks ago and used Atoms many times since. It works well till yesterday when I loose the ability to use the space group browser with an error reported on the herre attached file. It looks that I have a problem with Tk, but I don't understand why. I have tried to make a new install from scratch after putting in the trash the ifeffit and perl (the one I assume to be put by the iffit installer in the home/lib folder): it didn't fix the problem. I found rather puzzling to find several perl folders (one coming from ifeffit and one from Fink). Looking my environnement, I found the following: PERL5LIB=/sw/lib/perl5:/sw/lib/perl5/darwin. I therefore modify my profile making a setenv to force to use the perl from ifeffit without any change. So it seems some hidden file is responsible of this behavior. I must say that if I enter the space group by hand, Atoms runs (e.g. it creates the feff.inp file). If anybody has a solution, I will appreciate. Additional point: I have compliled feff7 using the GNU g77 from Fink, but it stops the run with a segmentation fault. Any hint? Best regards Michel -- __________________________________________ Michel Jaouen Universite de Poitiers - UFR Sciences - SP2MI LMP UMR 6630-CNRS Boulevard Pierre et Marie Curie - Teleport 2 BP 30179 86962 Futuroscope - Chasseneuil Cedex France Tel : (33) 5 49 49 67 37 Fax : (33) 5 49 49 66 92 e-mail : Michel.Jaouen(a)univ-poitiers.fr __________________________________________

3 2

Debian packages
by Carlo U. Segre 04 Jun '04

04 Jun '04

Hello All: I have now packaged the latest horae (036) for Debian stable and unstable. There was a problem in previous versions for stable which I just now figured out how to fix and it involved making a back port of a newer perl module for the archiving/zipping of the project files. Sorry if this caused anyone problems. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre(a)iit.edu http://www.iit.edu/~segre

2 1

trouble with Tk on Mac OSX
by Michel Jaouen 03 Jun '04

03 Jun '04

Hi folks, I think somethings is broken with Tk. As reported in my previous e-mail I found a problem (I have not before 1st june!) with the space group browser of Atoms. In fact I have the same error with Artemis when pressing the fit button! The following message was trapped by Artemis: Artemiswarn/Users/mjaouen/.horae/stash/ARTEMIS.TRAPCODE(0x1e18a84) at /Applications/Ifeffit/bin/artemis line 1491 main::__ANON__('Tk::Error: unknown option "background" at /Library/Perl/ 5.8.1...') called at blib/lib/Tk.pm (autosplit into blib/lib/auto/Tk/Error.al) l ine 488 Tk::Error('MainWindow=HASH(0x61e5d8)','unknown option "background" at /Library/Perl/5.8.1/darwin-thr...','Tk callback for .sgb.frame','Tk callback for . sgb.frame.ysbslice','Tk callback for .sgb.frame.ysbslice.corner','Tk callback for ..sgb','Tk callback for .sgb.button1','Tk callback for .frame.menubutton5.menu', 'Tk::__ANON__ at /Library/Perl/5.8.1/darwin-thread-multi-2leve...',...) called at /Library/Perl/5.8.1/darwin-thread-multi-2level/Tk.pm line 406 eval {...} called at /Library/Perl/5.8.1/darwin-thread-multi-2level/Tk.pm line 406 Tk::MainLoop() called at /Applications/Ifeffit/bin/artemis line 1627 What makes me crazy is that all was running smoothly before tuesday :-) Cheers Michel -- __________________________________________ Michel Jaouen Universite de Poitiers - UFR Sciences - SP2MI LMP UMR 6630-CNRS Boulevard Pierre et Marie Curie - Teleport 2 BP 30179 86962 Futuroscope - Chasseneuil Cedex France Tel : (33) 5 49 49 67 37 Fax : (33) 5 49 49 66 92 e-mail : Michel.Jaouen(a)univ-poitiers.fr __________________________________________

2 1

news
by Bruce Ravel 02 Jun '04

02 Jun '04

Hi everybody, Today I made another new release of the source code tarball and built a new Artemis executable for windows. Users of each of the three major platforms should read the notes below for information about this release. This will be the last release for a while. June and July will be very busy for me and I will have scant time to work on the codes until August at the earliest. I will be reading bug reports and suggestions and will address them when I get back to work on the codes -- so please continue to send them in. Hopefully whatever bugs are lurking in there will not prove too difficult to work around. This release attempts to fix a problem managing the project folder in Artemis, as reported by Stefano Ciurli. The new version works correctly for me, your milage may vary. If any of you will be at the ISSRNS conference in Zakopane Poland next week, please introduce yourself! I hope everyone has a great summer! (Or a great winter for those of you in the southern hemisphere!) B -------------------- O -------------------- Notes for each of the platforms follow: Linux (and other non-Mac OSX unixes): The source code tarball is on SourceForge and on my web site. If the horae_update script fails, try using the --mirror argument as described in the help text (horae_update -h). Mac OSX: There was no time to make a new installer package. For the time being, you can use the most recent installer package, then update to the latest source code tarball from the command line. This requires downloading the source tarball from SourceForge and unpacking it. Then, from the command line, type "perl Makefile.PL" then "make" then "sudo make install". The last step will prompt for the administrator password. If you run into trouble, ask on the mailing list and one of the Mac users should be able to help you. Windows: There was no time to prepare a new updater package for windows. Virtually all of the changes in my codes since the last updater package have been bug fixes to Artemis. So I have made a new Artemis executable and placed it here: http://leonardo.phys.washington.edu/~ravel/software/exafs/packages/artemis_… If you are up to date with the most recent updater package, just download this executable and overwrite the "artemis.exe" file in the instalation directory: "C:\Program Files\Ifeffit" (or where ever you have ifeffit installed on your computer). -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 405 Naval Research Laboratory phone: (1) 202 767 2268 Washington DC 20375, USA fax: (1) 202 767 4642 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

trap file
by Stefano Ciurli 01 Jun '04

01 Jun '04

Hi Bruce, I installed the new horae (035) and played around with the ZnO tutorial using the new version of Artemis. I called the program in the directory where the ZnO dat file reside from the command line. The project apj1 (run with all the indications in the journal) worked smoothly. As soon as I try to read in the apj2, the following trap message pops up: # Artemis 0.7.005 # This file created at 00:19:09 on 31 May, 2004 # using darwin, perl 5.008001, Tk 804.027, and Ifeffit 1.2.5 # Workspace: /Users/stefano/.horae/stash/artemis.project.3/ The following message was trapped by Artemis on a SIGWARN: Artemis0.7.005warn/Users/stefano/.horae/stash/ARTEMIS.TRAPCODE(0x1e3dff8)/Users/stefano/.horae/stash/artemis.project.3/ at /Applications/Ifeffit/bin/artemis line 1562 main::__ANON__('Tk::Error: could not open /Users/stefano/.horae/stash/artemis...') called at blib/lib/Tk.pm (autosplit into blib/lib/auto/Tk/Error.al) line 488 Tk::Error('MainWindow=HASH(0x8f44c)','could not open /Users/stefano/.horae/stash/artemis.project.3/...','main::nnnn_header at /Applications/Ifeffit/bin/artemis line 4386','main::read_path at /Applications/Ifeffit/bin/artemis line 10872','main::open_project at /Applications/Ifeffit/bin/artemis line ...','main::read_data at /Applications/Ifeffit/bin/artemis line 6901','main::dispatch_read_data at /Applications/Ifeffit/bin/artemis...','main::__ANON__ at /Applications/Ifeffit/bin/artemis line 586','Tk callback for ..frame.menubutton.menu.project_data',...) called at /Library/Perl/5.8.1/darwin-thread-multi-2level/Tk.pm line 406 eval {...} called at /Library/Perl/5.8.1/darwin-thread-multi-2level/Tk.pm line 406 Tk::MainLoop() called at /Applications/Ifeffit/bin/artemis line 1707 End of trap file. Exactly the SAME error message pops out when I try to save a fit as chi(k). Obviously I am stuck... Any help here? Again, there must be some problem with the perl libraries... HELP!!! Stefano -- ____________________________________________ Stefano Ciurli Professor of Chemistry Department of Agro-Environmental Science and Technology University of Bologna Viale Giuseppe Fanin, 40 I-40127 Bologna Italy Phone: +39-051-209-6204 Fax: +39-051-209-6203 "Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza" Dante Alighieri - Inferno - Canto XXVI -- ____________________________________________ Stefano Ciurli Professor of Chemistry Department of Agro-Environmental Science and Technology University of Bologna Viale Giuseppe Fanin, 40 I-40127 Bologna Italy Phone: +39-051-209-6204 Fax: +39-051-209-6203 "Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza" Dante Alighieri - Inferno - Canto XXVI

3 7