Import path does not give reproducible results

[SiebevanderVeer]

Hi Matt and co.,

I've come across something that I don't understand. I noticed that the same paths (Mg_O201) from two different feff calculations gave different results with the same parameters, so I checked if this is also the case if the same path is imported from the same feff calculation and it seems so. Furthermore, it seems not to be random, but follow a pattern.

The paths were added in order as they are listed in the legend and every time I do this the shapes of the curves are exactly the same. The second is slightly different from the first and from the third on there is a significant difference. Note that this is without fitting, but simply giving each path the same parameters and using the values listed in the screenshot below.

The issue is that when I perform a fit using the different versions of the path, I get (slightly) different results. The fit for each version of this path is reproducible.

I've separately mailed the data and cif file to Matt, as I can't add a data file here.

Is this an expected result?

Siebe

PS Due to partial occupancy of the M site (Mg, Al) there is another thing to watch out for. Each time feff/Larix computes the atomic positions it seems to randomly select the Mg/Al distribution of the 6 Mg_M paths. Given the elemental composition, this should be 3/3.

[newville]

@SiebevanderVeer it looks like maybe those two paths have distances that are almost identical bur not quite exact to 4 decimal places. Does that seem right to you?

I recommend picking one of these paths. From the Session File you sent, it looks like maybe you imported 5 slightly different paths and set them all to have a coordination number of 6 -- adding to 30 total neighbors, if I am reading that correctly.

[SiebevanderVeer]

@newville, sorry for the confusion. The issue occurs when I import the same path several times. The final comment on the partial occupancy I've added because I am not sure that this first Mg-O path will remain identical in each of the different atomic configurations, where the 6 nearest metal neighbours to Mg are a combination of Mg and Al.

For a bit more background on how I came across this. I did data fitting using a certain version of a cif file of a layered structure, but I came to the conclusion that the interlayer atoms and their paths do not significantly contribute to the EXAFS so I made another version of the cif file, where the interlayer atoms were removed. This I wanted to do to get a clearer overview of which paths within the octahedral sheets were available and explore which of these contribute to the EXAFS. Then when I did a first shell fit of the new cif file, the fit was significantly different from the one obtained with the previous cif file. I wondered how that could be, so I imported the Mg-O path of both files and they were different while having the same variables. After some more exploration I came to the conclusion that when I import a path multiple times, it is different. As mentioned in the original post, this behaviour seems to be reproducible.

Hope this clarifies the issue a bit.

[SiebevanderVeer]

@newville, sorry to bother you on this, but do you have any further feedback on this issue, based on the clarification above?

[newville]

@SiebevanderVeer I guess I don't. I'm not 100% sure I know what you are seeing that is a problem. Having a slightly distorted structure will give paths that are very similar but not identical. Is that what you are seeing?

Having partial occupancy will cause randomly selected scattering atoms. Is that what you are seeing?

It definitely helps if you can provide a reproducible script that demonstrates what the problem is.

[SiebevanderVeer]

Hi Matt, ok. I'll think a bit on how better to explain the issue. I'll get back on it early next week.

[SiebevanderVeer]

@newville, let's try this again. When you are talking about a script, do you mean the sequence of actions that I take?

I am using the cif file I sent to you for the feff calculation with Mg as the absorbing atom. When I import the first shell Mg-O path multiple times, I repeatedly see the same issue, as shown in the image in the original post. I am not importing degenerate, or slightly different paths, but the same one multiple times and it gives different results.

[newville]

@SiebevanderVeer By script I mean either the Larix Session File or the Command Script from the Larch buffer. This will show the exact sequence you took.

You say that you import "the first shell Mg-O path" multiple times. What does that mean to you? Like, if you are reading the same FeffNNNN.dat file, then the results have to be identical. For a single Feff run, there might be several fefffNNN.dat files that would represent a "first shell". The fefffNNNN.dat files represent "paths" which are one set of atoms with one geometry and one set of atomic potentials. But a "shell" is sort of a vague concept -- for your case, there could be 6 different paths in the first shell. Those would not be identical, but they are all "first shell".

If you are running Feff multiple times on the same input file, you will get identical results. But if you re-make the input file from the CIF file -- especially in the case of partial occupancy -- then the Feff file might have different arrangements of atoms, and indeed different atom types at each partially occupied position. That would give different results - probably only slightly different. But, the path files would NOT be "the same". They might be named the same, but Feff names files "feff0001.dat", "feff0002.dat", ...., so not all "feff0001.dat" files are the same.

[SiebevanderVeer]

Hi Matt, thanks for the further explanations; the point on the differences between the re-makes of the input file is clear. With regards to further information, I will send you the session file, the history saved as a script, as well as the feff file with which I observe this behaviour.

I see now that my phrasing is unclear, apologies. What I did is I imported the same FeffNNNN.dat (feff0001.dat) file from the same feff calculation multiple times, see Mg_O201 to Mg_O201d in the image in the original post. If I repeat this process, by removing the paths and loading them again, I see the same behaviour.

[newville]

@SiebevanderVeer When I look at your project files, some of those "Mg-O at 2.01 Ang" paths are, in fact, identical, while others are not precisely identical. I think "Mg_O201_c" and "Mg_O201_d" are identical. The path labeled "Mg_O201" is clearly from a different calculation. The path labeled "Mg_O201_a" also appears to be from a different calculation (several of the parameters in the Feff.dat file are just different), though it is a little less clear how that came to be.

Again (and apologies if this is already clear to you) if you run feff with a different input file (or a different set of atomic positions) then the results may be slightly different.

[SiebevanderVeer]

@newville. Thanks for the response.

I checked it again and now it seems to behave as expected, i.e. the same path from a single calculation are identical each time they are imported and the same path from a different calculation is slightly different. I don't fully understand the situation, because I thought I also did this check when I first broached the (non-)issue. Importing from a feff calculation indeed seems to be working as intended, so I guess we can consider the issue resolved.

Thanks for your patience and help.

[maurov]

@SiebevanderVeer I think you have understood what was your initial error, then this issue is not relevant anymore.