Inconsistent behavior between scriptable and the GUI

[Kvieta1990]

Here I am reporting the inconsistent behavior between the GSAS-II scriptable and the GUI. In short, when I simulate the powder diffraction pattern with GSAS-II scriptable with a CIF and an instrument parameter file and afterwards I perform the Rietveld refinement with GSAS-II GUI using the simulated data, the same CIF and instrument parameter file, I would assume a nearly perfect refinement without doing anything. However, it seems that is not the case -- the difference between the initial fitting and the simulated data does not seem be explainable by the rounding error of the involved calculations. Here below are details about how to reproduce.

1. Use the run_gsasii.py script included in the package below to simulate a powder diffraction pattern, using the CIF STO_Parent.cif and instrument parameter file powgen_profile_lwf.instprm -- both are included in the package below.

   One needs to replace the file paths on the top part of the script with their own specifics.

2. With the shared script as is, running the script would create the simulated data file STO_Parent_neutron_powder_calc.txt. Next, start GSAS-II GUI and import the data as from Topas xys/qye or 2th Fit2D chi/qchi file. When asked for the instrument parameter file, choose the one included in the package below, namely powgen_profile_lwf.instprm which was used for the data simulation above.

3. Then import the CIF STO_Parent.cif and attach it to the imported histogram above.

4. With all default settings, just start the refinement and initially we would see a big mismatch between the calculated pattern and the observed pattern (the simulated data), which is really not expected since basically we are refining against 'itself'.

5. In the instrument parameter file used, zero and difb parameters are both 0 and by default they are not refined. If we enable both of them to be refined, we would get an expected nearly perfect refinement. Still there are some mismatch, but that is kind of expected since we would always have some rounding errors when performing the calculation back and forth.

   The included GSAS-II project file is with zero and difb parameters refined and we can see the fitting quality is nearly perfect. If we set both to be 0 and disable the refinement for both of them, we will see the obvious mismatch between the calculated and observed patterns.

issue_249_files.zip

[briantoby]

I can see (and vaguely remember Bob talking about) that the time (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 in the data array are for the bin midpoint. Since the TOF values that are read in will be shifted to the bin midpoint, we need to apply a shift to the x values to prepare for that. Once this is done, the points will align.

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 needs to be documented for scripting.
• Some thought is needed on how this should be handled for export from the GUI. Should the exported files have this shift applied automatically?
• Is this done for CW data as well?
  • no

[briantoby]

closing this, since the remaining action item is now #251.

[Kvieta1990]

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]

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.