Dear Rietvelders,
Thanks for your opinions!
I guess keeping an eye on measurement software's rebinning behavior (especially
if it's done without informing user)is still necessary, becasue too much
rebinning might deform the peak profile especially in the overlapping regions.
Plus errors from Rietveld refinement are sometime used to judge the suitability
of the refinement model, etc...
Matthew's suggsetion of testing counting statistics experimentally is quite
good. I am thinking of just check the flat background region which is already
repeat measurements of a count level by the target system.
Therefore, placing the "n-cursor" in Profex (a "+-sqrt(Y)" cursor varing with
mouse Y position) to the data's background is quite handy to visually check if
the data drifted too much from the Possion distribution.
In my software, I tested the noise levels of several flat background regions of
my data like below, they are always smaller than sqrt(Y). Looks like Alan is
correct: the data was saved for user(me) with a better look....
xdd C:\***.raw
start_X 66
finish_X 67
prm bkga 0.69281`
prm bkgb 96.32814`
fit_obj = bkga X + bkgb;
xdd_sum num_data = 1;:101
xdd_sum sum_sqr_diff = (Yobs-Ycalc)^2;:7247.6514
prm Standard_Deviation_Obs = Sqrt(sum_sqr_diff/num_data);:8.47106
prm PossionTest = Standard_Deviation_Obs/Sqrt(bkga
(Get(start_X)+Get(finish_X))/2 + bkgb);:0.70988`
Thank you very much for your help!
--
Dr. Xiaodong (Tony) Wang
Research Infrastructure Specialist (XRD)
Central Analytical Research Facility (CARF) | Institute for Future
Environments
Queensland University of Technology
Address: XRD lab, P Block, Gardens Point campus, 2 George St Brisbane QLD 4000
At 2019-09-27 17:54:18, "Reinhard Kleeberg" <kleeb...@mineral.tu-freiberg.de>
wrote:
The problem of falsified counting statistics (deviating from Poisson
distribution) sometimes arises even from (wrong) conversion of 0D detector data
(typically when originally cps have been stored and the counting time got lost
in the conversion), and is quite common when 1D detector data are exported to
3rd party formats and the number of active channels is not considered correctly
in the export routine.
As a tool for a quick coarse check of the correct noise (like Matthew has
suggested below), Nicola Doebelin has integrated a "noise" cursor in his PROFEX
software
https://profex.doebelin.org/
simply showing the +-sqrt(n) bars.
If the noise of a pattern significantly deviates from this interval, something
was going wrong, either in instrumental data collection/pretreatment or during
export or conversion. No big science, but very helpful to identify bad or
manipulated data.
Reinhard
Am 27/09/2019 um 08:15 schrieb Matthew Rowles:
Hi Tony
If you want to have a look at what the uncertainties are doing, then try
scanning over a peak a couple of dozen times (maybe with a few different mA
settings on the tube, maybe with some different step times) to collect a range
of different intensities. The standard deviation of the "raw" counts (not raw
CPS) should approximately the square root of the number of counts. If it is
different, then something squirrelly is going on.
Matthew
On Fri, 27 Sep 2019 at 13:46, iangie <ian...@126.com> wrote:
Dear Rietvelders,
Thanks for your opinions!
The "re-binning" of 1D data was done by my measurement software automatically,
rather than by analysis software.
The CPS is unchanged after its "re-binning". This means, rather than adding
counts of neighboring steps, it is *averaging* my data (sum counts up then
divided by the number of combined bins)!
I have a feeling what my measurement software doing is not correct...
--
Dr. Xiaodong (Tony) Wang
Research Infrastructure Specialist (XRD)
Central Analytical Research Facility (CARF) | Institute for Future
Environments
Queensland University of Technology
在 2019-09-27 10:31:45，alancoe...@bigpond.com 写道：
Hi Tony
>My I ask is this re-bined data from the measurement software considered as
>"raw data" or "treated data"?
I’m not sure what is meant by treated data. Almost all neutron data and
synchrotron data with area detectors are “treated data”.
If the detector has a slit width in the equatorial plane that is 0.03 degrees
2Th then it makes little sense using a step size that is less than 0.03/2
degrees 2Th. If rebinning is done correctly (see rebin_with_dx_of in the
Technical Reference) then rebinning is basically collecting redoing the
experiment with a wider slit.
In the case of your PSD then the resolution of the PSD would be the smallest
slit width. If the data has broad features relative to the slit width then
rebinning (or using a bigger slit width) should not change the results. You
could simulate all this using TOPAS to see the difference. Correct rebinning
should not affect parameter errors.
This is a question that is not simple to answer and if there’s concern then:
Simulating data with the small step size and performing a fit
And then rebinning with various slit widths and then fitting
And then comparing parameters errors and parameter values for all the
refinements should shine light on the area.
I don’t know where but I feeling is that there should be papers on this.
Cheers
Alan
From:rietveld_l-requ...@ill.fr <rietveld_l-requ...@ill.fr> On Behalf Of iangie
Sent: Thursday, September 26, 2019 1:40 PM
To:rietveld_l@ill.fr
Subject: Software re-binned PD data
Dear Rietvelder,
I hope you are doing well.
It is generally acknolwdged that Rietveld refinement should be performed on raw
data, without any data processing.
One of our diffractometer/PSD scans data at its minimal step size (users can
see that the step size during scan is much smaller than what was set), and upon
finishing, the measurement software re-bin the counts to the step size what
users set (so the data also looks smoother, after re-bin).
My I ask is this re-bined data from the measurement software considered as "raw
data" or "treated data"? And can we apply Rietveld refinement on this data?
Any comments are welcome. :)
--
Dr. Xiaodong (Tony) Wang
Research Infrastructure Specialist (XRD)
Central Analytical Research Facility (CARF) | Institute for Future
Environments
Queensland University of Technology
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please do NOT attach files to the whole list <alan.he...@neutronoptics.com>
Send commands to <lists...@ill.fr> eg: HELP as the subject with no body text
The Rietveld_L list archive is on http://www.mail-archive.com/rietveld_l@ill.fr/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please do NOT attach files to the whole list <alan.he...@neutronoptics.com>
Send commands to <lists...@ill.fr> eg: HELP as the subject with no body text
The Rietveld_L list archive is on http://www.mail-archive.com/rietveld_l@ill.fr/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
--
TU Bergakademie Freiberg
Dr. R. Kleeberg
Mineralogisches Labor
Brennhausgasse 14
D-09596 Freiberg
Tel. ++49 (0) 3731-39-3244
Fax. ++49 (0) 3731-39-3129
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Please do NOT attach files to the whole list <alan.he...@neutronoptics.com>
Send commands to <lists...@ill.fr> eg: HELP as the subject with no body text
The Rietveld_L list archive is on http://www.mail-archive.com/rietveld_l@ill.fr/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
