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

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

Re: A question about the new Artemis version
by Peter Southon 02 May '04

02 May '04

As Bruce and Matt already know, I also have been trying to get Artemis to use the same FEFF calculation set for multiple data sets (in my case fewer data sets than Scott but with more paths). I've been taking the 'bite the bullet' approach and re-entering all the path parameters for each sample, but the ability to clone the calculations would help me a lot as well. I came up against two limits. First there is Ifeffit's limit of 256 paths, so I think Scott's student will hit this in the project he described (11 x 25). Matt has kindly sent me a modified version of Ifeffit which should have an increased limit, but I haven't had the chance to test it yet (partly for reasons described below). The second limit is when Artemis checks that there are not more than 256 paths before running a fit. When I tried running one fit I found that Artemis counts all the files that are opened, not just those selected to be included in the fit, but Bruce is fixing this. However, I suspect that Artemis too will have to be modified before it will let you run a fit with more than 256 paths using a modified Ifeffit. This is where Bruce's suggestion of writing a Ifeffit script and then editing with cut & paste (and find & replace) becomes particularly useful. This is quite similar to what I did with Feffit and Ifeffit before I started using Artemis, and works well but is rather time consuming. I understand that an item on Bruce's (very long) 'to do' list is to allow Artemis to open a Ifeffit script into a project - so that once manually modified you could transfer the project back into Artemis. There is another thing to look out for when constructing very large or complex Artemis projects. I have found that very occasionally Artemis will save a project into Bruces' new zip file format, but neglect to actually add in some (or any) of the data and feff files. The first symptom is that the size of the saved project is much smaller than it should be. Thus when re-opened, the project looks fine, but Artemis cannot open any of the required files when a fit is attempted. The data can be replaced, but I can't find a way of replacing any feff calculations without re-entering all of the parameters. Anyway, the purpose of all that is that if you are putting a lot of work into your Artemis project, it may be worthwhile to back it up occasionally, or save under a new name. >P.S. Thanks to Matt and Bruce again for even making such a thing >conceivable. Hear hear Peter Peter Southon Post Doctoral Fellow School of Chemistry University of Sydney NSW 2006, Australia +61 2 9351 4425

5 7

RE: [Ifeffit] Substrate material question
by Kropf, Arthur Jeremy 29 Apr '04

29 Apr '04

Paul, Silicon is quite strong. However, it is also brittle. For detectors I have been able to bend 200 micron silicon to less than a 200mm radius. That should be plenty of strain. Virginia Semiconductor is great. Look at their double-side polished stock and you can typically find one or two batches with less than 200 micron thickness. Wafers thinner than 100 microns begin to get quite fragile. Jeremy Kropf Chemical Engineering Division Argonne National Laboratory -----Original Message----- From: ifeffit-bounces(a)millenia.cars.aps.anl.gov [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf Of Paul Fons Sent: Tuesday, April 27, 2004 7:59 PM To: XAFS Analysis using Ifeffit Subject: Re: [Ifeffit] Substrate material question I have still not decided on the final substrate material, but I have a couple of samples coming from Dupont of polyimide (same composition as Kapton) material called vespel. It is essentially inert as one would expect (like Kapton), but due to differences in manufacture I understand it is hydroscopic. From this I assume that the reaction for making Kapton is diffusion limited and Vespel is essentially a "polycrystalline" -- in the sense there are grains between which water can absorb -- form of Kapton. The energy in question is 11.6 keV (the Ge edge). Si is an interesting idea but the loss for a 200 micron thick substrate is essentially 1/e. It is certainly worth considering for higher energies though! The 1/e value for polyimide is about 3500 microns in contrast, while the 1/e value for MgO is about 300. As in my experiment I want to create biaxial stress in a thin film on the substrate, I worry that the stress/strain curves for MgO are too stiff. On the other hand, thin S! i is a real possibility (darn, Si technology is everywhere!). I like the Si idea and might try that in parallel. Has anyone tried using thinned Si wafers (Virginia Technology ? sells mechanically thinned wafers I think -- I saw them at a MRS booth a long time ago). How fragile are the wafers? On 2004/04/28, at 0:32, Jeff Terry wrote: Hi Matt, Both items are good to know. I didn't realize that the laminated kapton structures still had good heat resistance. Jeff On Apr 27, 2004, at 10:22 AM, Matt Newville wrote: Hi Paul, I think you can get polyimide thicker than 175 microns. It may not go as Kapton, but maybe as Cirlex or Torlon or something else. I think goodfellow.com carries these in millimeter thick sheets and rods, and that they're still radiation and heat resistant. Goodfellow tends to be pricey, but has excellent information on thermal and mechanical properties. Using MgO, sapphire, or even diamond might be reasonable too. --Matt PS: I have a working build of PGPLOT with all of Aquaterm, X11, Postscript, and Png devices on Mac OS X. I'm still tweaking the makefile so that it links directly to the png objects to avoid possible conflicts with dynamic png and zlib libraries, but I should have a working ifeffit binary using this in a matter of days, and then be ready to tweak horae's Makefile.PL so that horae_update works. _______________________________________________ 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 Dr. Paul Fons Senior Researcher National Institute for Advanced Industrial Science & Technology METI Center for Applied Near-Field Optics Research (CANFOR) AIST Central 4, Higashi 1-1-1 Tsukuba, Ibaraki JAPAN 305-8568 tel. +81-298-61-5636 fax. +81-298-61-2939 email: paul-fons(a)aist.go.jp The lines below are in a Japanese font 〒３０５−８５６８茨城県つくば市東１−１−1 つくば中央第４近接場光応用工学センターポール・フォンス主任研究官

3 2

RE: [Ifeffit] Minor bugs in the new versions
by Jensen, Mark P. 29 Apr '04

29 Apr '04

Along the topic of not being able to run Artemis and Athena simultaneously under Windows. 1. Lack of complaints doesn't mean that he problem is rare. I have consistently seen this behavior (run either Artemis or Athena) on 3 different Windows NT/Win 2000 (incidently 128 Mb RAM) machines. I recall pointing it out to Bruce many moons ago, and just accepting it as the way things were. Matt and Bruce obviously spend a lot of time working on their programs to our benefit, and I didn't think it was worth Bruce's time to chase a small, possibly not fixable, problem like that down. Thus, I did not bug him about it after the first mention of it. I would just extract the EXFAS signal in Athena, save the file, close Athena, open Artemis, and fit. It seemed like a small price to pay for being able to use a great set of programs. 2. However, the recent exchanges on this matter got me to look closer. Now I see that I can run both programs simultaneously on my brand-spanking-new 1 Gb RAM Windows XP computer. I'll have to try it under WinXP and 512 Mb RAM at home this evening. Maybe this is indeed a memory size problem. 3. It seems like more and more of the posts to the Ifeffit list are about general EXAFS things like (for a recent example), what k-range to use. Bruce and Matt and others have been very helpful to the needy, and I can tell it has been much appreciated. (I think I already know the answer to my following question). Has it been considered to "split" the Iffefit list into 2 topics, 1 for general XAFS and 1 for Ifeffit and related programs. (Suspected answer.... "Great idea Mark, we've talked about this before, why don't you volunteer?") Mark J. ------------------------------ 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

3 3

Re: Artemis Crashed too often
by Aria 29 Apr '04

29 Apr '04

After reading these days' discussion in 'minor bugs report' thread, it reminds me of keeping a track of memory usage in my case. Here is a detailed list. Artemis starts: 56,100 K Loads project file: 59,180 K Save: 65,256 K After 1st fit: 88,252 K 2nd fit: 88,824 K 3rd fit: 89,320 K Save: 98,160 K 4th fit: 97,840 K Save: 98,164 K 5th fit: 298,152 K Crash I have also noticed the CPU usage is normally 25% during the fit process. But in the 5th fit, it went up to 25% for first several seconds, then drops to 0% suddenly. The memory usage jumps to 298,152K at the same time, and stayed for a few seconds before it finally crashed. Meanwhile, another process called 'dwwin.exe' with memory usage of 248,016K appeared. After the error message showed up, and closed all the Artemis windows, both of those big memory consuming processes disappeared. This practice is reproducible. I hope it helps a little bit. Best regards, Aria

1 0

RE: [Ifeffit] Minor bugs in the new versions
by Jensen, Mark P. 29 Apr '04

29 Apr '04

I agree with Gerrit on this. This morning I took a look at the two "nearly identical" computers and found that 1. Athena and Artemis each consume about 230 MB of memory to run on my Windows 2000 or XP computers. 2. That the computer that could run both Athena and Artemis with 128 MB RAM had a considerably larger maximum virtual memory setting (600 MB) than the computer that would not (300 MB). Increasing the size of the virtual memory on the latter computer allows both to run. Bruce, as long as that is the amount of memory the programs should use, I guess that means this is not a minor bug in your software. In my case, it's a user that was being miserly with hard drive space. 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: Schmithals [mailto:schmithals@hmi.de] Sent: Thursday, April 29, 2004 3:06 AM To: XAFS Analysis using Ifeffit Subject: Re: [Ifeffit] Minor bugs in the new versions Matt Newville schrieb: > 2 I can definitely run artemis and athena at the same on a Windows > machine, so I doubt there's a lock on Perl's Ifeffit.dll. I'd > assume that if other people could only run one of these at a > time there would be many complaints. > > 3 On my WinXP box, athena and artemis each use about 55Mb at > startup -- without reading in any data. That seems to be about > 50% Ifeffit / 50% Perl/Tk (the ifeffit shell takes ~24Mb). > I don't know enough about what changed to guess why the memory > usage would've changed between versions of artemis and athena, > but I think they should both be able to run in 256Mb. Anyway, > I'd suggest watching the memory usage in TaskManager as you > start athena and artemis to see if it really is a memory issue. I now think its a memory problem, too. My computer is running Win2000, 256 MB of RAM, virtual memory is fixed to 400 MB. I started the Windows Task manager to watch memory usage: - without any programs running (except virus scanner, ..) its 119 MB - After starting Artemis it goes up to 412 MB - Athena won't run Then I set the virtual memory to fixed 600 MB. - After starting Artemis it again takes ~400 MB - Athena now starts! Memory usage is ~700 MB. But shutting down one program before starting the other has been OK for me, too. Regards, Gerrit _______________________________________________ Ifeffit mailing list Ifeffit(a)millenia.cars.aps.anl.gov http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

2 1

Minor bugs in the new versions
by Schmithals 29 Apr '04

29 Apr '04

Dear Bruce, I installed the new versions of the programs. Many thanks for your ongoing work and especially for the new feature of exporting parameter values in Athena. While working with the new versions I listed the problems that I still ran over (all just minor problems that are not critical or for which I figured out a workaround). Some of the bugs have already been mentioned, but I was not sure if they should already be fixed with this release - if not please just ignore these points. Hope it helps to improve the software. My System is Win2000. Artemis 0.7.003 - After the update the path to the stash-folder is set to the default path: "c:\Program Files\Ifeffit\horae\stash" although my Ifeffit is installed at "c:\Programme\Ifeffit" and previously the stash folder was "c:\Programme\Ifeffit\horae\stash". Is it possible to set the stash folder automatically to the subfolder in the installation directory? Obviously, this should be corrected via: Options | General | Workspace. But Artemis will not let me do that. I included the messages that Artemis gives when I change the path and press "Save changes to future sessions" and "return to main window". In the latter case Artemis will ask if I want to keep changes for future sessions (obviously it recognizes that changes have not been saved) but will not return to the main program (and not change the path). However, it does affect working with Artemis in any other way (as far as I can tell). - Atoms potential cards (in feff.inp) is sometimes wrong. (work-around: enlarge r_max in atoms.inp) - Artemis will stumple if I try to import 30 paths (my default) but feff generated less than that (no paths will be loaded and and error message generated, see ARTEMIS Import.TRAP). - If I run feff, import 30 paths and then do that a second time, Artemis does not delete the old entries in the "data&paths"-window but just append the new entries with names "feff0001.dat:2" etc., is that the intended behaviour? The problem is that if I decrease r_max in feff.inp before doing the second run (to a value so that feff produces less than 30 path-files) Artemis will generate error messages when trying to plot the first path entries (obviously because they dont exist anymore). - Function "discard this dataset" does not delete the main folder "data0.feff.0". Therefore, after deleting a few FEFF-datasets I end up with a lot of folders "data0.feff.x", because the empty ones are not reused. The function also does not delete the corresponding parameter values (which is probably better than deleting them). - Set-up of Atoms/Feff-page before loading a datafile will lead to errors (already discussed) Athena 0.8.027 - Athena does not start when Artemis is running. Two new Windows will show up for a moment in the taskbar and disappear again, no error logs are written to the stash-folder. No problems occur if Artemis is not running. Also Artemis will not start when Athena is running. - When using the export function via "File | Save marked groups as data" Athena will state that I may not export more than 15 datafiles. But it also produces errors with less files: it seems that the maximum line width is limited to 259 characters. The line with the names of the datagroups is usually longer and therefore gets truncated. - Access to last opened files is not released: it is not possible to rename/delete project files that just have been closed or data files that just have been read in. This is possible after a new project file is opened or a new data file imported. - Sometimes the selection of groups gets faulty: when clicking on one of the groups it will not be highlighted. Instead the previously selected group will be redisplayed (and remains highlighted). Sometimes a completly different group will be highlighted and displayed. Closing and reopening will not solve the problem, but restarting of Athena does. I could not figure out how to reproduce this error and nothing is written to the stash-folder. - Athena sometimes resizes the width of the right panel (Data groups) by itself. E.g. when exporting data via "File | Save chi(R)" the window becomes wider and gets small again when clicking on a datagroup afterwards (but not always ?!). Atoms ? - I am not sure about the version number because "Help"|"About Atoms" displays "left" (?!) instead of version number. - The "Browse Space Groups" will still invoke the browser only once. Hephaestus 0.01 - Multiple choosing of Settings | Energies will TOGGLE between display in energies/wavelengths (instead of just keeping displaying in terms of energy). Moreover, the checkmark in the Settings-Dialog will stay at "Energies", even when displaying in wavelengts. Despite of this I would propose to display the unit on the main page anyway. - On my machine the checkmarks are hard to recognize as they only shown up as two tiny red dots. But they will show up as checkmarks when I hover over them with the mouse. (This behaviour is common to all the programs, also in previous versions). I also have some general question: - Is it possible to do an offline installation on a computer not connected to the internet? (e.g. by manually loading the updates-files and changing "update_site" in updater.ini) - Is there a way in Athena to display the raw data of a group as a text file? Athena will not allow to edit this data via "Edit | Edit data as text". I only had the idea of saving the group and looking at the resulting text file. - This raised another point: if I compare the file I read into Athena with the file I exported then I notice that they have a different scaling (abszissae values) - does Athena automatically change the scaling when importing data files? I also noticed that when exporting multiple groups then all groups are scaled to the same abszissae values which is not the case when I export them separately. Regards, Gerrit

3 9

RE: [Ifeffit] Minor bugs in the new versions
by Jensen, Mark P. 28 Apr '04

28 Apr '04

Ifeffit friends, I have done several test with Athena and Artemis this afternoon, and the problem of running Athena and Artemis at the same time does not seem to be solely memory related. On two similar Win2000 machines, my old one with 128 Mb behaved as usual, only Artemis or Athena would run at one time. The first "program box" for Aretmis representing the text window would appear in the task bar, the updater program box would appear and then both would disappear instantly. I do not observe the Aretmis splash screen and she never really starts. It happens so fast that I can't read anything in the text window. This was it's "usual" behavior on the 3 computers I mentioned in the previous e-mail. This happens right from the get-go. Nothing else, other than the manditory windows services and the lab mandated anti-virus software was running. On the other machine, with 256 Mb, I could run both simultaneously. Aha! I'm on to something! When I took 128 Mb out of this 2nd computer, though, I could still start Athena and Artemis simultaneously! Rats, foiled again! Unfortunatley, I couldn't bump up that 1st computer to 256 Mb to see if that would enable both to run simultaneously on that computer. In the past, on the first computer, I have had to shut down other programs to get enough memory to run either Athena or Artemis. Maybe, people with this problem will just have to adopt my old approach and put up with this glitch. Mark ------------------------------ 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

1 0

RE: [Ifeffit] Minor bugs in the new versions
by Scott Calvin 28 Apr '04

28 Apr '04

At 02:57 PM 4/28/2004 -0500, you wrote: >1. Lack of complaints doesn't mean that he problem is rare. > Mark brings up an interesting issue. I'd kind of like to get the sense of the community on this. Given that, unlike Ifeffit itself, Artemis and Athena are beta versions (a "0" starts the version number), all of us who use that software are beta testers. Thus part of our responsibilities, in exchange for getting to use really nifty and cutting-edge software, is to report bugs to Bruce. Unfortunately, reporting bugs in a responsible way is somewhat time-consuming (not nearly as time-consuming as writing the software in the first place, of course!). For example, a really minor bug which has already been discussed is the one that occasionally makes the right panel of Athena get wide. It's not something that bothers me, but it's clearly a bug. I don't feel like I'm being helpful, though, if I report to Bruce that something like this "occasionally" happens without being able to make it happen reproducibly. So I never reported it. If, on the other hand, some bug is either making it harder for me to do what I want to do, or it seems likely to cause some other unsuspecting user grief, or I can see exactly under what circumstances it occurs, I generally investigate and make a bug report. So my question is what perspective everyone (and especially Bruce) has on the trade-off between tracking down every bug so as to give Bruce full reports and spending the time actually using this great software for analysis. --Scott Calvin Sarah Lawrence College

1 0

RE: [Ifeffit] k range
by Kelly, Shelly D. 28 Apr '04

28 Apr '04

Hi Steven, > On Tue, 27 Apr 2004, Steven Sangyun Lim wrote: > > > My question is how low can I set the k range? Is there any minimum > > range for reliable result? Please let me get out of this dilemma... > Scott and Matt both answered this question differently than I would. I guess I am very practical. If I was asking this question I would want a set of rules that would help me figure it out the k-range. So here one way to do that. 1) Look at the data in Athena to determine a good k-range to use. Here is how. 1a) As Matt suggested find a node in the chi(k) data that is around 3 inverse angstroms and set that to the kmin value. 1b) make about 6 copies of the chi(k) data set, all with the same kmin value. All the other FT values should be as you used in Artemis. (k-weight, window, dk) 1c) highlight each data set choosing a larger and larger node for kmax. Start really safe value around 8 inverse angstroms. Then pick the next node for the next copy and so forth using up all the data. For example, the first copy of the data set has a k-range [3.2 to 8.2] the next copy has k-range [3.2 to 9.3] and so forth....until the last has a k-range of [3.2 to 14] 1d) Plot the FT of the first three data sets all together (using the purple buttons to select them and the purple R button). Look at the data with the magnitude and the real or imaginary part. With a small k-range the FT signal will be very smooth curve in the magnitude, real and imaginary parts. You will tend to see two types of changes as you increase the k-range. 1) peaks will become more resolved, larger amplitude and thinner. --this is a good kind of change 2) eventually you will see noise in the FT of the data. The noise will look like high frequency pulses in the real and imaginary part of the spectra all over in R. From one data set to the next random signals will appear and disappear as you include noise in the data. --this is the bad kind of change. Keep comparing three data sets, drop the first one then add another with slightly larger k-range. You should be able to find the cross over from the good kind of a change to the bad kind of a change. 1e) By using this comparison you should be able to choose a k-range that is large but not too large. It should result in a conservative k-range to use as a starting point for your modeling. Be careful about the k-weight that you use when you make this comparison. It needs to be the same that you are using in Artemis to model the data. Larger k-weights will have smaller "good" k-ranges for the data. 2) Pull your data into Artemis. Use the good k-range that you determined from step one. 2b) Determine a model that works and look at the results including the uncertainties. 2c) Increase the k-range and compare the results. Try to decrease kmin and increase kmax. Do one thing at a time and see how the results vary. You will need to make a lot of comparisons, see how your results and uncertainties change as you adjust these values. 2d) Decide on a k-range that gives you the "best" results. 3) You may want to go back into Athena and use a standard to adjust the low k region of the chi(k) data, depending on how your FT looks at low R. This can help you stretch the kmin value. HTH Shelly

4 3

RE: [Ifeffit] k range
by Kelly, Shelly D. 28 Apr '04

28 Apr '04

Hi Steven, In general you can use as small of a k-range as you want but you loose the number of variable that you can determine and your uncertainty in those variable gets really big too. If those trade offs are acceptable then there is no problem. I assume that you want to determine a few variables so Scotts equation is all you need to determine the minimum k-range. Artemis also lists the number of independent points in the log file. That number has to be greater than the number of variables you can determine in the fit. In practice, you need about twice as many independent points as variables to get reasonable uncertainties. But if what you say about your data is true then the metal peak is not real. In the chi(k) data the signal for each peak starts at k=0 and goes until the sigma2 term damps it out, usually around 8 to 10 inverse angstroms for oxygen, but usually much larger values for atoms with more electrons. It is physically impossible for the signal of the metal peak to only exist between 6 and 8 inverse angstroms. I would compare the data set that you are having troubles with to the other data sets that you indicated gave a consistent peak in the FT. I would bet that the troubled data set has some artifact in it that is distorting the FT. Shelly -----Original Message----- From: Steven Sangyun Lim [mailto:steven.lim@yale.edu] Sent: Tuesday, April 27, 2004 6:31 PM To: ifeffit(a)millenia.cars.aps.anl.gov Subject: [Ifeffit] k range Thank you all very much for the immediate help. One more question, may I??? What can the minimum kmax be? I think it can be about 8 according to Scott. If I use kmin=2, can it be 7 or 6? The reason why I ask this is that when I plot R space with my sample, which has been reduced and needs to be confirmed if there is any metal cluster, the metal peak shows at kmax=8, but it disappears at kmax=6 or 7. At kmax=10, it is hard to tell because the spectrum is very noisy (it shows split peak). When there are extremely small metal clusters (even at CN=0.6), I can see a distinct metal peak that does not change no matter what k range and weight I use. I wonder any further advice can be suggested. Thank you for your help in advance. Steven

1 0

Substrate material question
by Paul Fons 27 Apr '04

27 Apr '04

OK, I admit this isn't an athena question (but it is about how to take the raw data for it!). I want to do biaxial strain measurements. The idea is to deposit a thin film of the material to be investigated on a substrate and then deform the plate with a form of cylindrical symmetry. One can then solve for the stress of a plate using elasticity theory. The twist is that I need a plate that is stiff and (surprise) x-ray transparent ... and heat resistant to about 250 C. Kapton would be a wonderful choice, but is only made in thicknesses up to 175 microns (hardly stiff enough). There must be someone out there in the collective iffeffit world who knows of an appropriate material. Doing some web surfing, I came across another product by DuPont called Vespar that *may* be available in thicker forms. The specs I am looking for are: a thin (semiconducting) film has to stick to the surface, heat resistant to <=250 C, thick enough to be elastically stiff, and x-ray transparent. Any suggestions? Thanks for any help that may come my way in advance! Dr. Paul Fons Senior Researcher National Institute for Advanced Industrial Science & Technology METI Center for Applied Near-Field Optics Research (CANFOR) AIST Central 4, Higashi 1-1-1 Tsukuba, Ibaraki JAPAN 305-8568 tel. +81-298-61-5636 fax. +81-298-61-2939 email: paul-fons(a)aist.go.jp The lines below are in a Japanese font 〒３０５−８５６８茨城県つくば市東１−１−1 つくば中央第４近接場光応用工学センターポール・フォンス主任研究官

5 9

k range
by Steven Sangyun Lim 27 Apr '04

27 Apr '04

Thank you all very much for the immediate help. One more question, may I??? What can the minimum kmax be? I think it can be about 8 according to Scott. If I use kmin=2, can it be 7 or 6? The reason why I ask this is that when I plot R space with my sample, which has been reduced and needs to be confirmed if there is any metal cluster, the metal peak shows at kmax=8, but it disappears at kmax=6 or 7. At kmax=10, it is hard to tell because the spectrum is very noisy (it shows split peak). When there are extremely small metal clusters (even at CN=0.6), I can see a distinct metal peak that does not change no matter what k range and weight I use. I wonder any further advice can be suggested. Thank you for your help in advance. Steven

1 0

k range
by Steven Sangyun Lim 27 Apr '04

27 Apr '04

Dear all, I always appreciate the big useful help from everyone. I have a basic question. I think a similar question has been arose long time ago. (But I lost the mail..) My sample has very small amount (under 1 wt%) and cluster size (< 1nm). The spectrum is always noisy at high k range, so I use usually k=2 to 10 or 12. It depends on the noise of the spectrum. Of course, if I go further down, it is better. My question is how low can I set the k range? Is there any minimum range for reliable result? Please let me get out of this dilemma... Thank you always. Steven

3 2

RE: Ifeffit Digest, Vol 14, Issue 23
by Aria 27 Apr '04

27 Apr '04

Hi, Bruce For the first question, after I answered 'yes'. Artemis will run well without problems. But after running fits for four (sometimes even three) times, it will crash again. And the next cycle begins. As for reproducible, only after I finished the updates, it will crash every four or three fits, no matter what fits I am running. The fits paths included might be around 100. By the way, I did not notice if Artemis posts a message or not before. But this time, it do pop up a message at the first time I run the fit (not at the time it crashes). This is the message I got: # This file created at 11:01:54 on 27 April, 2004 # using Windows XP, perl 5.006001, Tk 800.024, and Ifeffit 1.2.5 The following message was trapped by Artemis on a SIGWARN: ArtemiswarnC:\Program Files\Ifeffit\horae\stash\ARTEMIS.TRAPCODE(0x3525f58) at artemis line 1491 main::__ANON__('Tk::Error: Can\'t locate utf8.pm in @INC (@INC contains: C:\DOCU...') called at blib\lib\Tk.pm (autosplit into blib\lib\auto\Tk\Error.al) line 402 Tk::Error('MainWindow=HASH(0x394d430)', 'Can\'t locate utf8.pm in @INC (@INC contains: C:\DOCUME~1\VINCEH...', '[\&main::__ANON__]', '(menu invoke)') called at /PerlApp/Tk.pm line 340 eval {...} called at /PerlApp/Tk.pm line 340 Tk::MainLoop() called at artemis line 1627 Here attached is the file. Thanks a lot, Aria ------------------------------ Message: 2 Date: Mon, 26 Apr 2004 17:04:59 -0400 From: Bruce Ravel <ravel(a)phys.washington.edu> Subject: Re: [Ifeffit] Artemis Crashed too often To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> Message-ID: <200404261704.59318.ravel(a)phys.washington.edu> Content-Type: text/plain; charset="iso-8859-1" On Monday 26 April 2004 04:27 pm, Aria wrote: > I began to use the old version of Artemis in last September, and did not > update till days ago. But after the installation, Artemis crashed very > often. After running four fits, it will crash without any reasons (I did > not close the graphics window). And when I restart the Artemis, sometimes > it will give out information like: 'There seems to be a large number of > abandoned project folders. This might be due to past program crashes or > other past problems. I can clean these up at this time.' I am not sure if > it happens to others. I work in Windows XP platform. You seem to be reporting two different problems here, but have not given me enough information to do anything useful about either one. 1. What happens when you answer yes to the question about cleaning up abandoned project folders? Does Artemis crash again right after that? How about the next time you start Artemis? 2. It is really not adequate just to say "Artemis crashed very often." If you do not give me enough information to reproduce the problem myself, then I cannot fix whatever is causing the crash. Indeed, I cannot even begin to search for the problem because you haven't told me anything about it. Please read this page carefully: http://leonardo.phys.washington.edu/~ravel/software/exafs/bugs.html and the consider trying your bug report again. If Artemis beeps and posts a message to the echo area about a TRAP file, please send me the specified file along with a description of how you got to the situation. 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/

3 5

Artemis Crashed too often
by Aria 26 Apr '04

26 Apr '04

Hello, I began to use the old version of Artemis in last September, and did not update till days ago. But after the installation, Artemis crashed very often. After running four fits, it will crash without any reasons (I did not close the graphics window). And when I restart the Artemis, sometimes it will give out information like: 'There seems to be a large number of abandoned project folders. This might be due to past program crashes or other past problems. I can clean these up at this time.' I am not sure if it happens to others. I work in Windows XP platform. Regards, Aria

2 1

Re: [Ifeffit] Re: A question about the new Artemis version
by Scott Calvin 22 Apr '04

22 Apr '04

Hi Matt, FYI, the path limit in the current version appears to be set to 256 paths. --Scott Calvin Sarah Lawrence College At 02:53 PM 4/1/2004 -0600, you wrote: >The latest version of the ifeffit_10.dll windows binary should >support 1024 paths, and 16 data sets. You can see what these >limits are for your system by typing > show &max_paths, &max_data_sets > >at the command line prompt. The limits are set to their current >values so that Ifeffit+Athena takes well under 64Mb RAM. But these >limits are set in one place in the source code (src/lib/consts.h) so >that you can easily change them and recompile if you need these >limits to be higher. max_paths can be increased easily up to 9999, >but going above that would take more work. >>

1 0

new versions of my programs
by Bruce Ravel 22 Apr '04

22 Apr '04

Hi folks, I have just finished the new release of my data analysis programs: Athena 0.8.027 and Artemis 0.7.003. This release contains mostly bug fixes and feature enhancements. As you may recall, last month's release of Artemis generated a very large amount of traffic on this list due to several problems surrounding the new project file format and other file management issues. I have addressed almost all of the problems that were reported and am cautiously optimistic that this release of Artemis will be much more solid than the last. There is one significant new feature in this release -- the program Hephaestus, which will be a permanent part of future releases. Hephaestus replaces the Atoms Periodic Table and expands greatly upon its functionality. I will describe Hephaestus in more detail in a message later this morning. Source code tarballs are already available on my web site and at SourceForge. The Windows updater package will be available soon. Change logs with all the details of the new features of Athena and Artemis are on my web site. Lots of people helped out this time with excellent suggestions and bug reports. Special thanks to Mauro Ravezzi, David Barton, Peter Pfalzer, Gerrit Schmithals, Stanislav Stoupin, and Shelly Kelly. 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/

6 20

Re: Truncate, Post-edge Athena Issues
by Bruce Ravel 21 Apr '04

21 Apr '04

On Tuesday 20 April 2004 11:56 pm, Barton, David (DG) wrote: > One final question. I often see a strong discontinuity near the edge > energy in the background subtraction. The attached Athena project clearly > shows this discontinuity, any thoughts about this? Dave, I am CCing the answer to this one to the mailing list. The background spline is evaluated between the energies (or k values) specified. Outside that range the spline is not evaluated at all. To make the arrays conatining the data and background spectra easier to handle when interacting directly with Ifeffit, Matt wisely chose to make the background array the same length as the data array. At energies within the spline range, the background array contains the background spline. Outside the spline range, that background array contains the original data. Not only does this make the arays the same length, but it makes computation of chi(E) completely trivial -- you can just subtract the background array from the data array point by point. If the first or last few points of the spline are not near in value to the data (which can happen since a spline can be poorly constrained at the ends), then the plot of the data and background arrays will be as you described. The background array will have a discontinuity, but that is not a bug. Regardless of the constraint of the spline near its ends, the criterion for choosing the spline is met. That is, the spline is always chosen to minimize the low-R Fourier components (possibly with respect to a standard spectrum). Sometimes this minimization results in a spline that deviates from the data at the ends. Constraining that deviation is the purpose of the spline clamps. > I typically have ignored this since it is outside the EXAFS fitting > region and the XANES background subtraction routines are not > affected by it. That is completely correct. HTH, 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

Athena Minor Error
by Norbert Weiher 21 Apr '04

21 Apr '04

Hey Bruce, I found a minor error in athena: When want to select the spline range for my spectrum and accidentially press the "k" button (but have the spectrum plotted in E), athena crashes as soon as I click on the graph to select some value. Its not bothering much (actually I should be aware of pressing the right button - I know :)), just wanted to tell you. Cheers, Norbert -- Dr. rer. nat. Norbert Weiher (weiher(a)chem.ethz.ch) Institute for Chemical and Bioengineering - ETH Hönggerberg HCI E 117 - 8093 Zürich - Phone: +41 1 63 3 48 32

2 1

noisy spectrum and AUTOBK
by gabriel rosenblum 20 Apr '04

20 Apr '04

Hi all. Sorry for not being specific. I am trying to do background removal with AUTOBK. The parameter emax is present at autobk.inp file under the UWEXAFS package. Emax � means the region after the edge in the xmu file to be taken by AUTOBK to perform the spline. For example, if emax is set to 400 eV, it means the spline and the subtraction will be carried 400 eV over the edge. After the subtraction I FT the data and observe chi(R ). I guess the noise problem is more pronounced 350 to 550 eV over the edge, and not near the edge. However I will sure try the recipe offered by Shelly. Still waiting for an answer. Thanks. Gabi. __________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash

2 1