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
Copy file name to clipboardExpand all lines: doc/architectural_decisions/003-run-in-process.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ Current
8
8
9
9
`bluesky` code can be run in several ways:
10
10
- By the user at an interactive shell, directly calling the run engine in-process.
11
-
- Underneath {py:obj}`run_plan()<ibex_bluesky_core.run_engine.run_plan>` if a plan/plan stub is to be run programmatically, which in turn calls the run engine.
11
+
- Underneath {py:obj}`~ibex_bluesky_core.run_engine.run_plan` if a plan/plan stub is to be run programmatically, which in turn calls the run engine.
12
12
- By a central worker process, to which the user would "submit" plans to run.
13
13
- See DLS's `blueapi` for an example of a REST API for submitting plans to the run engine.
Copy file name to clipboardExpand all lines: doc/architectural_decisions/005-variance-addition.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,8 +6,8 @@ Current
6
6
7
7
## Context
8
8
9
-
For counts data, the uncertainty on counts is typically defined by poisson counting statistics, i.e. the standard
10
-
deviation on `N` counts is `sqrt(N)`.
9
+
For counts data, the uncertainty on counts is typically defined by Poisson counting statistics, i.e. the standard
10
+
deviation on {math}`N` counts is {math}`\sqrt{N}`.
11
11
12
12
This can be problematic in cases where zero counts have been collected, as the standard deviation will then be zero,
13
13
which will subsequently lead to "infinite" point weightings in downstream fitting routines for example.
@@ -24,17 +24,17 @@ Use a standard deviation of `NaN` for points with zero counts.
24
24
25
25
### Option C
26
26
27
-
Define the standard deviation of `N` counts as `1` if counts are zero, otherwise `sqrt(N)`. This is one of the
27
+
Define the standard deviation of {math}`N` counts as {math}`1` if counts are zero, otherwise {math}`\sqrt{N}`. This is one of the
28
28
approaches [available in mantid](https://github.com/mantidproject/mantid/blob/bbbb86edc2c3fa554499770463aa25c2b46984e5/docs/source/algorithms/SetUncertainties-v1.rst#L16) for example.
29
29
30
30
### Option D
31
31
32
-
Define the standard deviation of `N` counts as `sqrt(N+0.5)` unconditionally - on the basis that "half a count" is
32
+
Define the standard deviation of {math}`N` counts as {math}`\sqrt{N+0.5}` unconditionally - on the basis that "half a count" is
33
33
smaller than the smallest possible actual measurement which can be taken.
34
34
35
35
### Option E
36
36
37
-
No special handling, calculate std. dev. as `sqrt(N)`.
37
+
No special handling, calculate std. dev. as {math}`\sqrt{N}`.
Copy file name to clipboardExpand all lines: doc/architectural_decisions/008-centre-of-mass.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,14 +10,14 @@ A decision needs to be made about whether to make changes to upstream Bluesky so
10
10
11
11
## Decision
12
12
13
-
We will be making our own {py:obj}`CentreOfMass <ibex_bluesky_core.callbacks.CentreOfMass>` callback.
13
+
We will be making our own {py:obj}`~ibex_bluesky_core.callbacks.CentreOfMass` callback.
14
14
15
15
## Justification & Consequences
16
16
17
17
[We attempted to make changes to upstream Bluesky which were rejected](https://github.com/bluesky/bluesky/pull/1878), as it adds limits to the functionality of the callback. We also found other limitations with using their callback, such as not being able to have disordered and non-continuous data sent to it without it skewing the calculated value - we need it to work with disordered and non-continuous data as we need to be able to run continuous scans.
18
18
19
-
We currently only need to support positive peaks, but in future a toggle could be added to {py:obj}`CentreOfMass <ibex_bluesky_core.callbacks.CentreOfMass>` to allow for negative peaks.
19
+
We currently only need to support positive peaks, but in future a toggle could be added to {py:obj}`~ibex_bluesky_core.callbacks.CentreOfMass` to allow for negative peaks.
20
20
21
21
This will mean that...
22
22
- Our version of the callback will not be supported by Bluesky and may need changes as Bluesky updates.
23
-
- We can have a version of the callback that is made bespokely for our use cases.
23
+
- We can have a version of the callback that is made specifically for our use cases.
{py:obj}`ibex_bluesky_core.callbacks.CentreOfMass` is a callback that provides functionality for calculating our definition of Centre of Mass. We calculate centre of mass from the 2D region bounded by min(y), min(x), max(x), and straight-line segments joining (x, y) data points with their nearest neighbours along the x axis.
3
+
{py:obj}`ibex_bluesky_core.callbacks.CentreOfMass` provides functionality for calculating a specific definition of a "centre of mass": it computes the centre of mass of a 2-dimensional region bounded by:
4
+
-`min(x)`
5
+
-`max(x)`
6
+
-`min(y)`
7
+
- Straight-line segments joining `(x, y)` data points with their nearest neighbours along the x axis
4
8
5
-
{py:obj}`ibex_bluesky_core.callbacks.CentreOfMass`has a property, {py:obj}`result <ibex_bluesky_core.callbacks.CentreOfMass.result>`, which stores the centre of mass value once the callback has finished.
9
+
{py:obj}`~ibex_bluesky_core.callbacks.CentreOfMass`stores its result in the {py:obj}`~ibex_bluesky_core.callbacks.CentreOfMass.result` property.
6
10
7
-
## Our CoM Algorithm
11
+
:::{note}
12
+
This will return **different** results from the `com` property available from {py:obj}`bluesky.callbacks.fitting.PeakStats` in the following cases:
13
+
- Points irregularly sampled along the x-axis
14
+
- Points with negative y-values
15
+
- x data which does not monotonically increase
8
16
9
-
Given non-continuous arrays of collected data `x` and `y`, ({py:obj}`ibex_bluesky_core.callbacks.CentreOfMass`) returns the `x` value of the centre of mass.
17
+
For a detailed comparison of the two implementations, see [unit tests written to expose tricky cases](https://github.com/bluesky/bluesky/blob/2d6fecd45e8de3a7d53d1c16dcd1a7b8f6f88d69/src/bluesky/tests/test_scientific.py#L142).
18
+
:::
10
19
11
-
Our use cases require that our algorithm abides to the following rules:
12
-
- Any background on data does not skew the centre of mass
13
-
- The order in which data is received does not skew the centre of mass
20
+
Given non-continuous arrays of collected data `x` and `y`, {py:obj}`~ibex_bluesky_core.callbacks.CentreOfMass` returns the `x` value of the centre of mass.
21
+
22
+
Many of our use cases require that our algorithm follows the following rules:
23
+
- Any background on data should not change the centre of mass.
24
+
- The order in which data is received should not change the centre of mass
14
25
- Should support non-constant point spacing without skewing the centre of mass
15
26
16
27
```{note}
17
28
Note that this is designed for only **positive** peaks.
18
29
```
19
30
20
-
### Step-by-step
31
+
{py:obj}`ibex_bluesky_core.callbacks.CentreOfMass` is included in {doc}`our callbacks collection <isiscallbacks>`.
32
+
33
+
---
34
+
35
+
**Implementation details**
21
36
22
37
1) Sort `x` and `y` arrays in respect of `x` ascending. This is so that data can be received in any order.
23
-
2) From each `y` element, subtract `min(y)`. This means that any constant background over data is ignored. (Does not work for negative peaks)
24
-
3) Calculate weight/widths for each point; based on it's `x` distances from neighbouring points. This ensures non-constant point spacing is accounted for in our calculation.
25
-
4) For each decomposed shape that makes up the total area under the curve, `CoM` is calculated as the following:
38
+
2) From each `y` element, subtract `min(y)`. This means that any constant background over data is ignored.
39
+
3) Decompose the curve into a series of trapezoidal regions, and then further decompose those
40
+
trapezoidal regions into rectangular and triangular regions.
41
+
4) Compute centre of mass of the overall shape by composition of each region:
26
42
```{math}
27
-
com_x = \frac{\sum_{}^{}x * y * \text{weight}}{\sum_{}^{}y * \text{weight}}
28
-
```
29
-
30
-
{py:obj}`ibex_bluesky_core.callbacks.CentreOfMass` can be used from our callbacks collection. See {doc}`isiscallbacks`.
Copy file name to clipboardExpand all lines: doc/callbacks/file_writing.md
+8-9Lines changed: 8 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,11 +3,10 @@
3
3
{#hr_file_cb}
4
4
## Human readable files
5
5
6
-
A callback ([`HumanReadableFileCallback`](ibex_bluesky_core.callbacks.HumanReadableFileCallback)) exists to write all documents to a separate human-readable file which contains the specified fields.
6
+
{py:obj}`~ibex_bluesky_core.callbacks.HumanReadableFileCallback` can be configured to write all documents to a human-readable file which contains the specified fields.
7
7
8
-
This callback will add units and honour precision for each field as well as add some metadata ie. the `uid` of each scan as well as the RB number, which is injected using the {doc}`/dev/rbnumberpp`
8
+
This callback will add units and honour precision for each field as well as add some metadata, for example the RB number, which is injected using the {doc}`/dev/rbnumberpp`.
9
9
10
-
### Example
11
10
An example of using this could be:
12
11
13
12
```{code} python
@@ -47,17 +46,17 @@ RE(some_plan())
47
46
```
48
47
49
48
This will put the `block` and `dae.good_frames` data collected over the run into a `.txt` file, named after the `uid`
50
-
of the scan, in `C:\instrument\var\logs\bluesky\output_files\`.
49
+
of the scan, in `\\isis\inst$\ndx<inst>\user\bluesky_scans\<rbnumber>`.
51
50
52
51
Optional parameters, not shown above, include:
53
-
-`output_dir` parameter is optional, if not input the file will by default be placed in
52
+
-`output_dir` parameter is optional; if not provided, the file will by default be placed in
-`postfix` an optional suffix to append to the end of the file name, to disambiguate scans. Default is no suffix.
56
55
57
56
The data is prepended on the first event with the names and units of each logged field, and then subsequently the data
58
-
for each scan separated by a newline. All of this is separated by commas, though the metadata is not.
57
+
for each scan separated by a newline. The data is separated by commas, though the metadata is not.
59
58
60
-
The file also contains metadata such as the bluesky version, plan type, and rb number.
59
+
The file also contains metadata such as the bluesky version, plan type, and RB number.
61
60
62
61
## Fit outputs
63
62
@@ -74,6 +73,6 @@ See {ref}`plot_png_saver`
74
73
This callback is added automatically and is not intended to be user-facing - it is primarily for developer diagnostics.
75
74
```
76
75
77
-
The [`DocLoggingCallback`](ibex_bluesky_core.callbacks.DocLoggingCallback) is a callback that the BlueSky RunEngine subscribes to unconditionally in {py:obj}`RunEngine import level<ibex_bluesky_core.run_engine.get_run_engine>`. After receiving each document, if they share the same start document (in the same run) then it will write them to the same file. These logs are stored under `C:/instrument/var/logs/bluesky/raw_documents` and are handled by the log rotation.
76
+
The {py:obj}`~ibex_bluesky_core.callbacks.DocLoggingCallback` is a callback that the BlueSky RunEngine subscribes to unconditionally during {py:obj}`~ibex_bluesky_core.run_engine.get_run_engine`. It logs all documents it receives into files grouped by unique scan identifier. These logs are stored under `C:/instrument/var/logs/bluesky/raw_documents`; older logs are moved to long-term storage by a log rotation script.
78
77
79
-
Each document is stored in a JSON format so can be both machine and humanreadable. It is in the format `{"type": name, "document": document}` whereby `name` is the type of the document, e.g start, stop, event, descriptor and the `document` is the [document from BlueSky in JSON format](https://blueskyproject.io/bluesky/main/documents.html). As these files are produced per BlueSky run, these will be useful for debugging.
78
+
Each document is stored in a JSON format so can be both machine and human-readable. The format is line-delimited JSON, `{"type": name, "document": document}` whereby `name` is the type of the document, e.g start, stop, event, descriptor and the `document` is the {external+bluesky:doc}`document from bluesky in JSON format <documents>`.
0 commit comments