You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For counts data, the uncertainty on counts is typically defined by poisson counting statistics, i.e. the standard deviation on `N` counts is `sqrt(N)`.
10
+
11
+
This can be problematic in cases where zero counts have been collected, as the standard deviation will then be zero, which will subsequently lead to "infinite" point weightings in downstream fitting routines for example.
12
+
13
+
A number of possible approaches were considered:
14
+
15
+
| Option | Description |
16
+
| --- | --- |
17
+
| A | Reject data with zero counts, i.e. explicitly throw an exception if any data with zero counts is seen as part of a scan. |
18
+
| B | Use a standard deviation of `NaN` for points with zero counts. |
19
+
| C | Define the standard deviation of `N` counts as `1` if counts are zero, otherwise `sqrt(N)`. This is one of the approaches available in mantid for example. |
20
+
| D | Define the standard deviation of `N` counts as `sqrt(N+0.5)` unconditionally - on the basis that "half a count" is smaller than the smallest possible actual measurement which can be taken. |
21
+
| E | No special handling, calculate std. dev. as `sqrt(N)`. |
22
+
23
+
For clarity, the following table shows the value and associated uncertainty for each option:
These approaches were discussed in a regular project update meeting including
44
+
- TW & FA (Experiment controls)
45
+
- CK (Reflectometry)
46
+
- JL (Muons)
47
+
- RD (SANS)
48
+
49
+
## Decision
50
+
51
+
The consensus was to go with Option D.
52
+
53
+
## Justification
54
+
55
+
- Option A will cause real-life scans to crash in low counts regions.
56
+
- Option B involves `NaN`s, which have many surprising floating-point characteristics and are highly likely to be a source of future bugs.
57
+
- Option D was preferred to option C by scientists present.
58
+
- Option E causes surprising results and/or crashes downstream, for example fitting may consider points with zero uncertainty to have "infinite" weight, therefore effectively disregarding all other data.
# yerr is the uncertanties of each y value, producing error bars
42
43
```
43
44
45
+
By providing a signal name to the `yerr` argument you can pass uncertainties to LivePlot, by not providing anything for this argument means that no errorbars will be drawn. Errorbars are drawn after each point collected, displaying their standard deviation- uncertainty data is collected from Bluesky event documents and errorbars are updated after every new point added.
46
+
44
47
The `plot_callback` object can then be subscribed to the run engine, using either:
45
48
- An explicit callback when calling the run engine: `RE(some_plan(), plot_callback)`
46
49
- Be subscribed in a plan using `@subs_decorator` from bluesky **(recommended)**
**Note:** that the `LiveFit` callback doesn't directly do the plotting, it will return function parameters of the model its trying to fit to; a `LiveFit` object must be passed to `LiveFitPlot` which can then be subscribed to the `RunEngine`. See the [Bluesky Documentation](https://blueskyproject.io/bluesky/main/callbacks.html#livefitplot) for information on the various arguments that can be passed to the `LiveFitPlot` class.
34
35
36
+
Using the `yerr` argument allows you to pass uncertainties via a signal to LiveFit, so that the "weight" of each point influences the fit produced. By not providing a signal name you choose not to use uncertainties/weighting in the fitting calculation. Each weight is computed as `1/(standard deviation at point)` and is taken into account to determine how much a point affects the overall fit of the data. Same as the rest of `LiveFit`, the fit will be updated after every new point collected now taking into account the weights of each point. Uncertainty data is collected from Bluesky event documents after each new point.
37
+
35
38
The `plot_callback` and `fit_plot_callback` objects can then be subscribed to the `RunEngine`, using the same methods as described in [`LivePlot`](../callbacks/plotting.md). See the following example using `@subs_decorator`:
36
39
37
40
```py
@@ -79,7 +82,7 @@ from bluesky.callbacks import LiveFitPlot
79
82
from ibex_bluesky_core.callbacks.fitting.fitting_utils import [FIT]
80
83
81
84
# Pass [FIT].fit() to the first parameter of LiveFit
@@ -89,7 +92,7 @@ The `[FIT].fit()` function will pass the `FitMethod` object straight to the `Liv
89
92
**Note:** that for the fits in the above table that require parameters, you will need to pass value(s) to their `.fit` method. For example Polynomial fitting:
0 commit comments