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

newcomer's simple trouble
by Stefano Ciurli 12 May '04

12 May '04

Hello, this is a more intelligent input file which still gives the same error: Stefano TITLE Ni(H2O)6 HOLE 1 1.0 * Ni K edge (8333.0 eV), second number is S0^2 * mphase,mpath,mfeff,mchi CONTROL 1 1 1 1 PRINT 1 0 0 0 RMAX 6.0 POTENTIALS * ipot Z element 0 28 Ni 1 8 O ATOMS * this list contains 7 atoms * x y z ipot tag distance 0.00000 0.00000 0.00000 0 Ni1 0.00000 1.91860 0.00000 0.00000 1 O1_1 1.91860 0.00000 1.91860 0.00000 1 O1_1 1.91860 0.00000 0.00000 1.91860 1 O1_1 1.91860 -1.91860 0.00000 0.00000 1 O1_1 1.91860 0.00000 -1.91860 0.00000 1 O1_1 1.91860 0.00000 0.00000 -1.91860 1 O1_1 1.91860 END

2 2

status of self-absorption corrections
by mauro＠rulp.org 11 May '04

11 May '04

Hi to all, I would like to ask you which is the status of the discussion on the self-absorption corrections to fluorescence EXAFS. I'm working on Mo/Si multilayers, studied by standing-wave-assisted EXAFS. My data are collected at grazing incidence (phi + theta = 90 deg) with a Ge (13 elements) detector. I have done data analysis without self-absorption corrections and I have found good results, except for the amplitude (S_0^2) that is very low (~0.50). I think this low value is due to self-absorption, so I would like to demonstrate it. My dilemma is: Troger's approach or Booth's one? I personally think that Booth's (simple) approach, could be used in this particular case (Ge detector, phi+theta=90deg), but my tutor told me that I can't assume a neglectable solid angle for a Ge detector so I have to use the Troeger's (quite difficult) approach. >From the mailing-list archive, I have read your discussion about this topic but I haven't found something like a "conclusion". Is there anyone who use Booth's approach with good results? Have you already done "tests" of this method? Is it possible to improve it? Finally, what about the software status? Matt, have you done something on Booth's Fortran code? Thanks, Mauro -- Mauro Rovezzi <mauro(a)rulp.org> - Physics student University of Rome "Tor Vergata", ESRF Beamline BM8 - GILDA

2 2

[Ifeffit]
by Webb, Samuel M. 10 May '04

10 May '04

Aaron -- That worked perfectly. Thanks! (it is the system32 directory) The default windows one (although "newer") was 10k short of the one that is distributed with IFEFFIT. Sam >Sam, > I ran into this about a week before the APS Users Meeting. Right after I >upgraded to the newest version of Athena/Artemis/et al. I did find the >solution. Check in your system32 subdirectory (I think, it may be system) of >the windows directory. There could be a DFORRT.dll located there. The >DFORRT.dll file in that location was rather date, possibly from '99. This old >file was set in the windows path, and it was accessing it even though newer >versions were available. I found that replacing the old DFORRT.dll file with >the newer version fixed the problem. You might have to do a google search if >you don't have a newer version on your computer. If you can't find a newer >version of DFORRT.dll that works, I'll post the one that I am using up online. > > >Sorry guys, I guess I should have sent something to the list about this >immediately.. > >Aaron Stuckey

1 0

[Ifeffit]
by Webb, Samuel M. 10 May '04

10 May '04

Quick question for everyone about the behavior of the latest updates on WinXP with Athena and Artemis et al. I manually unzipped all the updates and ran into the following error (which is likely due to my own problems). When I click on the hephaestus.bat file (WinXP), I get "The procedure entry point _FIIfexp_ could not be located in the dynamic link library DFORRT.dll." in a dialog box, then everything closes. This is also the case for Artemis.bat and Athena.bat. My version of IFEFFIT that was not updated does not have this problem. Copying the former version of DFORRT.dll from my working installation does not appear to help either. Going thru the updates from the start, I found that this error arises in update 007 and 008, but not 006. The same behavior happens for me if I use the autoupdater, rather than manually installing the updates. Sixpack seems to be unaffected. Anyone have any idea or seen this before? Sam ******************************************** Sam Webb SSRL/SLAC Bldg. 137, MS 69 2575 Sand Hill Rd. Menlo Park, CA 94025 Phone: (650)-926-3734 FAX: (650)-926-4100 E-mail: samwebb(a)slac.stanford.edu *******************************************

4 3

Upgrade issues
by Webb, Samuel M. 10 May '04

10 May '04

>I've never heard of this, and don't know what FIIfexp might mean. >There wasn't much change between 006 and 007 -- certainly not to >DFORRT.dll or ifeffit_10.dll, so it seems pretty strange. It does >appear that the DFORRT.dll in ifeffit/sixpack/ is older than the one >in ifeffit/. I'd be surprised if that had an affect, but it's easy >enough to try both versions of the dll. There's also a MSVCRT.dll >that you could try moving away, so that the system one gets used. > >Does this problem happen with ifeffit.bat? One thing that did >change between 006 and 007 was that the perl-generated executables >got smaller by a factor of 2. This might suggest that the perl >codes depend more heavily on other dlls for code, but I don't know >any of the details... > >--Matt Well, after some more investigation, I can get the upgrades to work on just about every other computer on site except for mine. The .bats all look fine, as near as I can tell. As you suggested Matt, it only appears that the perl codes -- the ones that depend on IFEFFIT are problematic. The rest (such as ifeffit.bat and sixpack) seem fine. Even uninstalling everything and reinstalling doesn't seem to help at all. I guess I'll manage with the old versions for now. Thanks all! Sam

1 0

RE: [Ifeffit]
by Jensen, Mark P. 10 May '04

10 May '04

Regarding Sam's question. > Quick question for everyone about the behavior of the latest > updates on WinXP with Athena and Artemis et al. I manually > unzipped all the updates and ran into the following error > (which is likely due to my own problems). When I click on > the hephaestus.bat file (WinXP), I get "The procedure entry > point _FIIfexp_ could not be located in the dynamic link > library DFORRT.dll." in a dialog box, then everything closes. I haven't had any problems running Hephaestus on 2 Windows XP machines under update 008. One of the machines was updated automatically, and one was updated by unzipping the downloaded files. Both approaches worked equally well for me. Mark Jensen ------------------------------ Mark P. Jensen Chemistry Division Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439-4831 USA 630-252-3670 630-252-7501 FAX mjensen(a)anl.gov > -----Original Message----- > From: Webb, Samuel M. [mailto:samwebb@slac.stanford.edu] > Sent: Monday, May 10, 2004 1:45 PM > To: 'ifeffit(a)millenia.cars.aps.anl.gov' > Subject: [Ifeffit] > > > > Quick question for everyone about the behavior of the latest > updates on WinXP with Athena and Artemis et al. I manually > unzipped all the updates and ran into the following error > (which is likely due to my own problems). When I click on > the hephaestus.bat file (WinXP), I get "The procedure entry > point _FIIfexp_ could not be located in the dynamic link > library DFORRT.dll." in a dialog box, then everything closes. > This is also the case for Artemis.bat and Athena.bat. My > version of IFEFFIT that was not updated does not have this > problem. Copying the former version of DFORRT.dll from my > working installation does not appear to help either. Going > thru the updates from the start, I found that this error > arises in update 007 and 008, but not 006. The same behavior > happens for me if I use the autoupdater, rather than manually > installing the updates. Sixpack seems to be unaffected. > Anyone have any idea or seen this before? > > Sam > > ******************************************** > Sam Webb > SSRL/SLAC Bldg. 137, MS 69 > 2575 Sand Hill Rd. > Menlo Park, CA 94025 > > Phone: (650)-926-3734 > FAX: (650)-926-4100 > E-mail: samwebb(a)slac.stanford.edu > ******************************************* > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit >

1 0

Re: Help
by Bruce Ravel 07 May '04

07 May '04

On Thursday 06 May 2004 06:05 pm, chachi rojas wrote: > I am a graduate student in physics at San Marcos University, Lima,Peru > and I'm interested in studying the intermetalic alloys Fe2Zr and Fe3Zr by > EXAFS (K-Fe-edge), this samples was prepared by mechanical milling. > I am a beginner in this technique (EXAFS), I try search some information > about these system, analysed by EXAFS. I use IFEFFIT (feff6) and Artemis > programs on Linux Slackware. > Bien, in my fit i find e0= -45.34 +/- 2.15, that is a error??.. a fit the > first shell in Fe2Zr system. > please help me, if is posible, send me some information, about these > systems analysed by EXAFS or some references on it, specially Fe2Zr. > I really appreciated it if you could help me. > Thanks > Chachi Chachi, This is a very good question. In fact, I think it is important enough that I am taking the liberty of CCing my response to the ifeffit mailing list (pues, escribiendo en ingles y no en espanol). This is most definately a problem. A huge E0 like that is probably coincident with an unphysical value for one or more bond lengths. I could explain, but fortunately Alain Michalowicz gave an excellent talk on this very topic a while back at NSLS. Here is the PDF of his talk, which provides an excellent overview of the "large-E0" issue: http://cars9.uchicago.edu/xafs/Advanced_Methods/BNLworkshop2001/michalowicz… So that helps explain what went wrong, but not how to make it right. Here are some suggestions and I imagine that some folks on the mailing list might have more: 1. Make sure that your E0 was set sensibly and calibrated to a sensible value way back in Athena. Metallic zirconium tends to have the annoying feature of a double peak in the first derivative spectrum and typically the second peak is larger than the first. (That is true both in pure Zr and in Zr-alloyed Sm2Co17.) Consequently, the algorithm used by Ifeffit (and so by Athena) to automatically determine E0 will choose the second peak, since it is bigger. This places E0 10s of volts above the real E0, thus introducing an enormous E0 shift into the data. Your fit might be conpensating for that or your fit might simply be resolving to a non-physical minimum of chi-square. (I know you said you are measuring the Fe edge, but a similar thing could happen elsewhere.) 2. There is documentation under Athena's Help menu about how to use the calibration tool in Athena. There is also a demo project (also under the Help menu) explaining how the calibration tool works. Make sure you know how this is done. 3. If your data are very noisy for any reason, the algorithm used by ifeffit to find E0 could be confused by the noise. It is even possible that it will choose an E0 value well in the pre-edge if the pre-edge is noisy enough. So watch out for that. 4. Last month, there was an interesting discussion on the mailing list about background removal and noisy spectra. It covered a lot of ground, but Shelly's response: http://millenia.cars.aps.anl.gov/pipermail/ifeffit/2004-April/000860.html includes an excellent point about the relationship of E0 in Athena and the later fit in Artemis. 5. Finally, it is possible that you need to take a more cautious approach to using Artemis. Have you read this web page: http://leonardo.phys.washington.edu/~ravel/software/exafs/startfitting.html It outlines my philosophy for how to start doing a fit using feff, ifeffit, and Artemis. By adopting this stategy and slowly building upi the parts of your fiting model, it is much easier to avoid some of the most common pitfalls. Hope that helps, B -- 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/

1 0

Another R-factor question
by Wayne Lukens 06 May '04

06 May '04

Hi Matt, Thanks again for clearing up my confusion over the origin of the R factor for fits in R-space. I now have a different and unrelated question about the R factor. From looking through the ifeffit code, it appears that the R factor is defined as sum(data-fit)/sum(data). Is this correct? The reason that I am asking is that I would like to use Hamilton's test (Acta Cryst 1965, V18, p.502) to determine whether adding additional shells to a fit actually results in a better fit. Hamilton's test uses the "crystallographic R factor", which is sqrt(sum(data-fit)/sum(data)), so I would like to know whether or not to take the square root of the R-factor ratios in Hamilton's test. Thanks again for the help! Sincerely, Wayne --- Wayne Lukens Scientist Lawrence Berkeley National Laboratory email: wwlukens(a)lbl.gov phone: (510) 486-4305 FAX: (510) 486-5596

2 2

reporting bugs
by Bruce Ravel 04 May '04

04 May '04

Hi folks, Of late, I have received a large number of well-intentioned but incomplete bug reports. While I am always pleased when people let me know about the in my programs that need improvement, it seems prudent for me to spend a little bit of time educating all of you in the art of reporting bugs. The most important thing for you to remember is this: +------------------------------------------------------+ | If I cannot replicate the problem you are seeing, I | | will not be not be able to fix it. | +------------------------------------------------------+ I do not knowingly release software with show-stopping bugs (i.e. bugs that cause crashes or generate trap files). Thus, if you do see such an event, it is likely that I am not aware of it. You need not only to tell me *that* it happened, but to show me *how* to make it happen. Often showing me involves sending the data or project file that triggers the problem. Other times it involves sending me an explicit "recipe" of steps to take which demonstrate the problem. Sometimes both. When I receive a bug report with insufficient information, I cannot do anything until we have exchanged email a few more times. By sending me what I need to replicate the problem, you may reduce the amount of communication required and speed up the response. I have a somewhat long list of suggestions for reporting bugs at this web page: http://leonardo.phys.washington.edu/~ravel/software/exafs/bugs.html If you have not read that page recently, please take a few minutes to do so again. Regards, B -- 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/

1 0

New binary installer for testing on Mac OS X
by Matt Newville 03 May '04

03 May '04

Hi Folks, There's a new version of a Mac Binary Disk image for testing at http://cars9.uchicago.edu/ifeffit/downloads Currently labeled ifeffit-1.2.5a-Mac10.3.dmg. This include horae-033, and uses the Aquaterm Plotting terminal by default, but supports the X-window plotting as well. This version is also ready for horae-update to work if Fink and Fink's g77 are installed on your system. This has been tested on exactly one machine and will require small changes to horae by Bruce, so we won't know how it really works until horae-034 is ready. Please try this out and let me know how it works. I have not yet put this version on Sourceforge.net, and will wait to do so until I hear a few positive responses that it works ok. --Matt

2 1