Re: [Ifeffit] Nearest neighbor statistics in a random alloy

[Felix E. Feiten]

Dear Qingying and Anatoly,

thank you very much for your quick help!

It is very much appreciated.

With kind regards

Felix


On 23/06/2017 22:57, Anatoly Frenkel wrote:
... and if the random alloy is a nanoparticle, the equations are 
modified (they will be the same as in Qingying's email in the bulk 
alloy limit and if the NPs are sufficiently large).

See here, Eq. (11), for more details:

Chem. Soc. Reviews *41*, 8163-8178 (2012) 



Anatoly
---

On Fri, Jun 23, 2017 at 9:28 AM, Qingying Jia > wrote:


Hi Felix,


Your assumptions are not correct because the model you use is not
a representative unit cluster model. Basically the following three
equations are always correct for foil:

 NPt-Pt+NPt-Co=12

NCo-Co+NCo-Pt=12

NCo-Pt/NPt-Co=9

And the specific values for the coordination number can be
determined if you know the orderness of the structure. As for the
random distribution of Pt and Co in foil,

NPt-Pt/NPt-Co=9

or equivalently,

NCo-Pt/NCo-Co=9,

Then you can get

NPt-Pt=10.8, and NPt-Co=1.2

The results will be different if the structure is ordered.


  Regards,


On Fri, Jun 23, 2017 at 9:02 AM, Felix E. Feiten
> wrote:

Dear all,

I am fitting a Pt9Co1 foil sample.
I assume the sample to be basically fcc platinum with every
10th atom randomly replaced by cobalt.

Here are the assumptions I make:

1. every atom has 12 nearest neighbors

2. every Pt atom has (on average) 10.7 Pt nearest neighbors
and 1.3 Co nearest neighbors

3. every Co atom has (on average) 11.7 Pt nearest neighbors
and 0.3 Co nearest neighbors

I have been told that assumptions 2 and 3 are not precise.
Here is what I'm confused about:

In order to determine the number of Pt or Co nearest neighbors
I looked at an ensemble of 13 atoms:
1 absorber and 12 scatterers/nearest neighbors.
I assume that the Pt/Co ratio in this ensemble is 9/1 and
therefor, statistically, 1.3 out of those 13 atoms should be
Co. That means that if Co is the central atom only 0.3 Co
atoms are remaining for the 12 nearest neighbors. On the other
hand, if Pt is the central atom, (all) 1.3 Co atoms are
remaining for the 12 nearest neighbors.

I have been told that the ratio of Pt/Co should be 9/1 in the
12 nearest neighbors, not in the 12 atoms including the
central atom (quote: "because we have a bulk sample").

But I do not understand why.

Can someone please explain the correct answer to me?

With kind regards,

Felix


___
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


___
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] Nearest neighbor statistics in a random alloy

[Anatoly Frenkel]

... and if the random alloy is a nanoparticle, the equations are modified
(they will be the same as in Qingying's email in the bulk alloy limit and
if the NPs are sufficiently large).
See here, Eq. (11), for more details:

Chem. Soc. Reviews *41*, 8163-8178 (2012)


Anatoly
---

On Fri, Jun 23, 2017 at 9:28 AM, Qingying Jia  wrote:

> Hi Felix,
>
>
> Your assumptions are not correct because the model you use is not a
> representative unit cluster model. Basically the following three equations
> are always correct for foil:
>
>  NPt-Pt+NPt-Co=12
>
> NCo-Co+NCo-Pt=12
>
> NCo-Pt/NPt-Co=9
>
> And the specific values for the coordination number can be determined if
> you know the orderness of the structure. As for the random distribution of
> Pt and Co in foil,
>
> NPt-Pt/NPt-Co=9
>
> or equivalently,
>
> NCo-Pt/NCo-Co=9,
>
> Then you can get
>
> NPt-Pt=10.8, and NPt-Co=1.2
>
> The results will be different if the structure is ordered.
>
>
>   Regards,
>
> On Fri, Jun 23, 2017 at 9:02 AM, Felix E. Feiten  > wrote:
>
>> Dear all,
>>
>> I am fitting a Pt9Co1 foil sample.
>> I assume the sample to be basically fcc platinum with every 10th atom
>> randomly replaced by cobalt.
>>
>> Here are the assumptions I make:
>>
>> 1. every atom has 12 nearest neighbors
>>
>> 2. every Pt atom has (on average) 10.7 Pt nearest neighbors and 1.3 Co
>> nearest neighbors
>>
>> 3. every Co atom has (on average) 11.7 Pt nearest neighbors and 0.3 Co
>> nearest neighbors
>>
>> I have been told that assumptions 2 and 3 are not precise. Here is what
>> I'm confused about:
>>
>> In order to determine the number of Pt or Co nearest neighbors I looked
>> at an ensemble of 13 atoms:
>> 1 absorber and 12 scatterers/nearest neighbors.
>> I assume that the Pt/Co ratio in this ensemble is 9/1 and therefor,
>> statistically, 1.3 out of those 13 atoms should be Co. That means that if
>> Co is the central atom only 0.3 Co atoms are remaining for the 12 nearest
>> neighbors. On the other hand, if Pt is the central atom, (all) 1.3 Co atoms
>> are remaining for the 12 nearest neighbors.
>>
>> I have been told that the ratio of Pt/Co should be 9/1 in the 12 nearest
>> neighbors, not in the 12 atoms including the central atom (quote: "because
>> we have a bulk sample").
>>
>> But I do not understand why.
>>
>> Can someone please explain the correct answer to me?
>>
>> With kind regards,
>>
>> Felix
>>
>>
>> ___
>> 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] Nearest neighbor statistics in a random alloy

[Qingying Jia]

Hi Felix,


Your assumptions are not correct because the model you use is not a
representative unit cluster model. Basically the following three equations
are always correct for foil:

 NPt-Pt+NPt-Co=12

NCo-Co+NCo-Pt=12

NCo-Pt/NPt-Co=9

And the specific values for the coordination number can be determined if
you know the orderness of the structure. As for the random distribution of
Pt and Co in foil,

NPt-Pt/NPt-Co=9

or equivalently,

NCo-Pt/NCo-Co=9,

Then you can get

NPt-Pt=10.8, and NPt-Co=1.2

The results will be different if the structure is ordered.


  Regards,

On Fri, Jun 23, 2017 at 9:02 AM, Felix E. Feiten 
wrote:

> Dear all,
>
> I am fitting a Pt9Co1 foil sample.
> I assume the sample to be basically fcc platinum with every 10th atom
> randomly replaced by cobalt.
>
> Here are the assumptions I make:
>
> 1. every atom has 12 nearest neighbors
>
> 2. every Pt atom has (on average) 10.7 Pt nearest neighbors and 1.3 Co
> nearest neighbors
>
> 3. every Co atom has (on average) 11.7 Pt nearest neighbors and 0.3 Co
> nearest neighbors
>
> I have been told that assumptions 2 and 3 are not precise. Here is what
> I'm confused about:
>
> In order to determine the number of Pt or Co nearest neighbors I looked at
> an ensemble of 13 atoms:
> 1 absorber and 12 scatterers/nearest neighbors.
> I assume that the Pt/Co ratio in this ensemble is 9/1 and therefor,
> statistically, 1.3 out of those 13 atoms should be Co. That means that if
> Co is the central atom only 0.3 Co atoms are remaining for the 12 nearest
> neighbors. On the other hand, if Pt is the central atom, (all) 1.3 Co atoms
> are remaining for the 12 nearest neighbors.
>
> I have been told that the ratio of Pt/Co should be 9/1 in the 12 nearest
> neighbors, not in the 12 atoms including the central atom (quote: "because
> we have a bulk sample").
>
> But I do not understand why.
>
> Can someone please explain the correct answer to me?
>
> With kind regards,
>
> Felix
>
>
> ___
> 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] Nearest neighbor statistics in a random alloy

[Felix E. Feiten]

Dear all,

I am fitting a Pt9Co1 foil sample.
I assume the sample to be basically fcc platinum with every 10th atom 
randomly replaced by cobalt.


Here are the assumptions I make:

1. every atom has 12 nearest neighbors

2. every Pt atom has (on average) 10.7 Pt nearest neighbors and 1.3 Co 
nearest neighbors


3. every Co atom has (on average) 11.7 Pt nearest neighbors and 0.3 Co 
nearest neighbors


I have been told that assumptions 2 and 3 are not precise. Here is what 
I'm confused about:


In order to determine the number of Pt or Co nearest neighbors I looked 
at an ensemble of 13 atoms:

1 absorber and 12 scatterers/nearest neighbors.
I assume that the Pt/Co ratio in this ensemble is 9/1 and therefor, 
statistically, 1.3 out of those 13 atoms should be Co. That means that 
if Co is the central atom only 0.3 Co atoms are remaining for the 12 
nearest neighbors. On the other hand, if Pt is the central atom, (all) 
1.3 Co atoms are remaining for the 12 nearest neighbors.


I have been told that the ratio of Pt/Co should be 9/1 in the 12 nearest 
neighbors, not in the 12 atoms including the central atom (quote: 
"because we have a bulk sample").


But I do not understand why.

Can someone please explain the correct answer to me?

With kind regards,

Felix


___
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] Automatically doing many fits / Scripting - Solved

[Felix E. Feiten]

Dear all,

as I got no reply, I did embark on this little automation quest by 
myself, as announced.


I used AutoHotkey to write a script that operates on Artemis by sending 
keystrokes and mousecommands. I will attach the the code to the end of 
this mail so anyone interested can take a peek. I basically wrote it for 
myself so some parts might not be clear or smartly designed but it does 
it's job of automatically starting fit after fit while varying the 
start/guess/set parameters. It is somewhat commented so anyone with a 
real interest in this should be able to get it to work, otherwise just 
ask me for help.


Subsequently I used MS PowerShell to grab the relevant parameters from 
the log-files of the fits.

I won't attach that script, but if anyone is interested in it: just ask.

Attention, wall-of-text/code below!

Felix


Contents of "artemis_fitting.ahk":

; This is what comments look like

; 3D Parameter Scan

; Artemis Main Window:

; Using IDs for buttons and text-fields and windows would be much better 
than using mouse-positioning.

; The IDs would make the whole thing independent from the resolution.

; GDS Window:
; Change Parameters
; Window unique ID: 0x30a38
; fields in GDS table don't have unique classes so mouse-positioning 
will have to be used after all
; this means there will be a calibration step before running the fitting 
loop



; Log Window:
; Save Log File

^j::
{
CoordMode, Mouse , Screen

; MouseGetPos, OutputVarX, OutputVarY, OutputVarWin, OutputVarControl
;MouseGetPos, MouseXPosition, MouseYPosition, ArtemisMainWindowUID, 
ArtemisMainWindowClassNN


;MsgBox Mouse Cursor x-position: %MouseXPosition%`n
;   , Mouse Cursor y-position: %MouseYPosition%`n
;   , Window unique ID:%ArtemisMainWindowUID%`n
;   , Window Class:%ArtemisMainWindowClassNN%

; 0. calibration

;MsgBox Calibration. Position the cursor over Artemis main window's 
entry field for Fit-Name and press return.

MsgBox Calibration: Name
MouseGetPos, Edit1XP, Edit1YP, ArtemisMainWindowUID

;MsgBox ArtemisMainWindowUID is %ArtemisMainWindowUID%

;MsgBox Calibration. Position the cursor over Artemis main window's 
fit description entry field.

MsgBox Calibration: Fit description
MouseGetPos, FDXP, FDYP

;MsgBox Calibration. Position the cursor over the Fit Button of 
Artemis' main window.

MsgBox Calibration: Fit
MouseGetPos, FitXP, FitYP

;MsgBox Calibration. Position the cursor over the "Show log" button 
of the main window.

MsgBox Calibration: Show log
MouseGetPos, slogX, slogY

; A - pick the two fields that containt the guess-value for 
FixedParameter1 and FixedParameter2


;MsgBox Calibration. Position the mouse cursor over the input field 
for FixedParameter1 and press Return.

MsgBox Calibration: Parameter1
MouseGetPos, FixPar1MXP, FixPar1MYP

;MsgBox Position the mouse cursor over the input field for 
FixedParameter2 and press Return.

MsgBox Calibration: Parameter2
MouseGetPos, FixPar2MXP, FixPar2MYP, GDSWindowUID

; B - enter the desired minimum, maximum and step-size for each of 
the FixedParamteres


; for now just fixed
; minimum = 0.002,
; maxmimum = 0.012 and
; step width = 0.001
MinPar1=0.002000
MinPar2=0.002000
MaxPar1=0.012000
MaxPar2=0.012000
StepSize=0.00100
CurPar1=%MinPar1%
CurPar2=%MinPar2%

;MsgBox Calibration(finally last step though). Place mouse cursor 
over Log-window's Save button.

MsgBox Calibration: Save (Log-Window)
MouseGetPos, SaveX, SaveY, LogID

;MsgBox Calibration: Plot Window
;MouseGetPos, PX, PY, PID

LV1=1
LV2=1
TFC=0
Loop , 11
{
CurPar2:=MinPar2

LV1:=LV1+1
Loop, 11
{
LV2:=LV2+1
TFC:=TFC+1

; block below is what should be executed in each run of the 
loop, let's build the loop

{
; 1. Go to GDS Window

; WinActivate [, WinTitle, WinText, ExcludeTitle, 
ExcludeText]


WinActivate , ahk_id %GDSWindowUID%
WinWaitActive , ahk_id %GDSWindowUID%

; 2. Set the two fixed parameters as desired !! THIS 
NEEDS TO BE VARIED FROM ITERATION TO ITERATION

; should work (i.e. be varied/changed)

MouseMove, FixPar1MXP, FixPar1MYP, 0
;Sleep 500
MouseClick
;Sleep 500
MouseClick
;MsgBox Just to make sure: CurPar1=%CurPar1%
Sleep 100
SendInput %CurPar1%
Sleep 100
MouseMove, FixPar2MXP, FixPar2MYP, 0
;Sleep 500
MouseClick
;Sleep 500
MouseClick
;MsgBox Just to make sure: CurPar2=%CurPar2%
Sleep 100

Re: [Ifeffit] nonsensical negative values / restrictions

[Felix E. Feiten]

Dear Bruce,

thank you very much for your quick and thorough answer.

I used to do I/V-LEED to do structural characterization of surfaces and 
there it was pretty common to get stuck in local minima. So my fear was 
that this negative R-factor corresponds to a local minimum and that 
there is actually a better minimum with reasonable values.


I have noticed that there is some dependence of the fitting results on 
the start values used. Also, in one of the very useful videos of you 
giving talks about EXAFS you mentioned that the Levenberg-Marquardt 
algorithm can end up in a local minimum. However, I'm starting to get 
the feeling that this is much less of a problem in EXAFS analysis than 
in my previous field. I guess one of the reasons might be that a fit in 
IFEFFIT/Artemis takes seconds whereas a single datapoint (i.e. a fully 
dynamical scattering calculation for one trial structure) in I/V-LEED 
would take ~30 mins.


After having done some systematic variation of parameters with a little 
script I wrote (more on that in the respective thread) I'm starting to 
realize that the hyperspace in EXAFS fitting seems rather shallow (at 
least for my samples).


I don't think that the reason for the physically unreasonable results is 
a systematic error, as I have a number of different samples measured in 
one beamtime and some of them are fine while others have varying issues 
(mostly with too high/low sigma^2 and it's correlation with N).


With kind regards

Felix


On 17/06/2017 00:10, Bruce Ravel wrote:

Felix,

When you fit your EXAFS data using Artemis + Ifeffit or Larch, you are 
using a Levenberg-Marquardt non-llinear, steepest descent algorithm. 
The fit does kn ow anything /at all/ about what you are trying to do. 
It doesn't know what a sensible value for sigma^2 or any other 
parameter is.  All it knows is that you have data and a model that you 
are throwing at the data.


Armed with data and model, the algorithm optimizes the parameters that 
you have flagged as the variables.  It changes those values until it 
makes the sum of the paths look as much like the data as possible.  
It's goal is to make the red line look like the blue line.  That's it. 
That's all it does.  That's how sigma^2 can come out as a negative 
number.


A negative sigma^2 or any other nonsensical parameter doesn't 
represent a failure of Artemis.  It is information that is useful to 
you, the person doing the fit.


A nonsense parameter is trying to tell you about a way that the model 
you have proposed does not represent the data that you have measured. 
And it is a hint about what changes you need to explore in your model 
to more properly represent the data.


An example: suppose you have an unknown oxide phase and you have 
reason to believe it is some sort of highly disordered phase. Just to 
pull an example out of the air, you might think that your sample is 
filled with FeO(OH) when in fact it is filled with FeO. FeO(OH) is 
pretty disordered, whereas FeO is rocksalt.  If you run Feff on 
Feo(OH), you will get a spread of paths at several distances for the 
first shell. When you make the fit with the FeO(OH) model, the 
structural contribution to the disorder is MUCH higher than in the 
actual sample. The fit is likely to use a negative sigma^2 to 
counteract that effect.


That's a simple and contrived "explaining example", but it makes the 
point (I hope).  Artemis didn't fail.  The fit is trying to tell you 
that you assumptions were not realized in the data.


In short, I agree that your results make no sense, but I suggest that 
the problem is that you are making a poor assumption in your fitting 
model.


It also might be the case that there is a problem with the measurement 
of your data that introduces a systematic error that the fit 
compensates for by applying a weird parameter value.


Or maybe you have a sulfide instead of the oxide you were expecting.

Or maybe you ran Feff for the Pt K edge rather than the Pt L3 edge. 
(Oops! I actually do that with embarrassing frequency)


Or something else I haven't thought of

HTH,
B


On 06/16/2017 02:09 AM, Felix E. Feiten wrote:

Dear all,

I have the following problem:

In some fits using Artemis (Demeter 0.9.25) I will get negative 
values for parameters where it makes no sense at all.
For example, when trying to fit two first shell paths, Pt-Pt and 
Pt-O, for a Pt nanoparticle,

sigma^2 for the Pt-O path becomes negative.

Obviously, sigma^2 has to be a positive number.

My questions:

1. Why does the fit algorithm do this?

2. What can I do to avoid this?

I know that there are most likely significant problems with my fit if 
this behaviour occurs.
As far as I know it's possible to impose restrictions in Artemis and 
if anyone could point me
towards a tutorial explaining how to implement restrictions that 
might be a first step in the right direction.
Currently, the chapter "Constraints and restraints" in the Artemis 
documentation is "Coming