Should TOF time values be shifted on GUI export; document TOF values usage in scripting

[briantoby]

If one simulates a pattern and then reads that pattern back in, the x values are shifted w/r to where the peaks are computed. This seems to be due to this: TOF values are reported at the edge of the bin, but in GSAS-II the intensity is computed at the mid-point for the bin, so x-values used internally are for the bin midpoints (at least I think this is correct). See Note #249.

This creates a confusing situation where GSAS-II reads in TOF bin edge values but exports TOF midpoint values. This means that a shift is needed to be applied to read in exported x positions. I’m wondering if histogram exports should be shifted so that imports and exports are consistent?

• We probably should not provide any shift (or perhaps make the shift as an option for G2PwdrData.getdata, what is going on needs to be documented there.

[Kvieta1990]

Hi @briantoby I am pasting the comment from issue #249 to below,

---

Thanks a lot Brian for looking into this and the thoughts! This is really useful and I just grabbed your shared snippet of codes, made some changes (see below), and plugged it into the end of the data simulation script with GSASIIscritable and now when loading the calculated data into GSAS-II GUI and do the refinement (without changing anything), and I can get a nearly perfect match (no need to enable difb, difa or tzero for refinement).

Here is my used piece of codes considering the x-point shift,

import numpy as np
x = gpx.histogram(0).getdata('x')
x = np.log(x)
bin_size = x[-1] - x[-2]
x = np.exp(x - bin_size / 2.)

The reason why I need to do the logarithmic and exponential calculation is for TOF data, I think by default GSAS-II is assuming a logrithmic binning and therefore the binning is only uniform after converting the initial TOF grid to logarithmic scale. Then we can shift the x by half of the bin size (again, on a logarithmic scale) and then we convert back to the original scale by exponentiating. When we do this, as I put above, I found that we don't need to enable any instrument parameters to be refined to get a nearly perfect fitting as presented above.

---

[briantoby]

Originally posted by @briantoby in #249:
If I'm correct, then the difference between your code and mine will be the exact place that is considered the "middle" of the bin, so the change should be pretty small. I should see if I can track down where the shift is applied to the TOF values during the import, or at least compare the original and shifted values inside the code to see what works best.

[Kvieta1990]

If I'm correct, then the difference between your code and mine will be the exact place that is considered the "middle" of the bin, so the change should be pretty small.

I think that is it.

I should see if I can track down where the shift is applied to the TOF values during the import, or at least compare the original and shifted values inside the code to see what works best.

sure. please feel free to let me know if you want me to test out something.

Thank you so much!

[briantoby]

Comment from Bob: "A bin is tagged with a TOF at the front end of the bin, ditto for the next one. The intensity should be ascribed to the point that is midway in time (TOF) these two bin edges. This is independent of how the bin edges were assigned ("log bins", I presume). All the "log binning" does is set out a set bin boundaries that increase with TOF; the counts in each bin should be assigned to points that are 1/2 way between each pair of bin boundaries; no log involved."

Makes sense to me. So this code is a better choice:

x = gpx.histogram(0).getdata('x')
xdiff = np.append(np.diff(x),x[-1]-x[-2]) # make same length as X by duplicating last element
x -= xdiff/2 # adjust for midpoint shift on data read

This is already in place for scripting. Now I need to get it into the PWDR exports.

[briantoby]

This is probably not going to affect too many people (how often does one export a TOF histogram?), but since this change does affect what the program is doing, it warrants a new minor version (5.6.0) and a blog (#253).