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

Startup Macros
by Emiliano Fonda 31 May '11

31 May '11

Dear all, I would like to write some IFeffit macro and use it in Athena. Actually, I did not find a clean way to load a file with macros at the Athena startup. How can we add our own macros to those that are built-in? Best regards, Emiliano -- Dr. Emiliano Fonda Beamline Scientist (SAMBA) Synchrotron SOLEIL L'Orme des Merisiers Saint Aubin BP48 91192 Gif Sur Yvette CEDEX France Phone +33169359633 Fax +33169359456

2 1

Re: [Ifeffit] more bugs in atoms?
by Gudrun Lisa Bovenkamp 27 May '11

27 May '11

Hi George, I cannot understand how you got this atoms.inp file where the core is stated to be Co1 and there is only Fe. So, I cannot confirm the crystal structure from a database. My problem is solved. I understood that the ATOMS program implemented in Arthemis and ATOMS 2.5 have some bugs that are corrected in ATOMS 3.0 and WebATOMS. When I use those two programs I get a correct crystal structure xyz table in feff.inp. the only reason that I can think of, why your shifting seem to work better is that the atoms.inp file was not representing the correct structure in the first place. This can happen when the situation you wnat to describe is not the situation that was measured by somebody else. Or there is a mistake in the paper. Anyway. Thanks for sharing this idea. Lisa > Date: Thu, 26 May 2011 11:41:08 -0400 >From: George Sterbinsky <GeorgeSterbinsky(a)u.northwestern.edu> > To: XAFS Analysis using Ifeffit <ifeffit(a)millenia.cars.aps.anl.gov> > Subject: Re: [Ifeffit] more bugs in atoms? > Message-ID: <BANLkTi=OH=NCJjmwhkE5vLmnTEao8k3avg(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Lisa, > > Let me just mention one situation I have encountered using atoms, >and how I > resolved it. I am not sure if this is the result of a bug or not, >but > perhaps you can try applying the approach I took to your own >situation and > see if it can resolve your problem. > > The issue I encountered was running atoms for a monoclinic I2/c >structure, > space group 15. > > Here is the atoms input file: > > ! This atoms input file was generated by Artemis 0.8.014 > ! Atoms written by and copyright (c) Bruce Ravel, 1998-2001 > title = ... > space = i 2/c 1 1 > a = 5.51120 b = 5.51120 c = 7.79410 > alpha = 90.0 beta = 90.740 gamma = 90.0 > core = Co1 edge = K rmax = 6.0 > !shift 0.25000 0.25000 0.25000 > atoms > ! elem x y z tag occ. > Fe 0.00000 0.00000 0.00000 Fe1 1.00000 > > If one calculates the Fe-Fe distance between the atom at (0,0,0) and >the > atom at (0, 0, 0.5), from application of the (x, -y, -z+0.5) lattice > translation, one finds a Fe-Fe distance of 3.9705. However, if one >runs the > above atoms input file, this Fe-Fe distance is not found. Instead, a >shift > vector of (0.25, 0.25, 0.25) is needed to get the correct Fe-Fe >distance. > Note, the i2/c space group is listed with only one origin in the > international tables. I determined the necessary shift vector from >trail and > error. It is still unclear to me why it was necessary to include a >shift > vector. So the best suggestion I have is that you can try including > different shift vectors in your own atoms.inp file and see if you >can get > agreement with the crystallography program that way. Since, as I >said, it > isn't clear to me why this fixed my problem, its hard to say if this >is the > same issue you are having, but it may be worth a try. > > It may also be worth while to calculate some atomic distances from >the > lattice positions given in the international tables, and see if >atoms or the > crystallography program is giving you the same thing. > >Finally, let me add on another question for the list here since it is > somewhat related. When one runs the above atoms.inp file with the >(0.25, > 0.25, 0.25) shift vector one finds four Fe1_1 atoms at 3.9701 and >two Fe_2 > atoms at 3.9705. When one then runs Feff, it combines these into a >single >Fe1_1 scattering path with N=6. Is there a command can be placed in >the Feff > input file to tell Feff not to combine identical paths like this? > > Best, > George > >

2 1

Simulation of ion xanes spectra using feff9
by Aurora Clark 27 May '11

27 May '11

Hi; I hope you don¹t mind me posting a question about feff9 to this list, but the feff userlist is defunct. I am trying to learn feff9 by reproducing the work in a JPCA recent paper (JPCA 2011, 115, 2345). I have a calculated structure for U(H2O)8]4+ ion that is nearly identical to that of the paper and so I am using that structure. I have been able to run several test cases for feff9 and I think I have a reasonable understanding of the different cards in feff9 however there are definitely some particulars for these f-element ions that are eluding me. My primary question surround how to deal with ion charge 1. I have tried several options with the ion card, everything from the U having a charge of 4 and the O-atoms zero, to partial charges like 2 and 0.25. However, in each case I get errors that state: ION: Expert option, please read documentation carefully and check your results. ION: Expert option, please read documentation carefully and check your results. U4+-8h2o Now if I run the calculation with no charges on the atoms everything proceeds very smoothly. The manual states that charges typically should not exceed 1 for an atom but in a highly charged system what are you to do? Thank you; Aurora

1 0

Re: [Ifeffit] more bugs in atoms?
by Gudrun Lisa Bovenkamp 26 May '11

26 May '11

Hi George, thanks for responding. I sure imported the same structural information into atoms and the crystal structure program. Lisa > > Hi Lisa, > > I'm not very familiar with PbSO4, so I'm not sure if I can help, but >your > email immediately brought some questions to mind. > >First, did you import the same information into atoms and the crystal > structure program? The way you worded your message made me think >that the > crystal structure program already "knew" the structure of PbSO4, in >which > case perhaps it is using a structure that is slightly different from >the one > you import into atoms. > > Second, what is the source of the structure data you are feeding >into atoms? > In my experience, errors and inconsistencies in the reporting of >structure > data in the literature can lead to unusual results in atoms. > > Best, > George > > >

3 2

Re: [Ifeffit] Can Artemis Simulate a FT Spectrum?
by Palomino, Robert 19 May '11

19 May '11

Matt, Thank you. How would I go about making a theory sum? Would I have to do that in another graphing program or can it be done in Artemis? -----Original Message----- From: ifeffit-bounces(a)millenia.cars.aps.anl.gov [mailto:ifeffit-bounces@millenia.cars.aps.anl.gov] On Behalf Of ifeffit-request(a)millenia.cars.aps.anl.gov Sent: Thursday, May 19, 2011 1:00 PM To: ifeffit(a)millenia.cars.aps.anl.gov Subject: Ifeffit Digest, Vol 99, Issue 17 Send Ifeffit mailing list submissions to ifeffit(a)millenia.cars.aps.anl.gov To subscribe or unsubscribe via the World Wide Web, visit http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit or, via email, send a message with subject or body 'help' to ifeffit-request(a)millenia.cars.aps.anl.gov You can reach the person managing the list at ifeffit-owner(a)millenia.cars.aps.anl.gov When replying, please edit your Subject line so it is more specific than "Re: Contents of Ifeffit digest..." Today's Topics: 1. Can Artemis Simulate a FT spectrum? (Palomino, Robert) 2. Re: Can Artemis Simulate a FT spectrum? (Matt Newville) ---------------------------------------------------------------------- Message: 1 Date: Thu, 19 May 2011 11:38:45 -0400 From: "Palomino, Robert" <rpalomino(a)bnl.gov> To: <ifeffit(a)millenia.cars.aps.anl.gov> Subject: [Ifeffit] Can Artemis Simulate a FT spectrum? Message-ID: <B32CD18BE9D42745B75847F981879A3602051206(a)exchangemb3.bnl.gov> Content-Type: text/plain; charset="us-ascii" Hi, I was wondering if it was possible for Artemis to simulate a FT spectrum, I have a model and would like to visually see what the simple R-space spectrum would like so see if there are any similarites at all to my sample. I'm not sure if the reason it doesn't converge is because the signal level is too low or if it is the wrong model all together. Robert

2 1

Can Artemis Simulate a FT spectrum?
by Palomino, Robert 19 May '11

19 May '11

Hi, I was wondering if it was possible for Artemis to simulate a FT spectrum, I have a model and would like to visually see what the simple R-space spectrum would like so see if there are any similarites at all to my sample. I'm not sure if the reason it doesn't converge is because the signal level is too low or if it is the wrong model all together. Robert

2 1

Athena (Question about LC fitting)
by Yu-Ting Liu 15 May '11

15 May '11

Hi, Related to this issue, I have a question about whether alignment is necessary for LCF when the oxidation state among sample and standards is different. I used to align spectra of samples and standards before LCF while handling P. However, I got confused about Se. For Se speciation, I prepared six Se species with oxidation state of -2 (FeSe), 0 (elemental Se), 0 (seleno-cystine), 0 (seleno-methionine), 4 (selenite), and 6 (selenate) to fit samples collected from sediments and biofilms. I am wondering whether the shift of spectra due to the alignment would make standards mis-fit spectral features of samples. Thank you so much for the help! Yu-Ting Liu Yu-Ting (Lusia) Liu Postdoctoral Associate Duke University Civil and Environmental Engineering Durham, NC, 27708-0287 ------------------------------------------------------------------------------- Belay, I am CCing my response to the Ifeffit Mailing List, which is the appropriate venue for questions about the use fo the software. I encourage you to subscribe to and use the mailing list. On Tuesday, May 10, 2011 08:50:10 am you wrote: > Dear Dr. Ravel, > I am doing my PhD in title with identication of Fe-phases in cement > hydrates. I am using Athena for LC fitting. I use EXAFS spectra for the > fittings. My question is before LC fitting of EXAFS spectra , do I need to > calibrate the energy? I have normlized and alligned the spectra very well. > The problem is data calibration, when I calibrate the spectra, the energy > shifts and it destroys the fitting. Can you please give a clue why this > happens or do I make a mistake on the procedure? Thanks so much for your > cooperation. Alignment puts a group of spectra on the same relative energy scale. It is often necessary to do an explicit alignment when working at a beamline with an unstable and unencoded monochromator, as might be found at some older beamlines. Calibration intends to put a single spectrum on the correct absolute energy scale. That is, if you know what point in a spectrum represents a particular absolute energy, then calibration does as I said. LCF requires that the ensemble of data and standards all be aligned -- i.e. put on the same relative energy axis. Once that is done, you can proceed with LCF analysis. LCF does not require that the data be calibrated, only that they be aligned. That is, LCF requires that all the data+standards be on the same relative energy axis, but does not require that that energy axis be calibrated. The reason that is so is because LCF fitting is an abstract, numerical function that treats one data set (the "data") as a linear combination of two or more other data sets (the "standards"). No part of that mathematical process requires knowledge of the species of the absorber atom. Indeed, LCF does not require that the x-axis represent energy, only that it be the same for all data+standards. That said, the interpretation of your data might be easier to consider and easier to present in publcation if your data is calibrated. For instance, the Xray Data Booklet tells us that copper metal has an edge at 8979 eV. Calibration is the process of transforming your data such that its edge does, in fact, happen at 8979 eV. In Athena, using the calibration dialog both does an energy shift and sets the E0 value to 8979. If you want to calibrate your data as well as aligning your data, I find it less confusing to do the calibration first. I believe that the procedures can be commutative, but calibrating after aligning is confusing to me and more prone to error for me. Someone else might give you different advice. Finally, remember that calibration requires actual knowledge (as opposed to some assumption) about what point in a spectrum represents a particular absolute energy value. While you might reasonably assign the first big peak in the first derivative of copper metal to 8979 eV, you cannot correctly assign the first big peak in the first derivative of copper oxide to 8979 eV due to the upwards shift in threshold energy in the oxide. HTH, B

2 2

Re: [Ifeffit] Question about transform windows and statistical parameters
by Scott Calvin 13 May '11

13 May '11

Matt, On May 13, 2011, at 8:39 AM, Matt Newville wrote: >> >> After all, the epsilon should be different for different k-ranges, >> as your signal to noise ratio probably changes as a function of k. >> Using the same epsilon doesn't reflect that. > > Without seeing the data in question, this seems like speculation to > me. I'm not at all sure why epsilon (the variation in chi(k)) > should depend strongly on the k-range. In my experience, it usually > does not. The S/N ratio will surely change with k, but that would > surely be dominated by the rapid decay in |chi(k)|, rather than a > change in epsilon. I'm confused. We Fourier transform k-weighted data. Since Ifeffit uses the high-R amplitude to estimate uncertainty, it seems to me that what matters is signal-to-noise, not just noise in the original unweighted chi(k). Am I wrong in that? I may be misunderstanding how epsilon_r is calculated. And epsilon_r is the relevant epsilon for a fit in R space, right? > > I think your assumption that epsilon will depend strongly on k may > not correct. Do you have evidence for this? I would say that it > is not strongly dependent on k, and that reduced chi-square is > useful in comparing fits with different k-ranges. I just tried it on the FeC2O4 chi(k) attached to this post. It's a good example of data where it's not immediately clear to me what the "best" value for kmax is, so it would be tempting to use RCS to compare fits over different k-ranges. I used k-weight 3, and Hanning windows with dk = 1. I chose kmin as 2 and stepped kmax by 0.5, recording epsilon_r for each: kmax epsilon_r 7 0.034840105 7.5 0.041843848 8 0.082627337 8.5 0.087550367 9 0.086032007 9.5 0.085996216 10 0.088679339 10.5 0.090364699 11 0.092509939 11.5 0.108103081 There's a general trend of increasing epsilon_r with an increase in k. There's also a jump of a factor of 2 between 7.5 and 8. Why? Because there's a glitch there, and the glitch adds high-R structure. To make sure there wasn't something odd about this particular chi(k), I took one of the data sets included with the horae distribution: the file y300.chi in the ybco folder. I followed the same procedure as before, except I stepped by 1 inverse angstrom each time, because of the greater data range. kmax epsilon_r 7 0.012866125 8 0.073383695 9 0.078255772 10 0.080016040 11 0.091634572 12 0.105419473 13 0.164341701 14 0.195266957 15 0.224727593 16 0.411139882 17 0.480293296 If anything, the trend is more clear here. > > I find it confusing that you expect the noise in the data to depend > (strongly, even) on k, but not on R. The general wisdom is the > estimate of epsilon from the high-R components is too low, > suggesting that the R dependence is significant. Every time I've > looked, I come to the conclusion that noise in data is either > consistent with "white" or so small as to be difficult to measure. > I believe Corwin Booth's recent work supports the conventional > wisdom that epsilon decreases with R, but I don't recall it > suggesting a significant k dependence. I'm not making any claims as to whether, in general, the noise in the data depends on R. I can speculate about circumstances where low R noise is greater (due, for instance, to temperature fluctuations in cooling water, which are likely to be fairly slow), or where high R noise is greater (an example here would be if whatever system is keeping the beam on the sample vertically as the mono scans is tending to overshoot). But Ifeffit's estimation of epsilon_r demonstrably does not depend on the R-range used for fitting, regardless of the distribution of noise in R. That's a very different thing. Thus, changing the R-range of a fit is completely safe as far as comparing RCS goes. --Scott Calvin Sarah Lawrence College

2 1

Re: [Ifeffit] Question about transform windows and statistical parameters
by Scott Calvin 13 May '11

13 May '11

Hi Brandon, Matt and Bruce both gave good, thorough answers to your questions this morning. Nevertheless, I'm going to chime in too, because there are some aspects of this issue I'd like to put emphasis on. On May 11, 2011, at 8:46 PM, Brandon Reese wrote: > I tried your suggestion with epsilon and the chi-square values came > out to be very similar values with the different windows. Does this > mean that reporting reduced chi-square values in a paper that > compared several data sets would not be necessary and/or appropriate? Bruce said "no" emphatically, and I say "yes," but I think we've understood the question differently. As Bruce says: > Of course, reduced chi-square can only be compared for fitting > models which compute epsilon the same way or use the same value for > epsilon. That's the key point. I've gotten away from reporting values for reduced chi-square (RCS). That's a personal choice, and is not in accord with the International X-Ray Absorption Society's Error Reporting Recommendation, available here: http://ixs.iit.edu/subcommittee_reports/sc/ I think the difficulty in choosing epsilon is more likely to make a reduced chi-square number confusing than enlightening. But I am moving increasingly toward reporting changes in reduced chi-square between fits on the same data, and applying Hamilton's test to determine if improvements are statistically significant. > Would setting a value for epsilon allow comparisons across > different k-ranges, different (but similar) data sets, or a > combination of the two using the chi-square parameter? > Maybe not. After all, the epsilon should be different for different k- ranges, as your signal to noise ratio probably changes as a function of k. Using the same epsilon doesn't reflect that. > > > In playing around with different windows and dk values my fit > variables generally stayed within the error bars, but the size of > the error bars could change more than a factor 2. Does this mean > that it would make sense to find a window/dk that seems to "work" > for a given group of data and stay consistent when analyzing that > data group? The fact that your variables stay within the error bars is good news. The change in the size of the error bars may be related to a less-than- ideal value for dk you may have used for the Kaiser-Bessel window. But yes, find a window and dk combination that seems to work well and then stay consistent for that analysis. Unless the data is particularly problematic, I'd prefer making a reasoned choice before beginning to fit and then sticking with it; a posteriori choices for that kind of thing make me a little nervous. * * * At the risk of being redundant, four quick examples. Example 1: You change the range of R values in the Fourier transform over which you are fitting a data set. For this example, RCS is a valuable statistic for letting you know whether the fit supports the change in R-range. Example 2: You change the range of k values over which you are fitting your data. For this example, comparing RCS is unlikely to be useful. You are likely trying different k-ranges because you are suspicious about some of the data at the extremes of your range. Including or excluding that data likely implies epsilon should be changed, but by how much? Thus the unreliability of comparing RCS in this case. Example 3: You change constraints on a fit on the same data range. For this example, comparing RCS is very useful. Example 4: You compare fits on the same data range, with the same model, on two different data sets which were collected during the same synchrotron run under similar conditions. For this example, proceed with caution. You may decide to trust Ifeffit's method for estimating epsilon, or you may be able to come up with your own (perhaps basing it on the size of the edge jumps). Hopefully issues like glitches and high-frequency jitter are nearly the same for both samples, which gives you a fighting chance of making reasonable estimates of epsilon. Done with a little care, there may be value in comparing RCS for this kind of case. --Scott Calvin Sarah Lawrence College

3 2

more bugs in atoms?
by Gudrun Lisa Bovenkamp 12 May '11

12 May '11

Hey everybody, For a while I was wondering why I could not get a proper XANES simulation using FEFF (8 or 9). Recently I realized that the xyz list which is created in atoms from the crystal structure is not the same as from a crystal structure program for PbSO4. Can somebody please check this. I attached my feff.imp file including the atoms.imp (which was created by arthemis). Thanks, Lisa * input file was generated by Artemis 0.8.014 * Atoms written by and copyright (c) Bruce Ravel, 1998-2001 * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * * total mu*x=1: 13.94 microns, unit edge step: 24.69 microns * specific gravity = 5.382 * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * * Normalization correction: 0.00039 ang^2 * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * -- * * ----------------------------------------------------------------- * The following crystallographic data were used: * * title *-PbSO4 -[PNMA] Anglesite - orthorhombic * title 'James, R W' * title Proceedings of the Royal Society of London, Series A: Mathematical and Physical Sciences (76,1906-) * space = P n m a * a = 8.450 b = 5.380 c = 6.930 * alpha = 90.0 beta = 90.0 gamma = 90.0 * core = Pb edge = L3 * atoms * ! elem x y z tag occ * Pb 0.31530 0.25000 0.33750 1.00000 * S 0.44300 0.25000 -0.19470 1.00000 * O -1.00000 -1.00000 -1.00000 1.00000 * ----------------------------------------------------------------- EDGE L3 S02 1.0 CONTROL 1 1 1 1 1 1 PRINT 1 0 0 0 0 0 SCF 5.16556 0 15 0.1 EXCHANGE 0 0 0 XANES 6.0 0.07 0.5 FMS 6 *LDOS -20 20 0.1 POTENTIALS * ipot z [ label l_scmt l_fms stoichiometry ] 0 82 Pb -1 -1 0 1 8 O -1 -1 1 2 16 S -1 -1 1 3 82 Pb -1 -1 1 ATOMS * this list contains 156 atoms * x y z ipot tag distance 0.00000 0.00000 0.00000 0 Pb 0.00000 1.56072 1.34500 1.12613 3 O_1 2.34799 1.56072 -1.34500 1.12613 3 O_1 2.34799 1.07906 0.00000 3.24185 2 S_1 3.41672 -2.18263 2.69000 -0.22315 2 S_2 3.47128 -2.18263 -2.69000 -0.22315 2 S_2 3.47128 2.04237 2.69000 -0.98960 2 S_3 3.51947 2.04237 -2.69000 -0.98960 2 S_3 3.51947 -2.66429 1.34500 -2.33887 3 O_2 3.79180 -2.66429 -1.34500 -2.33887 3 O_2 3.79180 1.07906 0.00000 -3.68815 2 S_4 3.84276 -3.14594 0.00000 2.47540 2 S_5 4.00307 4.22500 0.00000 -1.21275 1 Pb_1 4.39561 -4.22500 0.00000 -1.21275 1 Pb_1 4.39561 1.56072 4.03500 1.12613 3 O_3 4.47049 1.56072 -4.03500 1.12613 3 O_3 4.47049 -1.10357 2.69000 3.46500 1 Pb_2 4.52329 -1.10357 -2.69000 3.46500 1 Pb_2 4.52329 -1.10357 2.69000 -3.46500 1 Pb_2 4.52329 -1.10357 -2.69000 -3.46500 1 Pb_2 4.52329 3.12143 2.69000 2.25225 1 Pb_3 4.69596 3.12143 -2.69000 2.25225 1 Pb_3 4.69596 -2.66429 4.03500 -2.33887 3 O_4 5.37122 -2.66429 -4.03500 -2.33887 3 O_4 5.37122 0.00000 5.38000 0.00000 1 Pb_4 5.38000 0.00000 -5.38000 0.00000 1 Pb_4 5.38000 -3.14594 0.00000 -4.45460 2 S_6 5.45348 -2.66429 1.34500 4.59112 3 O_5 5.47593 -2.66429 -1.34500 4.59112 3 O_5 5.47593 5.30406 0.00000 2.47540 2 S_7 5.85326 1.56072 1.34500 -5.80387 3 O_6 6.15872 1.56072 -1.34500 -5.80387 3 O_6 6.15872 3.12143 2.69000 -4.67775 1 Pb_5 6.23384 3.12143 -2.69000 -4.67775 1 Pb_5 6.23384 1.07906 5.38000 3.24185 2 S_8 6.37325 1.07906 -5.38000 3.24185 2 S_8 6.37325 -5.32857 2.69000 2.25225 1 Pb_6 6.37984 -5.32857 -2.69000 2.25225 1 Pb_6 6.37984 5.78571 1.34500 -2.33887 3 O_7 6.38387 5.78571 -1.34500 -2.33887 3 O_7 6.38387 1.07906 5.38000 -3.68815 2 S_9 6.61145 1.07906 -5.38000 -3.68815 2 S_9 6.61145 -2.66429 4.03500 4.59112 3 O_8 6.66769 -2.66429 -4.03500 4.59112 3 O_8 6.66769 -3.14594 5.38000 2.47540 2 S_10 6.70589 -3.14594 -5.38000 2.47540 2 S_10 6.70589 6.26736 2.69000 -0.22315 2 S_11 6.82391 6.26736 -2.69000 -0.22315 2 S_11 6.82391 2.04237 2.69000 5.94040 2 S_12 6.83343 2.04237 -2.69000 5.94040 2 S_12 6.83343 5.30406 0.00000 -4.45460 2 S_13 6.92651 0.00000 0.00000 6.93000 1 Pb_7 6.93000 0.00000 0.00000 -6.93000 1 Pb_7 6.93000 4.22500 5.38000 -1.21275 1 Pb_8 6.94736 -4.22500 5.38000 -1.21275 1 Pb_8 6.94736 4.22500 -5.38000 -1.21275 1 Pb_8 6.94736 -4.22500 -5.38000 -1.21275 1 Pb_8 6.94736 1.56072 6.72500 1.12613 3 O_9 6.99497 1.56072 -6.72500 1.12613 3 O_9 6.99497 -6.40764 2.69000 -0.98960 2 S_14 7.01949 -6.40764 -2.69000 -0.98960 2 S_14 7.01949 4.22500 0.00000 5.71725 1 Pb_9 7.10898 -4.22500 0.00000 5.71725 1 Pb_9 7.1089 END

2 1