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

Re: Ifeffit digest, Vol 1 #42 - 1 msg
by Raul Barrea 01 Aug '02

01 Aug '02

Hi Bruce, I've downloaded the exec file you've posted in your web site. Atoms and the periodic table work fine but Athena and Artemis don't work. Maybe there is something missing. Are the dll's the same for the old and new versions of the exec files? Thanks Raul Barrea BioCAT/APS ----- Original Message ----- From: <ifeffit-request(a)millenia.cars.aps.anl.gov> To: <ifeffit(a)millenia.cars.aps.anl.gov> Sent: Tuesday, July 23, 2002 12:01 PM Subject: Ifeffit digest, Vol 1 #42 - 1 msg > 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-admin(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. serious athena bug fix (Bruce Ravel) > > --__--__-- > > Message: 1 > Date: Mon, 22 Jul 2002 18:15:24 -0400 > To: ifeffit mailing list <ifeffit(a)millenia.cars.aps.anl.gov> > Reply-To: ravel(a)phys.washington.edu > From: Bruce Ravel <ravel(a)phys.washington.edu> > Subject: [Ifeffit] serious athena bug fix > > > Hi folks, > > Today Shelly Kelly pointed out a serious bug in the code that merges > spectra. Spectra merged as mu(E) or norm(E) have not ever been > calculated correctly. There were several problems -- the worst was > that the e0 shifts for all groups involved in the merge were ignored. > This resulted in numerous problems with the merged spectra. > > I think I have fixed the problem -- at least the sample data that > Shelly gave me now gets merged correctly. There is a new source > tarball on my web site. > > I also added a couple of trivial features to both athena and artemis. > The first is a splash-screen, i.e. something to look at in those > endless seconds between double clicking on the icon and having the > program spring to life on the screen. I also added several keyboard > shortcuts for common tasks in both programs. You can see what these > are by examining the menus in the menubar. > > > I also added something new to my web site. Athena and Artemis change > much faster than Ifeffit these days. The bad part of this is that > Windows users don't get to take advantage of my updates as often as > unix and OSX users. So today I added a section to the downloads page > with links to the executables of my four programs. I doubt I will > update the executables as often as I update the source tarballs. But > when I do, I'll post the executables on the downloads page. > > The idea of these individual executables is that you replace the > executable in the C:\Program Files\Ifeffit\ folder with the new one. > These executables now found on my downloads WILL NOT RUN CORRECTLY > outside the context of a properly installed ifeffit package. But if > you have installed Ifeffit using the installer from Matt's web page, > you will be able to drop my new executables in place. > > Regards, > B > > > > -- > Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu > Code 6134, Building 3, Room 222 > Naval Research Laboratory phone: (1) 202 767 5947 > Washington DC 20375, USA fax: (1) 202 767 1697 > > NRL Synchrotron Radiation Consortium (NRL-SRC) > Beamlines X11a, X11b, X23b, X24c, U4b > National Synchrotron Light Source > Brookhaven National Laboratory, Upton, NY 11973 > > My homepage: http://feff.phys.washington.edu/~ravel > EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/ > > > --__--__-- > > _______________________________________________ > Ifeffit mailing list > Ifeffit(a)millenia.cars.aps.anl.gov > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit > > > End of Ifeffit Digest

3 2

Carlo's message and perl 5.8.0
by Bruce Ravel 31 Jul '02

31 Jul '02

Hey, I just thought I would drop a short note to the list explaining in fewer words what Carlo said. The bottom line is that 5.8 and 5.6 are not binary compatible. This is an annoyance that affects many things, including the ifeffit interface. The solution is to go to the place where you unpacked ifeffit and cd to the wrappers/perl/ directory. Rebuild the ifeffit interface by doing make clean perl Makefile.PL make make install I don't think you'll actually need to reinstall athena, but it couldn't hurt. This is not a OSX-only, or debian-only problem. We will all have this annoyance when we get around to updating to perl 5.8 That doesn't make me happy, but I'll deal. Starting to distribute a big tarball with the ifeffit interface bundled with all my codes will actually go along way towards solving that problem. And, if you are not updating to perl 5.8 (or don't even grok what this discussion is about), then you will probably not be affected by this issue. Thanks Carlo! B Bruce Ravel e-mail: ravel(a)phys.washington.edu URL: http://feff.phys.washington.edu/~ravel/

1 0

Perl 5.8.0 packages (fwd)
by Carlo U. Segre 31 Jul '02

31 Jul '02

In reference to the recent mail about Perl 5.8.0. This is specific to the Linux Distribution (Debian) that I use but it explains why version 5.8.0 is not drop in compatible with athena and artemis. Carlo -- Carlo U. Segre -- Professor of Physics Illinois Institute of Technology Voice: 312.567.3498 Fax: 312.567.3494 Carlo.Segre(a)iit.edu http://www.iit.edu/~segre ---------- Forwarded message ---------- Date: Wed, 31 Jul 2002 23:18:29 +1000 From: Brendan O'Dea <bod(a)debian.org> To: "debian-devel-announce(a)lists.debian.org" <debian-devel-announce(a)lists.debian.org> Cc: Debian Perl List <debian-perl(a)lists.debian.org> Subject: Perl 5.8.0 packages Resent-Date: Wed, 31 Jul 2002 08:20:14 -0500 Resent-From: debian-devel-announce(a)lists.debian.org Perl 5.8.0 packages are currently being tested in a staging area: deb http://auric.debian.org/~bod perl/$(ARCH)/ deb-src http://auric.debian.org/~bod perl/ the principal reason for a staging area is that these packages are not binary compatible with the previous perl packages, which means that all binary (XS) modules and programs embedding a perl interpreter will need to be rebuilt. The complete list of packages which will require a rebuild may be obtained by running: apt-cache showpkg perlapi-5.6.0 perlapi-5.6.1 libperl5.6 In addition, since the perl 5.8.0 packages break binary compatibility I've chosen to enable ithreads which may affect some of the packages listed above--notably if packages embedding an interpreter declare their own xs_init subroutine rather than generating one with ExtUtils::Embed::xsinit may need to add a pTHR argument to that function.

1 0

(no subject)
by Bruce Ravel 29 Jul '02

29 Jul '02

Paul said: PF> Just for fun, I tried installing the new perl 5.8.0 release on PF> Mac OS 10.1.5. The perl installation went fine (all the tests PF> passed that should), however, when I tried to reinstall ifeffit, PF> problems ensued. The installation attempt (the very tip) is PF> pasted below. Is this a sign of problems to come? I don't know PF> perl well enough to know where these modules came from. For the PF> moment my resolution is to install perl 5.6.1 (a slight upgrade PF> from the default 5.6.0 included with the OS) I haven't tried perl 5.8.0 myself yet. I presume that there will not be any issue with my code, but obviously I haven't tested it. My best suggestion is to install the ifeffit wrapper by itself without athena. (If you are using an older ifeffit distribution which has an athena subdirectory under wrapper/perl/, delete the athena subdirectory before building the wrapper.). Then install athena afterwards. My next, and more annoying, suggestion, is to clean up any traces of ifeffit's perl inteface (i.e. any instances of the files Ifeffit.pm, Ifeffit.bs, and Ifeffit.so) then try again. All of this points to something that I brought up on the list a while ago and which Matt has been advocating for. It would probably be best to make on big package with the the Ifeffit/perl inteface and my programs all bundled together and distributed separately from Ifeffit. I'll look into that next month. B -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/

1 0

Artemis and Athena
by Bruce Ravel 29 Jul '02

29 Jul '02

Hi Folks, I belive that I have solved the problems that I discussed earlier today for athena and artemis on both windows and unix. I have uploaded new tarballs and windows executables to the "downloads" page. Mark Jensen and Raul Barrea have confirmed that the windows executables posted today work as expected when you drop them into an existing Ifeffit distribution. Thanks guys! Sher Alam informed me of the problem with the missing module in the tarballs. I believe that I have solved that problem, but I would be grateful if you would let me know how it works for you, Sher. I also fixed yet another problem with merging in energy space which was discovered by Shelly Kelly. I believe that I have it working correctly now, but I am sure someone will let me know if that's not the case! This bug is fixed in today's tarballs AND Windows executables. Thanks to Mark, Raul, Sher, and Shelly. I am, as always, quite grateful. Regards, B -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/

2 1

continuous scan data
by Matt Newville 29 Jul '02

29 Jul '02

Hi Everyone, I made some small, probably incomplete, progress on dealing with the problem of continuous scan (or QEXAFS) XAFS data for which the XAFS data is sampled on a fine energy grid -- 1eV was used for the data Raul posted. As mentioned earlier, Ifeffit currently uses a fixed k-grid of 0.05Ang^-1 for chi(k). At k = 10Ang^-1, this corresponds to energy steps of nearly 4eV. Any scheme to use "all the data" to map to chi(k=10) may be tricky. The basic approaches are 1) better interpolation algorithm. 2) change the k-space grid size. 3) doing some sort of averaging of the data around a particular k value. At this point I've tried the first 2 of these. More details are posted at http://cars9.uchicago.edu/ifeffit/qexafs/ including data files and some plots figures. This is all with 'experimental' versions of ifeffit. First, I made the interpolation scheme used for the translation of chi(E) to chi(k) in the spline command have a few options: 'linear' using two surroundings data points 'quadratic' or parabolic using three data points 'cubic spline' put a cubic spline through all the data points Linear interpolation is not very satisfying. The results from 'quadratic' and 'cubic spline' are very similar. The next thing I did was to change the k-grid spacing from 0.050 to 0.025 and to 0.010 Ang^-1, and repeated the use all 3 interpolation schemes. Using 0.050 is noticeably different from 0.025, while 0.025 and 0.010 seem pretty similar to me. This was all done by changing the kgrid at compile time, which will be possible in 1.0073. I also played around with trying to make the kgrid and size of the FFT array variables that can be set at run-time. This seems highly desirable for cases like this. Surprisingly to me, it also seems possible. I have a *highly* experimental version that allow kgrid to be set at run time. In favorable conditions, it even works correctly. There are still some severe bugs with this version that I do not fully understand, and I doubt I'll have much time to work on it soon. But if anyone is very eager to try it, I'd be willing to send it. I have not yet tried implementing any 'averaging of adjacent points' such based on a rolling boxcar or a convolution with a Lorenztian. I could be persuaded to try such things, but at this point I'm not sure what the right thing is. Finally, coming back to the interpolation of the continuous scan data, the data Raul sent has some systematic effects going on that might complicate these comparisons. The effects can be seen from the un-interpolated chi(k) data: http://cars9.uchicago.edu/ifeffit/qexafs/orig_data_zoom.png and the attempts to interpolate this data: http://cars9.uchicago.edu/ifeffit/qexafs/kgrid_zoom.png It looks like there are systematic trends due to insufficient precision (only 4 digits in the mu(E) data). I don't know enough about the electronics used to know if this is intrinsic to the measurements or not. Also, does anyone know how accurate the energies are with this kind of data? Thanks, --Matt

1 0

Re: GIFeffit bugs
by Matt Newville 28 Jul '02

28 Jul '02

Hi Raul, On Fri, 26 Jul 2002, Raul Barrea wrote: > I was working with Gifeffit for windows and I save a session > file as ifeffit.sav but I couldn't open it again. Could you > please check it to see what can be wrong? Yes, GIFEFFIT is not handling the opening of files in directories with spaces in their name. It appears that save files are written correctly and can be read from a directory without a space in the name, but not if there is a space in the name. Should be easy to fix. > I found that log(my_logfile.log) is not working properly in > the windows version of GIfeffit. The program literally > crashes. A visual fortran run time error window appears. This > is not a serious bug but I think you must know it. I think this is related to all the other problems that result in a Visual Fortran Error of the form: forttl: severe (38): error during write, unit -1, file CONOUT$ .... which are come from GUIs that have no DOS console associated with them for simple print statements to be sent. These messages should not be necessary, but making sure that they never happen is harder. A solution should be fairly easy. I hope to post a version with fixes for both of these problems later today or tomorrow. > By the way, have you had any time to find a solution to the > interpolation routine to include all the statistics available > in the experimental data? I've made some progress, but not a complete solution. I'll send a separate post on this later today. --Matt

1 0

Re: [Ifeffit] athena / artemis
by Bruce Ravel 25 Jul '02

25 Jul '02

Hi folks, On Monday I was rushing to get updated versions of Athena and Artemis finished so I could go on a two day trip to NSLS on Tuesday and Wednesday. In my rush, I posted broken versions of Athena and Artemis on my web site. Upon my return, I found my mailbox overflowing with reports of problems. For the Windows users: I belive that Matt correctly identified the problem. I, of course, installed the logos for the splashscreens on *my* computer, but forgot that no one else would have them installed on theirs. That's none too bright! Matt sent me personal email while I was gone stating that he is almost ready to release 1.0073. So here is what I propose. I'll build new executables that do not use the splashscreens and wait for 1.0073 to release that feature. In the future, I'll try very hard to remember to post any new files that need to go into the distribution. Thanks to Mark Jensen, Raul Barrea, and Matt for downloading the executables and reporting back with their problems. For the Unix users: The splashscreens appear to be a problem for unix types as well. The code which handles the splashscreen makes use of a perl module that I had thought was part of the standard distribution but which, in fact, is not. The solution is simple. I'll include the missing module in the source tarballs for athena and artemis and post the new tarballs later today. Thanks to Sher Alam for pointing out this problem. I'll send mail out to the list later today when the new executables and tarballs are in place. Once again, thanks to all of you for taking the time to provide feedback. Your help is very much appreciated. B -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/

1 0

Re: FT padding
by Matt Newville 23 Jul '02

23 Jul '02

Dear Marcus, Recently, Marcus Karolewski wrote: > Dear Matt, > > I have been looking thro' your (highly informative) PhD thesis today in the > hope of finding some discussion about the zero padding used in FT > operations on XAFS data, but there doesn't seem to be any direct reference > to the reasoning behind it, although I gather you padded your data up to 25 > A-1. > > I realise that FT padding makes the data look nice in R-space, but I'd like > to ask whether you know of any other benefit to be gained from it. To my > way of thinking, there seems to be a definite drawback to padding insofar > as one ends up with data that consist mostly of interpolated points in R > space. This would seem to make a mockery of the fitting criteria which > strictly should be based on the actual number of points justified by the > range of the expl data. I would be very interested to hear your comments if > you can find the time. Excellent question! I hope it's OK if I CC this to the ifeffit mailing list, as it's relevant to a current discussion there on interpolating QEXAFS data, and because others might be interested or have opinions on this as well. Short answer: Yes, zero-padding is mostly to make the data look nice in R-space. A mockery of the fitting criteria?? I wouldn't go that far! Just for reference, the important values for the FTs are: kgrid: the k-grid spacing needs to get 'all the features'. N_fft: the FFT should use a number of points = a power of 2, even if zero-padding is used. rmax: the largest frequency that can be seen. rgrid: the resulting grid spacing in R should be small enough to avoid missing real features in R-space. Ifeffit uses kgrid=0.05Ang^-1 and zero-pads chi(k) to have N_fft=2048. The outputs from feffit also use these values. rmax and kgrid are simply related: rmax = pi /(2* kgrid) ~= 31.4 Ang for kgrid=0.05 The spectra above Rmax are a mirror image of the lower-R portion of the spectra: chi(R) = chi(2*Rmax-R) for R > Rmax 31.4Ang is much further than the XAFS really extends, but we can use the high portion to estimate the noise in the signal (feffit does this). So, we probably wouldn't want to go to kgrid=0.10 & rmax=16Ang. In fact, we might be tempted to use a smaller kgrid. The spacing of the R-space data, rgrid, is given as rgrid = pi / (kgrid * N_fft) For N_fft=2048 and kgrid=0.05Ang^-1, rgrid~=0.03Ang. If we had N_fft = 512, we'd have kmax = 0.05 * 512 = 25.6Ang-1 which is probably reasonable -- I've seen a few data sets past 25Ang^-1, but these are rare. We'd also have rgrid = pi / (0.05 * 512 ) = 0.122 Ang This has the advantages of giving data points in R that is closer to the 'real spacing' of "pairs of independent data points" in R-space: Delta R ~= pi / (K-range). The emphasis here should be on the 'approximate' sign. It is tempting to interpret this formula as "my independent data points are exactly 0.XXX Ang apart", but this is a serious overstatement. A better interpretation is that distances separated by less than (2pi/K-range) will be very difficult to distinguish. Using a coarser R spacing does make the fits faster. In fact, feffit (the program) does NOT use N_fft = 2048 when doing the fits -- it uses either 256, 512, 1024, or 2048 depending on the data k-range. This does indeed speed up the fits (for all output arrays, N_fft=2048 is used to make the plots prettier). Long ago (when computers ran on diesel), N_fft=128 was also allowed, but this was not reliable because there was a good chance of getting stuck in a 'false minima' with data that sparsely spaced in R. I've seen such false minima happen a few times, and took out the option of using N_fft = 128. Because it's painful to constantly switch N_fft, ifeffit currently uses kgrid=0.05 and N_fft = 2048 throughout. I have started working toward having these be changeable at will inside the program, but this still causes a few problems at the moment. Anyway, I wouldn't say that using zero padding and a large N_fft is really cheating much. It's really just oversampling the data. An FT is linear, so zero-padding does not change your data (much), but just convolves the 'independent data points' with Gaussian functions. Finally, zero-padding does change your data some because it means that you are asserting that chi(k)=0 for k>kmax. A better approach would be to pad with random noise at a level consistent with your data. This could be done, I suppose, but has not been done yet. Hope that helps, --Matt

1 0

serious athena bug fix
by Bruce Ravel 22 Jul '02

22 Jul '02

Hi folks, Today Shelly Kelly pointed out a serious bug in the code that merges spectra. Spectra merged as mu(E) or norm(E) have not ever been calculated correctly. There were several problems -- the worst was that the e0 shifts for all groups involved in the merge were ignored. This resulted in numerous problems with the merged spectra. I think I have fixed the problem -- at least the sample data that Shelly gave me now gets merged correctly. There is a new source tarball on my web site. I also added a couple of trivial features to both athena and artemis. The first is a splash-screen, i.e. something to look at in those endless seconds between double clicking on the icon and having the program spring to life on the screen. I also added several keyboard shortcuts for common tasks in both programs. You can see what these are by examining the menus in the menubar. I also added something new to my web site. Athena and Artemis change much faster than Ifeffit these days. The bad part of this is that Windows users don't get to take advantage of my updates as often as unix and OSX users. So today I added a section to the downloads page with links to the executables of my four programs. I doubt I will update the executables as often as I update the source tarballs. But when I do, I'll post the executables on the downloads page. The idea of these individual executables is that you replace the executable in the C:\Program Files\Ifeffit\ folder with the new one. These executables now found on my downloads WILL NOT RUN CORRECTLY outside the context of a properly installed ifeffit package. But if you have installed Ifeffit using the installer from Matt's web page, you will be able to drop my new executables in place. Regards, B -- Bruce Ravel ----------------------------------- ravel(a)phys.washington.edu Code 6134, Building 3, Room 222 Naval Research Laboratory phone: (1) 202 767 5947 Washington DC 20375, USA fax: (1) 202 767 1697 NRL Synchrotron Radiation Consortium (NRL-SRC) Beamlines X11a, X11b, X23b, X24c, U4b National Synchrotron Light Source Brookhaven National Laboratory, Upton, NY 11973 My homepage: http://feff.phys.washington.edu/~ravel EXAFS software: http://feff.phys.washington.edu/~ravel/software/exafs/

1 0