Re: [Ifeffit] bug in Athena

[Noerpel, Matt]

Hello Alex,

There are two options in the LCF page that may help.  If you don’t want any 
negative values try selecting “All weights between 0 and 1” and unselecting 
“Force weights to sum to 1”.

Matt

From: Ifeffit  On Behalf Of 
Alexander Zherebker
Sent: Wednesday, January 24, 2024 7:35 AM
To: ifeffit@millenia.cars.aps.anl.gov
Subject: [Ifeffit] bug in Athena

Caution: This email originated from outside EPA, please exercise additional 
caution when deciding whether to open attachments or click on provided links.

Hello!

I faced an issue with 0.9.26 Athena. Doing LCF the option for weights doesn't 
really work so I keep getting negative components.

Cheers,
Alex


___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

[Ifeffit] bug in Athena

[Alexander Zherebker]

Hello!

I faced an issue with 0.9.26 Athena. Doing LCF the option for weights
doesn't really work so I keep getting negative components.

Cheers,
Alex
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Bug report: Athena, multiple data export

[Matt Newville]

Hi Soyoung,

On Fri, Oct 8, 2021 at 5:29 PM Soyoung Kim  wrote:

> I see. Thank you for the quick reply.
>
> But would it be difficult to program it so that it will export properly,
> e.g., with multiple energy axes?
>

Sorry for the slight delay, and I have two answers here:

In general, it depends on what "export properly" means. If you save the
project file, the original, differing energy arrays will be retained.  If
you export to a simple ASCII column file (which is pretty ubiquitous in
scientific data), then each numeric row will be (or perhaps "is likely to
be") interpreted as the same "x" axis (energy or perhaps time - the
independent variable).   So, if you have multiple sets of data with
differing x/energy values, either you have missing values for some data
sets or you have data in rows without a consistent x/energy, and possibly a
different number of rows per column.  Many programs will struggle with such
data files.

But

Because when the data is plotted as a graph, it is hard to tell whether or
> not the x-axes are the same... And if you are processing data from someone
> else, you may not know whether or not they were collected with the same
> energy step settings.
>

That's all true.

And also: it looks to me that the exported data from this project looks
like it is not interpolated as well as it could be. There is a definite
shift in energy in the EXAFS region.

If I read that project into Larch's XAS Viewer and export it as a CSV file
it also interpolates all arrays onto a single energy grid (by default, the
first data set) and it looks better to me (see attached file -- needs
development version of XAS Viewer for this level of details).

I'm not entirely sure where the problem is. It does look like one of the
data sets has two energy points that are very close together as the data
transitions from constant energy steps in the XANES region to wider steps
in the EXAFS region.  That should not cause a problem, but I think that I
do recall that there were some such problems in the past.

We've tried to make XAS Viewer a replacement for Athena and Artemis.   I am
aware of a few missing features, but there are also several features not in
Athena.  I can say that it would be easier for me to fix things with
Larch/XAS Viewer than it is for me to fix things in Athena.

I'm not sure that resolves the issue, but I hope it helps.

--Matt
# 2 files saved Sun Oct 10 23:05:24 2021
# saving x array='energy', y array='norm'
# data1: data1
# data2: data2
#--
# energy data1 data2
4815.00 0.001453 0.001690
4825.00 0.000822 0.000912
4835.00 0.000460 0.000493
4845.00 0.000130 0.96
4855.00 -0.000157 -0.000221
4865.00 -0.000333 -0.000342
4875.00 -0.000527 -0.000602
4885.00 -0.000622 -0.000622
4895.00 -0.000661 -0.000545
4905.00 -0.000571 -0.000717
4915.00 -0.000355 -0.000431
4925.00 -0.000194 -0.000183
4925.25 -0.99 -0.90
4925.50 -0.000137 -0.26
4925.75 -0.35 -0.000216
4926.00 -0.000138 -0.93
4926.25 -0.87 -0.57
4926.50 -0.22 -0.000131
4926.75 -0.73 -0.43
4927.00 -0.54 -0.15
4927.25 -0.77 0.22
4927.50 -0.22 -0.22
4927.75 -0.31 -0.60
4928.00 0.07 -0.000111
4928.25 -0.07 -0.12
4928.50 0.24 0.000120
4928.75 0.000129 0.000133
4929.00 -0.27 -0.31
4929.25 0.21 0.000126
4929.50 0.02 0.000102
4929.75 0.000175 0.000146
4930.00 0.000181 0.98
4930.25 0.000120 0.62
4930.50 0.99 0.000182
4930.75 0.000149 0.000302
4931.00 0.000140 0.000247
4931.25 0.000149 0.000169
4931.50 0.000265 0.52
4931.75 0.000187 0.000186
4932.00 0.000163 0.000254
4932.25 0.000161 0.000328
4932.50 0.000337 0.000265
4932.75 0.000267 0.000309
4933.00 0.000241 0.000317
4933.25 0.000353 0.000428
4933.50 0.000349 0.000468
4933.75 0.000313 0.000472
4934.00 0.000357 0.000432
4934.25 0.000413 0.000417
4934.50 0.000348 0.000373
4934.75 0.000435 0.000430
4935.00 0.000430 0.000403
4935.25 0.000445 0.000549
4935.50 0.000517 0.000485
4935.75 0.000496 0.000453
4936.00 0.000496 0.000410
4936.25 0.000550 0.000529
4936.50 0.000471 0.000627
4936.75 0.000556 0.000605
4937.00 0.000647 0.000682
4937.25 0.000623 0.000636
4937.50 0.000681 0.000806
4937.75 0.000688 0.000709
4938.00 0.000734 0.000610
4938.25 0.000726 0.000498
4938.50 0.000648 0.000657
4938.75 0.000665 0.000524
4939.00 0.000747 0.000738
4939.25 0.000834 0.000892
4939.50 0.000810 0.000900
4939.75 0.000880 0.000767
4940.00 0.000882 0.000733
4940.25 0.000857 0.000880
4940.50 0.000916 0.000922
4940.75 0.000795 0.000897
4941.00 0.000997 0.000900
4941.25 0.000984 0.001074
4941.50 0.000967 0.000955
4941.75 0.001034 0.001153
4942.00 

Re: [Ifeffit] Bug report: Athena, multiple data export

[Anatoly Frenkel]

" But would it be difficult to program it so that it will export properly,
e.g., with multiple energy axes?"
- that is what saving as unique files means.
---
Anatoly I. Frenkel
Professor
Department of Materials Science and Chemical Engineering
Stony Brook University
Stony Brook, NY 11794, Ph: 631-632-2751
Email:  anatoly.fren...@stonybrook.edu

http://you.stonybrook.edu/frenkel

Joint Appointment:
Chemistry Department, Brookhaven National Laboratory
Upton, NY 11973. Ph: 631-344-3013. Group: 631-344-3494
Email: fren...@bnl.gov
https://www.bnl.gov/staff/frenkel
Spokesperson, Synchrotron Catalysis Consortium (SCC) at BNL
http://you.stonybrook.edu/scc2
---


On Fri, Oct 8, 2021 at 6:29 PM Soyoung Kim  wrote:

> I see. Thank you for the quick reply.
>
> But would it be difficult to program it so that it will export properly,
> e.g., with multiple energy axes? Because when the data is plotted as a
> graph, it is hard to tell whether or not the x-axes are the same... And if
> you are processing data from someone else, you may not know whether or not
> they were collected with the same energy step settings.
>
> Best,
> Soyoung
>
> On Fri, Oct 8, 2021 at 3:24 PM Anatoly Frenkel <
> anatoly.fren...@stonybrook.edu> wrote:
>
>> It is not a bug. When groups have unique energy axes they should be saved
>> in different files.
>>
>> Anatoly
>>
>> > On Oct 8, 2021, at 6:19 PM, Soyoung Kim  wrote:
>> >
>> > 
>> > Dear Bruce and IFEFFIT community,
>> >
>> > Hope all is well. I found a bug with Athena's file export function. I
>> had two normalized mu(E) data with very similar spectra but different
>> x-axis values (collected with different energy step settings).
>> > 
>> >
>> > When I batch exported them to a .dat file using the purple E button
>> while "Save next plot to a file" was turned on, the resulting data only had
>> a single x-axis column, which was taken from the first data. Hence, when I
>> plot the two spectra from this .dat file, they now look different:
>> > 
>> >
>> > If I export each data individually to .dat files, then they are correct.
>> > 
>> >
>> >
>> > I'm attaching the Athena project file containing the two data and the
>> .dat files I exported, both together and individually.
>> >
>> > Please let me know if anything is unclear. Thank you in advance for
>> your help.
>> >
>> > Best,
>> > Soyoung Kim
>> >
>> > 
>> > 
>> > 
>> > 
>> > ___
>> > Ifeffit mailing list
>> > Ifeffit@millenia.cars.aps.anl.gov
>> > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
>> > Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
>>
>> ___
>> Ifeffit mailing list
>> Ifeffit@millenia.cars.aps.anl.gov
>> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
>> Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
>>
>
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Bug report: Athena, multiple data export

[Soyoung Kim]

I see. Thank you for the quick reply.

But would it be difficult to program it so that it will export properly,
e.g., with multiple energy axes? Because when the data is plotted as a
graph, it is hard to tell whether or not the x-axes are the same... And if
you are processing data from someone else, you may not know whether or not
they were collected with the same energy step settings.

Best,
Soyoung

On Fri, Oct 8, 2021 at 3:24 PM Anatoly Frenkel <
anatoly.fren...@stonybrook.edu> wrote:

> It is not a bug. When groups have unique energy axes they should be saved
> in different files.
>
> Anatoly
>
> > On Oct 8, 2021, at 6:19 PM, Soyoung Kim  wrote:
> >
> > 
> > Dear Bruce and IFEFFIT community,
> >
> > Hope all is well. I found a bug with Athena's file export function. I
> had two normalized mu(E) data with very similar spectra but different
> x-axis values (collected with different energy step settings).
> > 
> >
> > When I batch exported them to a .dat file using the purple E button
> while "Save next plot to a file" was turned on, the resulting data only had
> a single x-axis column, which was taken from the first data. Hence, when I
> plot the two spectra from this .dat file, they now look different:
> > 
> >
> > If I export each data individually to .dat files, then they are correct.
> > 
> >
> >
> > I'm attaching the Athena project file containing the two data and the
> .dat files I exported, both together and individually.
> >
> > Please let me know if anything is unclear. Thank you in advance for your
> help.
> >
> > Best,
> > Soyoung Kim
> >
> > 
> > 
> > 
> > 
> > ___
> > Ifeffit mailing list
> > Ifeffit@millenia.cars.aps.anl.gov
> > http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
> > Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
>
> ___
> Ifeffit mailing list
> Ifeffit@millenia.cars.aps.anl.gov
> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
> Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit
>
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Bug report: Athena, multiple data export

[Anatoly Frenkel]

It is not a bug. When groups have unique energy axes they should be saved in 
different files. 

Anatoly

> On Oct 8, 2021, at 6:19 PM, Soyoung Kim  wrote:
> 
> 
> Dear Bruce and IFEFFIT community,
> 
> Hope all is well. I found a bug with Athena's file export function. I had two 
> normalized mu(E) data with very similar spectra but different x-axis values 
> (collected with different energy step settings).
> 
> 
> When I batch exported them to a .dat file using the purple E button while 
> "Save next plot to a file" was turned on, the resulting data only had a 
> single x-axis column, which was taken from the first data. Hence, when I plot 
> the two spectra from this .dat file, they now look different:
> 
> 
> If I export each data individually to .dat files, then they are correct.
> 
> 
> 
> I'm attaching the Athena project file containing the two data and the .dat 
> files I exported, both together and individually.
> 
> Please let me know if anything is unclear. Thank you in advance for your help.
> 
> Best,
> Soyoung Kim
> 
> 
> 
> 
> 
> ___
> Ifeffit mailing list
> Ifeffit@millenia.cars.aps.anl.gov
> http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
> Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

Re: [Ifeffit] Bug report ATHENA (Demeter 0.9.24)

[Ravel, Bruce]

Sunil,

You are correct.  Athena does not save settings from the LCF tool.  That's not 
so much a bug as it is a missing feature.

It's on my to do list (there's a link to the to do list on the Demeter home 
page).  I am hoping to make a new release next month ... I will try to address 
this before then.

B


--
 Bruce Ravel   bra...@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


From: Ifeffit [ifeffit-boun...@millenia.cars.aps.anl.gov] on behalf of Patel, 
Sunil [sunil.pa...@honeywell.com]
Sent: Monday, May 16, 2016 5:54 AM
To: ifeffit@millenia.cars.aps.anl.gov
Subject: [Ifeffit] Bug report ATHENA (Demeter 0.9.24)

Hello All,
I am using the latest version of Demeter (0.9.24) in Windows 7 Enterprise 
(64-bit).
In the process of doing LCF, the fit details (for ex. standards used for 
fitting, fitting range, phase fractions etc.) are not saved into the project 
file. This (very useful!) feature was available in the older version of ATHENA.

Please find attached a project file. To reproduce the problem:

  1.  Open the project file in new ATHENA.
  2.  Do LCF for marked datasets (Data_1 to Data_6) using standards (Standard_1 
and Standard_2), with LCF range= -20 to 40 eV and hitting the “Fit marked 
groups” tab.
  3.  Save the project file and close it.
  4.  Re-open the file and go to the LCF page. The details are not saved. We 
need to re-do the fits to get the values.
  5.  To check, open the ATHENA project file in older version of ATHENA and 
repeat the above steps. LCF details are shown on re-opening the file.

A similar bug report was made last year for an earlier version of Demeter 
(0.9.21).

(http://www.mail-archive.com/ifeffit%40millenia.cars.aps.anl.gov/msg05057.html )

Thanks & regards,
Sunil Patel

___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit
Unsubscribe: http://millenia.cars.aps.anl.gov/mailman/options/ifeffit

[Ifeffit] Bug in Athena merge preferences?

[Scott Calvin]

Hi Bruce (and Ifeffiteers),

I'm not positive this is a bug--maybe I'm just misunderstanding how  
the features are supposed to work. (It wouldn't be the first time!)


In Athena 0.8.061 on a Mac running OS 10.5.8, I tried the following (I  
tried it in more than one project, to make sure it's not an  
intermittent bug):


--Under Edit Preferences/Merge/Merge_Weight, choose n and apply to  
future sessions

--Close Athena and reopen
--Open a project
--Mark two data sets.
--Change the importance of one of them.
--Under the merge menu, choose weight by importance.
--Under the merge menu, merge marked data in chi(k)

The result for me is that the merged file ignores the importance I've  
assigned. I've also tried it in mu(E), with the same result.


It seems that perhaps the n value in the preferences overrides the  
weight by importance option in the menu? If so, that's not the way I  
expect preferences and menu options to interact.


Trying it with applying the n only to the current session also has  
an interesting behavior, although not necessarily the wrong one: it  
seems to just change the radio button in the menu. Also, if I change  
the radio button in the menu directly, the option under Preferences  
changes to match. For the current session, I can understand the  
argument that this is a reasonable behavior. But it is likely to cause  
confusion if a user changes it in the menu and then tries to use the  
preferences to check what the future sessions value is set to--if they  
haven't previously changed the preferences directly during the  
session, they might naturally assume that the value there is the value  
for future sessions, but in reality it just represents the most recent  
menu choice they made, and could be different in a future session.


My suggested fix to both issues: the preferences should control what  
value the radio button takes on when Athena is first opened, and  
changes to the preferences should cause an immediate change to the  
status of the radio button. Subsequent changes to the radio button  
should not change the value under the preferences. And the behavior of  
the merge function should always reflect the current value of the  
radio button.


--Scott Calvin
Sarah Lawrence College___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Zajac, Dariusz A.]

Hi All,
I am a little bit surprised how my post had made a nice discussion ;)

I didn't want to discuss about reference spectra and their usefulness.
I only wanted to point that when you merge data with marked reference
groups you get inversed merged groups - in merge group reference and
in Ref merge your real data. Let users decide if it is useful or not.
For me it is! Especially when I work with many repeats, like e.g. in
QEXAFS, when the signal from sample and from reference in single scan is
to noisy.
cheers
darek 

-Original Message-
From: ifeffit-boun...@millenia.cars.aps.anl.gov 
[mailto:ifeffit-boun...@millenia.cars.aps.anl.gov] On Behalf 
Of Scott Calvin
Sent: Friday, November 20, 2009 12:48 AM
To: XAFS Analysis using Ifeffit
Subject: Re: [Ifeffit] Bug in Athena?




On Nov 19, 2009, at 2:59 PM, Matt Newville wrote:

 For this case, wouldn't it be better to measure the reference 
 separately to determine the chemical shift, and not rely on the 
 reference channel for this purpose?

 How often is the reference channel both noisy AND improved 
by merging? 
 That would imply a transmission measurement that was poor due to low 
 flux.  But if this is because the sample is thick as you 
suggest, the 
 x-rays hitting the reference could be dominated by 
harmonics, and the 
 reference data may just be bad, not noisy due to counting statistics.


It's a good point. But pick your poison. When I am trying to be  
careful about chemical shift, I don't trust that the mono won't just  
happen to skip a step between measuring the standard separately and  
measuring the sample. So I do both. I measure a standard in 
the sample  
channel, with a reference in the reference channel. I then leave the  
reference in the reference channel, and put my sample in. If the  
sample is a reasonable thickness for transmission, but a bit on the  
high side (say 2.3 absorption lengths), the photon count is down  
pretty far by the time it gets to the reference. The reference 
is also  
often the worst detector and amplifier that a line has, as the good  
stuff is used for I0, It, and If. So the reference channel may well  
have a considerable amount of random noise which can be improved by  
merging.

If that's the case, and if my sample appears to be suffering no beam  
damage (scans when aligned, lie on top of each other), then I align  
used the sample data. I then merge the sample data and the reference  
data. By comparing the sample to the reference and the previous scans  
where I measured the standard to the reference, I can see if there's  
been any energy shift between scans. As far as harmonics, this  
procedure should detect them. If the merged reference looks different  
from sample to sample (including the case where a standard was 
also in  
the sample channel), that suggests that there are issues with  
harmonics. If those issues move the first peak of the first  
derivative, I know they're going to affect my determination of  
chemical shift.  Also, if I get a nonzero chemical shift from this  
procedure for the standard, I know there's an issue. If not, they're  
not a problem.

The net result is that I have good confidence that I'm getting  
accurate chemical shifts, as loss of energy calibration, harmonics,  
and noise should all become evident by this procedure.

I'm not recommending this procedure over others; it's just what I do  
in some cases. But it doesn't seem like an unreasonable 
procedure to me.

--Scott Calvin
Sarah Lawrence College

___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov 
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

[Ifeffit] Bug in Athena?

[Zajac, Dariusz A.]

Dear Bruce, Dear All,
maybe it is a naïve question but I want to ask and to point this problem...

Windows XP. Athena 0.8.059
Sc.Linux. Athena 0.8.060

I have a set of data with refernces  (one sample, many scans). I have marked 
sample's groups and do merge marked data in mu(E) then I get merged data 
together with reference (2 groups: merge - sample, and Ref merge - reference). 
But...
...if I have marked reference sample's groups and do merge then I get 2 
groups: merge - which is merged data of reference, and Ref merge - which is 
marged data of sample. Oposite to that I did in first example!

Is any hidden idea, I can not see, why it should be that way? If you don't know 
about that, can confuse and surprise...
cheers
darek
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Carlo Segre]

symmetry? ;)

Carlo

On Thu, 19 Nov 2009, Zajac, Dariusz A. wrote:


Dear Bruce, Dear All,
maybe it is a naïve question but I want to ask and to point this problem...

Windows XP. Athena 0.8.059
Sc.Linux. Athena 0.8.060

I have a set of data with refernces  (one sample, many scans). I have marked sample's 
groups and do merge marked data in mu(E) then I get merged data together with 
reference (2 groups: merge - sample, and Ref merge - reference).
But...
...if I have marked reference sample's groups and do merge then I get 2 
groups: merge - which is merged data of reference, and Ref merge - which is marged data 
of sample. Oposite to that I did in first example!

Is any hidden idea, I can not see, why it should be that way? If you don't know 
about that, can confuse and surprise...
cheers
darek
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit



--
Carlo U. Segre -- Professor of Physics
Associate Dean for Graduate Admissions, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://www.iit.edu/~segre   se...@debian.org___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Zajac, Dariusz A.]

should we break symmetry? ;)
darek

-Original Message-
From: ifeffit-boun...@millenia.cars.aps.anl.gov 
[mailto:ifeffit-boun...@millenia.cars.aps.anl.gov] On Behalf 
Of Carlo Segre
Sent: Thursday, November 19, 2009 3:35 PM
To: XAFS Analysis using Ifeffit
Subject: Re: [Ifeffit] Bug in Athena?



symmetry? ;)

Carlo

On Thu, 19 Nov 2009, Zajac, Dariusz A. wrote:

 Dear Bruce, Dear All,
 maybe it is a naïve question but I want to ask and to point this 
 problem...

 Windows XP. Athena 0.8.059
 Sc.Linux. Athena 0.8.060

 I have a set of data with refernces  (one sample, many 
scans). I have 
 marked sample's groups and do merge marked data in mu(E) 
then I get 
 merged data together with reference (2 groups: merge - 
sample, and Ref 
 merge - reference). But... ...if I have marked reference sample's 
 groups and do merge then I get 2 groups: merge - which is merged 
 data of reference, and Ref merge - which is marged data of sample. 
 Oposite to that I did in first example!

 Is any hidden idea, I can not see, why it should be that way? If you 
 don't know about that, can confuse and surprise... cheers darek
 ___
 Ifeffit mailing list
 Ifeffit@millenia.cars.aps.anl.gov
 http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit


-- 
Carlo U. Segre -- Professor of Physics
Associate Dean for Graduate Admissions, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://www.iit.edu/~segre   se...@debian.org

___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Matt Newville]

Is there ever a case where a merged reference channel is useful?

I thought the only possible use for a reference channel was for
comparing individual scans.  That is, prior to merging.

--Matt

On Thu, Nov 19, 2009 at 6:45 AM, Zajac, Dariusz A.
dariusz.za...@desy.de wrote:
 Dear Bruce, Dear All,
 maybe it is a naïve question but I want to ask and to point this problem...

 Windows XP. Athena 0.8.059
 Sc.Linux. Athena 0.8.060

 I have a set of data with refernces  (one sample, many scans). I have marked 
 sample's groups and do merge marked data in mu(E) then I get merged data 
 together with reference (2 groups: merge - sample, and Ref merge - reference).
 But...
 ...if I have marked reference sample's groups and do merge then I get 2 
 groups: merge - which is merged data of reference, and Ref merge - which is 
 marged data of sample. Oposite to that I did in first example!

 Is any hidden idea, I can not see, why it should be that way? If you don't 
 know about that, can confuse and surprise...
 cheers
 darek
 ___
 Ifeffit mailing list
 Ifeffit@millenia.cars.aps.anl.gov
 http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit


___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Carlo Segre]

Hi Matt:

I agree.  It is useful to have the reference channel from the first of the 
merged data pulled over as reference for the merged data but this 
actuallly only makes sense if the user first aligned using the reference.


carlo

On Thu, 19 Nov 2009, Matt Newville wrote:


Is there ever a case where a merged reference channel is useful?

I thought the only possible use for a reference channel was for
comparing individual scans.  That is, prior to merging.

--Matt

On Thu, Nov 19, 2009 at 6:45 AM, Zajac, Dariusz A.
dariusz.za...@desy.de wrote:

Dear Bruce, Dear All,
maybe it is a naïve question but I want to ask and to point this problem...

Windows XP. Athena 0.8.059
Sc.Linux. Athena 0.8.060

I have a set of data with refernces  (one sample, many scans). I have marked sample's 
groups and do merge marked data in mu(E) then I get merged data together with 
reference (2 groups: merge - sample, and Ref merge - reference).
But...
...if I have marked reference sample's groups and do merge then I get 2 
groups: merge - which is merged data of reference, and Ref merge - which is marged data 
of sample. Oposite to that I did in first example!

Is any hidden idea, I can not see, why it should be that way? If you don't know 
about that, can confuse and surprise...
cheers
darek
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit



___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit



--
Carlo U. Segre -- Professor of Physics
Associate Dean for Graduate Admissions, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://www.iit.edu/~segre   se...@debian.org___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Scott Calvin]

Hi Matt,

I'm the one who requested the merged reference channel.

If the data is ideal, of course only one reference scan is needed. But  
there are two common ways it can be nonideal that are relevant:


1) The monochromator does not hold calibration; i.e. there is an  
energy shift between scans


2) The reference channel is very noisy, perhaps because of an  
inherently thick sample


If  1) is a significant problem and 2) is not, then it makes sense to  
align the scans using the reference, at which point any reference scan  
will do for determination of the chemical shift of the merged data  
from the sample.


If 2) is a significant problem and 1) is not, then it makes sense to  
merge the references along with the sample data, because that will  
make it easier to determine the chemical shift.


If both problems are significant, then you've got a headache.

--Scott Calvin
Sarah Lawrence College


On Nov 19, 2009, at 10:26 AM, Carlo Segre wrote:


Hi Matt:

I agree.  It is useful to have the reference channel from the first  
of the merged data pulled over as reference for the merged data but  
this actuallly only makes sense if the user first aligned using the  
reference.


carlo

On Thu, 19 Nov 2009, Matt Newville wrote:


Is there ever a case where a merged reference channel is useful?

I thought the only possible use for a reference channel was for
comparing individual scans.  That is, prior to merging.

--Matt

On Thu, Nov 19, 2009 at 6:45 AM, Zajac, Dariusz A.
dariusz.za...@desy.de wrote:

Dear Bruce, Dear All,
maybe it is a naïve question but I want to ask and to point this  
problem...


Windows XP. Athena 0.8.059
Sc.Linux. Athena 0.8.060

I have a set of data with refernces  (one sample, many scans). I  
have marked sample's groups and do merge marked data in mu(E)  
then I get merged data together with reference (2 groups: merge -  
sample, and Ref merge - reference).

But...
...if I have marked reference sample's groups and do merge then  
I get 2 groups: merge - which is merged data of reference, and Ref  
merge - which is marged data of sample. Oposite to that I did in  
first example!


Is any hidden idea, I can not see, why it should be that way? If  
you don't know about that, can confuse and surprise...

cheers
darek
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit



___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit



--
Carlo U. Segre -- Professor of Physics
Associate Dean for Graduate Admissions, Graduate College
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://www.iit.edu/~segre   
se...@debian.org___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit


___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Bruce Ravel]

There are a few questions all mixed together here.

Why does Athena make a merge of references?  As Matt points out, that is 
an odd thing to do.  I decided I wanted some kind of reference channel 
tied to the merged spectrum so that I could take merged data from 
different project files and figure out how to align them in a consistent 
manner.  The easiest way to do this was to tie something to the merged 
spectrum as its reference channel.  I decided to make a merge of the 
reference spectra to serve this purpose.  That was just a decision -- I 
could just as well have made a copy of the reference of the first 
spectrum in the merge list.

So what explains the behavior Darek is asking about?  Well, Athena 
doesn't actually make a serious distinction between data and its 
reference.  They are both treated normal dtaa groups internally.  The 
sense in which the reference is somehow special is that you, the user, 
tend not to look at it after you have done data alignment.

So, when you make a merge, Athena sums up all the marked groups.  Then, 
if ach one has a reference tied to it, it sums up the references and 
then ties together these two merged spectra.

However, the reference tying runs both ways.  If you change the energy 
shift for one, the other's energy shift changes the same way.  In that 
sense, there is *no* difference between data and a reference.

So, if you make a merge of data, ther references get merged into a 
merged reference.  If you make a merge of references, the data get 
merged as well.  The data groups that are maked get called merge.  The 
merge of the tied groups gets called   Ref merge.  If you do the merge 
of the reference channels, these two merged groups get labeled 
backwards.

I think that explains everything

B



On Thursday 19 November 2009 07:45:14 am Zajac, Dariusz A. wrote:
 Dear Bruce, Dear All,
 maybe it is a naïve question but I want to ask and to point this 
problem...

 Windows XP. Athena 0.8.059
 Sc.Linux. Athena 0.8.060

 I have a set of data with refernces  (one sample, many scans). I have
 marked sample's groups and do merge marked data in mu(E) then I get
 merged data together with reference (2 groups: merge - sample, and Ref
 merge - reference). But...
 ...if I have marked reference sample's groups and do merge then I 
get 2
 groups: merge - which is merged data of reference, and Ref merge - 
which is
 marged data of sample. Oposite to that I did in first example!

 Is any hidden idea, I can not see, why it should be that way? If you 
don't
 know about that, can confuse and surprise... cheers
 darek
 ___l
 Ifeffit mailing list
 Ifeffit@millenia.cars.aps.anl.gov
 http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit


-- 
 Bruce Ravel  --- bra...@bnl.gov

 National Institute of Standards and Technology
 Synchrotron Measurements Group, Beamlines X23A2, X24A, U7A

 Building 535A, Room M7
 Brookhaven National Laboratory
 Upton NY, 11973, USA

 My homepage:http://xafs.org/BruceRavel
 EXAFS software: http://cars9.uchicago.edu/~ravel/software/exafs/

___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Scott Calvin]

Hi Bruce,

On Nov 19, 2009, at 11:48 AM, Bruce Ravel wrote:

Why does Athena make a merge of references?  As Matt points out,  
that is

an odd thing to do.



I may be confused as to what we're talking about. Why is this an odd  
thing to do? It seems perfectly normal to me to want the reference  
scans merged as well as the sample scans, in order to get a clean  
measure of chemical shift.


--Scott Calvin
Sarah Lawrence College

___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Bruce Ravel]

On Thursday 19 November 2009 01:48:49 pm Scott Calvin wrote:
  Why does Athena make a merge of references?  As Matt points out,  
  that is
  an odd thing to do.

 I may be confused as to what we're talking about. Why is this an odd  
 thing to do? It seems perfectly normal to me to want the reference  
 scans merged as well as the sample scans, in order to get a clean  
 measure of chemical shift.

Ummm... ok could be seen as an odd thing to do...

B



-- 
 Bruce Ravel  --- bra...@bnl.gov

 National Institute of Standards and Technology
 Synchrotron Measurements Group, Beamlines X23A2, X24A, U7A

 Building 535A, Room M7
 Brookhaven National Laboratory
 Upton NY, 11973, USA

 My homepage:http://xafs.org/BruceRavel
 EXAFS software: http://cars9.uchicago.edu/~ravel/software/exafs/

___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Matt Newville]

Hi Scott


On Thu, Nov 19, 2009 at 9:50 AM, Scott Calvin scal...@slc.edu wrote:
 Hi Matt,

 I'm the one who requested the merged reference channel.

 If the data is ideal, of course only one reference scan is needed. But there
 are two common ways it can be nonideal that are relevant:

 1) The monochromator does not hold calibration; i.e. there is an energy
 shift between scans

 2) The reference channel is very noisy, perhaps because of an inherently
 thick sample

 If  1) is a significant problem and 2) is not, then it makes sense to align
 the scans using the reference, at which point any reference scan will do for
 determination of the chemical shift of the merged data from the sample.

 If 2) is a significant problem and 1) is not, then it makes sense to merge
 the references along with the sample data, because that will make it easier
 to determine the chemical shift.

For this case, wouldn't it be better to measure the reference
separately to determine the chemical shift, and not rely on the
reference channel for this purpose?

How often is the reference channel both noisy AND improved by merging?
 That would imply a transmission measurement
that was poor due to low flux.  But if this is because the sample is
thick as you suggest, the x-rays hitting the reference could be
dominated by harmonics, and the reference data may just be bad, not
noisy due to counting statistics.

--Matt

PS: I think that means I agree with Anatoly!
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Frenkel, Anatoly]

Yay!
 
Anatoly

 


From: ifeffit-boun...@millenia.cars.aps.anl.gov on behalf of Matt Newville
Sent: Thu 11/19/2009 2:59 PM
To: XAFS Analysis using Ifeffit
Subject: Re: [Ifeffit] Bug in Athena?



Hi Scott


On Thu, Nov 19, 2009 at 9:50 AM, Scott Calvin scal...@slc.edu wrote:
 Hi Matt,

 I'm the one who requested the merged reference channel.

 If the data is ideal, of course only one reference scan is needed. But there
 are two common ways it can be nonideal that are relevant:

 1) The monochromator does not hold calibration; i.e. there is an energy
 shift between scans

 2) The reference channel is very noisy, perhaps because of an inherently
 thick sample

 If  1) is a significant problem and 2) is not, then it makes sense to align
 the scans using the reference, at which point any reference scan will do for
 determination of the chemical shift of the merged data from the sample.

 If 2) is a significant problem and 1) is not, then it makes sense to merge
 the references along with the sample data, because that will make it easier
 to determine the chemical shift.

For this case, wouldn't it be better to measure the reference
separately to determine the chemical shift, and not rely on the
reference channel for this purpose?

How often is the reference channel both noisy AND improved by merging?
 That would imply a transmission measurement
that was poor due to low flux.  But if this is because the sample is
thick as you suggest, the x-rays hitting the reference could be
dominated by harmonics, and the reference data may just be bad, not
noisy due to counting statistics.

--Matt

PS: I think that means I agree with Anatoly!
___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit


winmail.dat___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Webb, Adam]

--Matt

PS: I think that means I agree with Anatoly!

Me too!  :-)

I like the side-effect of merging the reference when the spectra are merged. 
However, it is the spectra that I merge rather than the refs. The refs can be 
cleaner for alignment though for samples with small edges. 


Adam


___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit

Re: [Ifeffit] Bug in Athena?

[Scott Calvin]

On Nov 19, 2009, at 2:59 PM, Matt Newville wrote:


For this case, wouldn't it be better to measure the reference
separately to determine the chemical shift, and not rely on the
reference channel for this purpose?

How often is the reference channel both noisy AND improved by merging?
That would imply a transmission measurement
that was poor due to low flux.  But if this is because the sample is
thick as you suggest, the x-rays hitting the reference could be
dominated by harmonics, and the reference data may just be bad, not
noisy due to counting statistics.



It's a good point. But pick your poison. When I am trying to be  
careful about chemical shift, I don't trust that the mono won't just  
happen to skip a step between measuring the standard separately and  
measuring the sample. So I do both. I measure a standard in the sample  
channel, with a reference in the reference channel. I then leave the  
reference in the reference channel, and put my sample in. If the  
sample is a reasonable thickness for transmission, but a bit on the  
high side (say 2.3 absorption lengths), the photon count is down  
pretty far by the time it gets to the reference. The reference is also  
often the worst detector and amplifier that a line has, as the good  
stuff is used for I0, It, and If. So the reference channel may well  
have a considerable amount of random noise which can be improved by  
merging.


If that's the case, and if my sample appears to be suffering no beam  
damage (scans when aligned, lie on top of each other), then I align  
used the sample data. I then merge the sample data and the reference  
data. By comparing the sample to the reference and the previous scans  
where I measured the standard to the reference, I can see if there's  
been any energy shift between scans. As far as harmonics, this  
procedure should detect them. If the merged reference looks different  
from sample to sample (including the case where a standard was also in  
the sample channel), that suggests that there are issues with  
harmonics. If those issues move the first peak of the first  
derivative, I know they're going to affect my determination of  
chemical shift.  Also, if I get a nonzero chemical shift from this  
procedure for the standard, I know there's an issue. If not, they're  
not a problem.


The net result is that I have good confidence that I'm getting  
accurate chemical shifts, as loss of energy calibration, harmonics,  
and noise should all become evident by this procedure.


I'm not recommending this procedure over others; it's just what I do  
in some cases. But it doesn't seem like an unreasonable procedure to me.


--Scott Calvin
Sarah Lawrence College

___
Ifeffit mailing list
Ifeffit@millenia.cars.aps.anl.gov
http://millenia.cars.aps.anl.gov/mailman/listinfo/ifeffit