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

experimental standard
by Yun Xu 18 Nov '14

18 Nov '14

Hi all I have a complex oxide BaTi8-xGaxO16. What standards I should run? Ga is the dopant. I guess I should run the sample without dopant BaTi8O16 as standard, or the simple oxide as BaO, TiO2 Ga2O3? or is the standard necessary? Also, I have colleage working on DFT, I assume the theoretical standard is the result from the DFT calculation, and by using the coordinates of the atoms, I can run FEFF and fit the data. Thanks Yun

3 3

installing Demeter on Yosemite
by Katherine M. Davis 12 Nov '14

12 Nov '14

Dear all, I was wondering whether anyone had tried installing the software on the new Mac OS (10.10 Yosemite)? Everything seems to work fine initially. I installed Macports and checked it installed correctly. At least when I test various commands, it seems to work. The sudo port install xorg-server demeter-devel command ran for about 3 hours until it quit. I tried restarting, but whenever I run the command, the following error message appears: ---> Computing dependencies for xorg-server ---> Cleaning xorg-server ---> Computing dependencies for demeter-devel ---> Configuring demeter-devel Error: org.macports.configure for port demeter-devel returned: configure failure: command execution failed Please see the log file for port demeter-devel for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_demeter/demeter-devel/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port demeter-devel failed I will post the log file at the bottom of the email. The last 8 lines are as follows: portbuild::add_automatic_buildsystem_dependencies :debug:clean No need to upgrade! p5.16-term-twiddle 2.730.0_1 >= p5.16-term-twiddle 2.730.0_1 :debug:clean epoch: in tree: 0 installed: 0 :debug:clean p5.16-text-template 1.460.0_1 exists in the ports tree :debug:clean p5.16-text-template 1.460.0_1 is the latest installed :debug:clean p5.16-text-template 1.460.0_1 is active :debug:clean Merging existing variants '' int Would anyone be able to help me with this? Any advice would be useful. Thanks for your time. Best, Kate Davis

3 2

Re: [Ifeffit] Fwd: Re: Re: problem about negative
by Bruce Ravel 12 Nov '14

12 Nov '14

On 11/11/2014 10:19 AM, Bruce Ravel wrote: > Rbkg>1.1 can avoid the first peak,but the remaining curve is somewhat > not smooth.How to distinguish whether a long wavelength oscillation > appear as a real peak or false one?I am confused about it. > I find when I avoid the first scattering peak after white > line(kmin=4.8 maybe too large),the first peak of R space > disappeared.Because usually the first scatering peak is related to the > first coordiantion shell,can I think the first peak in R space less 1A > is a real peak instead of noiseï¼ Zhanfei, As I said yesterday, I don't know anything about your sample, so it is hard for me to know what the "right" answer is to your problem. But I can make some observations and some suggestions. * Your data range is really short. As you seem to have noticed (judging from the very short k-range in your project file), your data has serious systematic problems starting at 9 or 10 inverse Angstroms. I cannot quite tell, but your data appear to be transmission data. Well it is possible that you have some instability or nonlinearity at the beamline, I would guess that your sample is not very homogeneous. It is possible that more disciplined sample preparation might help extend that range of the interpretable data. * You are right that slightly increasing the Rbkg value seems to make a positive difference in the extracted chi(k) data. Your data seem to be an example of the sort of data I was alluding to yesterday. The background subtraction is difficult because it is difficult to distinguish the Fourier components of the background function from the Fourier components of the data. I think that the background subtraction with Rbkg=1.1 looks much better than with Rbkg=1.0, but given how different they are, you have to be concerned about the correlations between the background and the parameters of the data. It is clear that your data are of the sort for which background subtraction is difficult. So how do you know what is an acceptable background subtraction? Well, using only Fourier methods, I think we have demonstrated that you cannot know the right answer without some kind of prior knowledge. So, how do you get that prior knowledge? Well, my advice is to first solve some simpler problems. Measure your standards. Measure the common forms of moly oxide and moly sulfide. Measure moly metal. Analyze all of them. The advantage of the standards is that you know what the answer should be. Do the data processing and data analysis. Make sure that, when you do the analysis, you get the right answers. Having done that exercise, you will then have a lot more knowledge about what the various forms of moly oxide look like and what the challenges are when doing the data processing and data analysis. Some questions: - Are there any forms of moly oxide for which the bond length is as short as 1.6? If so, do the conditions of formation exist in your system? Is your sample of a valence consistent with the valence of the Mo when it has such a short bond? - If you convince yourself that it is possible for moly to have an oxygen atom at 1.6 or 1.7, what did you have to do with your standard to get a sensible analysis of the EXAFS data? Hopefully, that will guide you to doing a sensible analysis of your unknown sample. - If none of your moly oxide standards have an O atom at 1.6 or 1.7, why do you think it is chemically reasonable for your unknown sample to have such a short bond? If, in fact, that short bond doesn't exist elsewhere in nature, why would your sample magically have such a short bond? - If you do not believe in such a short bond, then does your experience with the standards give you the confidence to increase Rbkg such that the low-R signal is removed by the background function? I completely understand that you have a compelling reason to understand your unknown sample and that I am suggesting that you spend a good chunk of time measuring and analyzing a bunch of standards that are not your actual research project. That might seem like time that takes you away from your real goal, but you have already demonstrated that you are stumped by your real goal. I am saying the only way to get over your current hurdle is to take a step back and gain a deeper understanding of the data, the physics of EXAFS, the methods of EXAFS analysis, and the intricacies of your current problem. B -- Bruce Ravel ------------------------------------ bravel(a)bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS --- Beamlines U7A, X24A, X23A2 Building 535A Upton NY, 11973 Homepage: http://bruceravel.github.io/home/ Software: https://github.com/bruceravel Demeter: http://bruceravel.github.io/demeter/

2 1

too small bond length in R space
by ZHAN Fei 11 Nov '14

11 Nov '14

Dear all： I encounter a problem of exafs fit in an example of Mo which have Mo-O Mo-S Mo-Mo bond.The problem is that the Mo-O peak in R space has too small bond length (less than 1.4A(+0.5A for phase correction) ).Because when 1.2>rbkg>0.68 there is little change in spectrum of R and k space,and when I increase the value of rmin of forward Fourier transform the peak changes little,so I think it's not a noise.But when I try to fit it use the 1.35A path of Mo-O,I can't fit it well. Could you give me some advise about fit too small bond length,or recommend papers of similar situation? picture of R space is attached. Thanks Sincerely, zhanfei ihep of China

3 5

Larch-0.9.24 with Python2
by Matthias Filez 05 Nov '14

05 Nov '14

Dear mailing list user, When running an example file of Larch-0.9.24 with Python2 on Ubuntu x86_64, the following error was reported. File "Py_usinglarch.py", line 32, in <module> autobk(xafsdat.energy, xafsdat.mu, rbkg=1.0, _larch=my_larch) File "/usr/local/lib/python2.7/dist-packages/larch/__init__.py", line 37, in wrapper return fcn(*args, **keywords) File "/usr/share/larch/plugins/xafs/autobk.py", line 187, in autobk fit.leastsq() File "/usr/local/lib/python2.7/dist-packages/larch/fitting/minimizer.py", line 395, in leastsq lsout = leastsq(self.__residual, self.vars, **lskws) File "/usr/local/lib/python2.7/dist-packages/larch/fitting/minimizer.py", line 222, in leastsq shape, dtype = _check_func('leastsq', 'func', func, x0, args, n) ValueError: need more than 1 value to unpack Is Larch-0.9.24 compatible with Python2 on Ubuntu x86_64? If not, what packages and dependencies could we install to make it work on Python2? Or is Larch-0.9.24 only compatible with Python3? Many thanks in advance, Matthias

3 8

Reporting the fitting data (uncertainty associated with N)
by pushkar shejwalkar 05 Nov '14

05 Nov '14

Dear All, I have seen and also been told by few professors that when you report the fitting you must report the uncertainty associated with the measurement as evaluated by the program used for the fitting. Now, When I do the fitting I typically get the +/- values for E0, delR, ss and SO2. However, the N value we always put either 1,2 or such whole integers. Is there any way to find out the uncertainty associated with the coordination number (N used in XAFS equation)? If so how to find such uncertainty? can we see this in the log file generated after the fitting is over? Thank you very much for the help Best Regards, Pushkar Shejwalkar. Post-doctoral -Researcher,JSPS Fellow Hokkaido University, Sapporo, Japan

2 2

Structure of Au2O3
by kaziz sameh 04 Nov '14

04 Nov '14

Hi all, I need the structure of Au2O3. if you can help me I would be very grateful. Kaziz

2 1

Re: [Ifeffit] inp file - artemis crashing when running feff calc on manually generated inp file
by stephen.parry＠diamond.ac.uk 03 Nov '14

03 Nov '14

The dartemis output log file -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

2 3

inp file - artemis crashing when running feff calc on manually generated inp file
by stephen.parry＠diamond.ac.uk 03 Nov '14

03 Nov '14

Can someone spot the problem with the attached inp file? I have manually reduced a cif file to remove multiple occupancy sites and cut down the unit cell from a large structure. I should be left with the first shell as Cartesian co-ords. I have then overwritten the co-ords and ipots into an old atoms generated inp file. I can't spot any formatting problems but when I run the feff calculation in artemis the program crashes. The feff.run error log file contains nothing obvious. "Feff 6L.02 TITLE Ga_c6h5f TITLE Ga TITLE S TITLE Gallium TITLE Note: mixed occ removed manually SP Calculating potentials and phases... free atom potential and density for atom type 0 free atom potential and density for atom type 1 free atom potential and density for atom type 2 overlapped potential and density for unique potential 0 overlapped potential and density for unique potential 1 overlapped potential and density for unique potential 2 muffin tin radii and interstitial parameters " Any help appreciated. Regards, Steve ================= Dr Stephen Parry Support Scientist, B18 Diamond Light Source Ltd. -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

2 1

Mac support for Demeter
by Bruce Ravel 28 Oct '14

28 Oct '14

Hi gang, I just heard from Frank Schima, the fellow who kindly provided packaging of Demeter via MacPorts. Frank is moving to a new position at NIST Boulder and will no longer be providing IT support for the group out there that does some XAS. That means his availability to maintain and update the MacPorts package will be somewhere between slim and non-existent. Here is what he said: I am no longer working for Quantum Devices as of Friday, 10/31/2014. So I will no longer be involved in updating Demeter and will be unsubscribing from the Ifeffit mailing list. For updates please follow the Macports procedures to request an update in Macports by opening a Trac ticket [1]. I may actually be able to perform the update but I cannot guarantee anything. [1] <https://trac.macports.org/newticket> I know that this support for the Mac was valued by many people in our community, so Frank will be missed. I am not able to provide packaging support for Mac users. Even if I had the time or energy to take on a new packaging responsibility, I simply don't own a Mac. This would be a good time for someone to step up and take over responsibility for the Mac package. It seems that Frank has done the bulk of the work. The MacPort ecosystem seems to be well supported and well documented, so I would think that someone else could readily step into that role. B -- Bruce Ravel ------------------------------------ bravel(a)bnl.gov National Institute of Standards and Technology Synchrotron Science Group at NSLS-II Building 535A Upton NY, 11973 Homepage: http://bruceravel.github.io/home/ Software: https://github.com/bruceravel Demeter: http://bruceravel.github.io/demeter/

2 1