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
@@ -585,6 +587,72 @@ the directories listed in the logs:
585
587
Notice that by default the executable will ignore the directory structure in the input file and upload all objects to one directory.
586
588
If you need the directory structure preserved, add the argument `--preserve-directories`.
587
589
590
+
## Propagating Check results to RCT in Bookkeeping
591
+
592
+
The framework allows to propagate Quality Objects (QOs) produced by Checks and Aggregators to RCT in Bookkeeping.
593
+
The synchronisation is done once, at the end of workflow runtime, i.e. at the End of Run or in the last stage of QC merging on Grid.
594
+
Propagation can be enabled by adding the following key-value pair to Check/Aggregator configuration:
595
+
```json
596
+
"exportToBookkeeping": "true"
597
+
```
598
+
Using it for Aggregators is discouraged, as the information on which exact Check failed is lost or at least obfuscated.
599
+
600
+
Check results are converted into Flags, which are documented in [O2/DataFormats/QualityControl](https://github.com/AliceO2Group/AliceO2/tree/dev/DataFormats/QualityControl).
601
+
Information about the object validity is preserved, which allows for time-based flagging of good/bad data.
602
+
603
+
### Conversion details
604
+
605
+
Below we describe some details of how the conversion is done.
606
+
Good QOs are marked with green, Medium QOs are marked with orange and Bad QOs are marked with red.
607
+
Null QOs are marked with purple.
608
+
609
+
- **Good QOs with no Flags associated are not converted to any Flags.**
610
+
According to the preliminary design for Data Tagging, "bad" Flags always win, thus there is no need for explicit "good" Flags.
611
+
It also implies that there is no need to explicitly add Good Flag to Good Quality.
612
+
613
+

614
+
615
+
- **Bad and Medium QOs with no Flags are converted to Flag 14 (Unknown).**
616
+
This means that Medium Quality data is by default bad for Analysis.
617
+
618
+

619
+
620
+
- **Null QOs with no Flags are converted to Flag 1 (Unknown Quality).**
621
+
622
+

623
+
624
+
- **All QOs with Flags are converted to Flags, while the Quality is ignored.**
625
+
As a consequence, one can customize the meaning of any Quality (Medium in particular) in terms of data usability.
626
+
A warning is printed if a Check associates a good Flag to bad Quality or a bad Flag to good Quality.
627
+
628
+

629
+
630
+
- **Timespans not covered by a given QO are filled with Flag 1 (Unknown Quality).**
631
+
In other words, if an object was missing during a part of the run, we can state that the data quality is not known.
632
+
633
+

634
+
635
+
- **Overlapping or adjacent Flags with the same ID, comment and source (QO name) are merged.**.
636
+
This happens even if they were associated with different Qualities, e.g. Bad and Medium.
637
+
Order of Flag arrival does not matter.
638
+
639
+

640
+

641
+
642
+
- **Flag 1 (Unknown Quality) is overwritten by any other Flag.**
643
+
This allows us to return Null Quality when there is not enough statistics to determine data quality, but it can be suppressed later, once we can return Good/Medium/Bad.
644
+
645
+

646
+
647
+
- **Good and Bad flags do not affect each other, they may coexist.**
648
+
649
+

650
+
651
+
- **Flags for different QOs (QO names) do not affect each other.
652
+
Flag 1 (Unknown Quality) is added separately for each.**
653
+
654
+

655
+
588
656
# Solving performance issues
589
657
590
658
Problems with performance in message passing systems like QC usually manifest in backpressure seen in input channels of processes which are too slow.
Copy file name to clipboardExpand all lines: doc/ModulesDevelopment.md
+14-2Lines changed: 14 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -22,6 +22,7 @@
22
22
*[Check](#check)
23
23
*[Configuration](#configuration)
24
24
*[Implementation](#implementation)
25
+
*[Results](#results)
25
26
*[Quality Aggregation](#quality-aggregation)
26
27
*[Quick try](#quick-try)
27
28
*[Configuration](#configuration-1)
@@ -300,7 +301,8 @@ A Check is a function (actually `Check::check()`) that determines the quality of
300
301
"type": "Task",
301
302
"name": "QcTask",
302
303
"MOs": ["example", "other"]
303
-
}]
304
+
}],
305
+
"exportToBookkeeping": "false"
304
306
},
305
307
"QcCheck": {
306
308
...
@@ -323,6 +325,7 @@ A Check is a function (actually `Check::check()`) that determines the quality of
323
325
* _type_ - currently only supported are _Task_ and _ExternalTask_
324
326
* _name_ - name of the _Task_
325
327
* _MOs_ - list of MonitorObjects names or can be omitted to mean that all objects should be taken.
328
+
* __exportToBookkeeping__ - allows to propagate the results of this Check to Bookkeeping, where they are visualized as time-based Flags (disabled by default).
326
329
327
330
### Implementation
328
331
After the creation of the module described in the above section, every Check functionality requires a separate implementation. The module might implement several Check classes.
The `check()` function is called whenever the _policy_ is satisfied. It gets a map with all declared MonitorObjects. It is expected to return Quality of the given MonitorObjects.
339
+
The `check()` function is called whenever the _policy_ is satisfied. It gets a map with all declared MonitorObjects.
340
+
It is expected to return Quality of the given MonitorObjects.
341
+
Optionally one can associate one or more Flags to a Quality by using `addFlag` on it.
337
342
338
343
For each MO or group of MOs, `beautify()` is invoked after `check()` if
339
344
1. the check() did not raise an exception
340
345
2. there is a single `dataSource` in the configuration of the check
341
346
347
+
### Results
348
+
349
+
Checks return Qualities with associated Flags.
350
+
The framework wraps them with a QualityObject, then makes it available to Aggregators (see the next section) and stores them in the repository.
351
+
It is also possible to propagate Check results to the Run Condition Table (RCT) in Bookkeeping.
352
+
Details are explained at [Propagating Check results to RCT in Bookkeeping](Advanced.md#propagating-check-results-to-rct-in-bookkeeping)
353
+
342
354
## Quality Aggregation
343
355
344
356
The _Aggregators_ are able to collect the QualityObjects produced by the checks or other _Aggregators_ and to produce new Qualities. This is especially useful to determine the overall quality of a detector or a set of detectors.
0 commit comments