Corryvreckan merge requestshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests2019-08-19T09:55:47+02:00https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/140New detector role: "auxiliary"2019-08-19T09:55:47+02:00Simon SpannagelNew detector role: "auxiliary"This new role allows to drop certain detectors in the reco because they just initially supplied additional information, such as a TLU.
Modules wishing to make use of this have to manually check
```cpp
if(detector->isAuxiliary()) {
//...This new role allows to drop certain detectors in the reco because they just initially supplied additional information, such as a TLU.
Modules wishing to make use of this have to manually check
```cpp
if(detector->isAuxiliary()) {
// do nothing
} else {
// do magic
}
```https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/139EvLoEUDAQ2: create new StdEvent instead of recycling if decoding fails2019-08-06T09:23:35+02:00Simon SpannagelEvLoEUDAQ2: create new StdEvent instead of recycling if decoding failsWe should create new StandardEvents after the decoding of one failed. Currently, we are re-using the event which might already contain some information set before the decoding process returned `false`.
Imagine a decoder:
```cpp
bool My...We should create new StandardEvents after the decoding of one failed. Currently, we are re-using the event which might already contain some information set before the decoding process returned `false`.
Imagine a decoder:
```cpp
bool MyStdEventConverter::Converting(eudaq::EventSPC d1, eudaq::StandardEventSP d2, eudaq::ConfigurationSPC conf) const {
auto ev = std::dynamic_pointer_cast<const eudaq::RawEvent>(d1);
// Set a tag
d2->SetTag("soup", "magic");
if(1) false;
}
```
This will first set a tag in the event object `d2` and then return false. If we continue with
```cpp
auto stevt = eudaq:StandardEvent::MakeShared();
do {
//...
bool failed = Convert(event, stdevt);
} while (failed)
```
The tag will persist. Thus, we need to delete the failed `stdevt` attempt and create a new one.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/138Updated documentation for EventLoaderEUDAQ22019-08-01T18:58:38+02:00Katharina DortUpdated documentation for EventLoaderEUDAQ2Updated documentation specifying which cmake flags should be set when building EUDAQ.Updated documentation specifying which cmake flags should be set when building EUDAQ.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/137Update README.md with @pschutze and @kdort as authors2019-08-01T11:57:00+02:00Simon SpannagelUpdate README.md with @pschutze and @kdort as authorshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/136Objects: use ROOT's ClassDefOverride for Track & Cluster2019-08-01T10:30:56+02:00Simon SpannagelObjects: use ROOT's ClassDefOverride for Track & ClusterObjects: use ROOT's ClassDefOverride for Track & Cluster where <<-operator overwrites the parent class operator
Rel to !132 by @pschutzeObjects: use ROOT's ClassDefOverride for Track & Cluster where <<-operator overwrites the parent class operator
Rel to !132 by @pschutzehttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/135Follow up on MR !1202019-08-07T12:55:59+02:00Jens KroegerFollow up on MR !120This is a merge-request addressing @simonspa's comments on MR !120.
Here's the list:
__Simon:__
This merge might have been a bit early, there are several things I would like to see addressed:
* [x] Hardcoding `TLU` is not nic...This is a merge-request addressing @simonspa's comments on MR !120.
Here's the list:
__Simon:__
This merge might have been a bit early, there are several things I would like to see addressed:
* [x] Hardcoding `TLU` is not nice, especially with a type-sensitive comparison
* [x] For `adjust_event_times` why can't the default not just be empty? Having a default that doesn't mean anything isn't good style imho
* [x] For `require_detector` I remember discussing to implement this as `getArray<std::string>` to directly allow requiring multiple detectors.
* [x] I don't like the name `detector_to_set_track_timestamp` and also not that `Timepix3_0` is a hard-coded value as default.
* [x] `Track::hasDetector` has to be a `const` function.
Apart from that - nice work!https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/134DUT association based on proximity of clusters to track2019-08-06T14:53:48+02:00Katharina DortDUT association based on proximity of clusters to track**Problem:** Currently, the DUTAssociation module allows the association of several clusters to one track. This turns out to be an issue especially if the DUT is noisy (see also Issue tracker).
**Suggestion:** Only allow one associat...**Problem:** Currently, the DUTAssociation module allows the association of several clusters to one track. This turns out to be an issue especially if the DUT is noisy (see also Issue tracker).
**Suggestion:** Only allow one associated cluster per track. The choice of the cluster can be based on spatial/temporal proximity or alternatively on ToT (but to be discussed)
**Status:** In order to keep the changes as small as possible I added closestCluster as a parameter to the track object which I set during the DUTAssociation. Currently, closestCluster is always the one closest in space (not in time).
In DUTAnalysis I left the loop over all clusters untouched and just do a comparison of the current cluster to the closestCluster which I get from a given track. This is to be discussed since it appears to be more efficient to delete the loop over all clusters.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/133Histograms showing number of cluster/tracks discarded by cuts2019-08-05T14:49:57+02:00Katharina DortHistograms showing number of cluster/tracks discarded by cutsThe 'cut flow histograms' are currently only implemented for DUTAssociation and for AnalysisDUT. We could add them to other modules as well if needed.
Please have a look at the naming of the histograms and let me know if you have oth...The 'cut flow histograms' are currently only implemented for DUTAssociation and for AnalysisDUT. We could add them to other modules as well if needed.
Please have a look at the naming of the histograms and let me know if you have other suggestions. I tried to find a trade-off between having a descriptive title while being concise but I'm not 100% satisfied with it.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/132Add Textwriter module for ASCII data output2019-08-01T09:46:10+02:00Paul Jean SchutzeAdd Textwriter module for ASCII data outputAdd module `TextWriter`. With this module it is possible to save objects in ASCII format, as long as for this object type a printout is defined. A lot of the implementation was adapted from the allpix-squared [TextWriter](https://gitlab....Add module `TextWriter`. With this module it is possible to save objects in ASCII format, as long as for this object type a printout is defined. A lot of the implementation was adapted from the allpix-squared [TextWriter](https://gitlab.cern.ch/allpix-squared/allpix-squared/tree/master/src/modules/TextWriter) module. I tried it so far with `Pixel`, `Cluster` and `Track`.
As in the allpix-squared alike, object types can included or excluded via the configuration and a filename can be specified.
An example output can be found below.
=== 0 ===
=== 1 ===
--- MIMOSA26_1 ---
+++ Cluster +++
Cluster 2.6496, -3.6616, -2.6496, -3.6616, -2.6496, 1, 0, 1, 1, 1, 2.80479e+10
Cluster 3.6892, -0.7176, -3.6892, -0.7176, -3.6892, 2, 0, 2, 2, 1, 2.80479e+10
Cluster -6.0536, 4.5448, 6.0536, 4.5448, 6.0536, 1, 0, 1, 1, 1, 2.80479e+10
Cluster 2.7416, 1.2972, -2.7416, 1.2972, -2.7416, 2, 0, 2, 1, 2, 2.80479e+10
Cluster 6.1456, 3.2384, -6.1456, 3.2384, -6.1456, 1, 0, 1, 1, 1, 2.80479e+10
--- MIMOSA26_1 ---
+++ Pixel +++
Pixel 720, 89, 1, 1, 2.80479e+10
Pixel 776, 249, 1, 1, 2.80479e+10
Pixel 777, 249, 1, 1, 2.80479e+10
Pixel 247, 535, 1, 1, 2.80479e+10
Pixel 725, 358, 1, 1, 2.80479e+10
Pixel 725, 359, 1, 1, 2.80479e+10
Pixel 910, 464, 1, 1, 2.80479e+10
--- MIMOSA26_2 ---
+++ Cluster +++
Cluster -8.5836, 0.1288, 8.5836, 0.1288, 8.5836, 48, 0, 48, 24, 1, 2.80479e+10
Cluster 9.4576, -0.92, -9.4576, -0.92, -9.4576, 1, 0, 1, 1, 1, 2.80479e+10
Cluster -8.1052, 0.1288, 8.1052, 0.1288, 8.1052, 24, 0, 24, 12, 1, 2.80479e+10
Cluster -2.852, 2.8704, 2.852, 2.8704, 2.852, 1, 0, 1, 1, 1, 2.80479e+10
Cluster 8.2984, 1.564, -8.2984, 1.564, -8.2984, 1, 0, 1, 1, 1, 2.80479e+10
Cluster 5.0968, -0.5704, -5.0968, -0.5704, -5.0968, 1, 0, 1, 1, 1, 2.80479e+10
--- MIMOSA26_2 ---
+++ Pixel +++
Pixel 105, 295, 1, 1, 2.80479e+10
Pixel 114, 295, 1, 1, 2.80479e+10
Pixel 113, 295, 1, 1, 2.80479e+10
Pixel 112, 295, 1, 1, 2.80479e+10
Pixel 111, 295, 1, 1, 2.80479e+10
Pixel 110, 295, 1, 1, 2.80479e+10
Pixel 109, 295, 1, 1, 2.80479e+10
Pixel 108, 295, 1, 1, 2.80479e+10
Pixel 107, 295, 1, 1, 2.80479e+10
Pixel 106, 295, 1, 1, 2.80479e+10
Pixel 115, 295, 1, 1, 2.80479e+10
Pixel 104, 295, 1, 1, 2.80479e+10
Pixel 103, 295, 1, 1, 2.80479e+10
Pixel 102, 295, 1, 1, 2.80479e+10
Pixel 101, 295, 1, 1, 2.80479e+10
......
....
..https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/131Added histograms for cluster seed signal to both clustering modules2019-08-02T10:25:19+02:00Katharina DortAdded histograms for cluster seed signal to both clustering modulesAdded histograms for cluster seed signal to both clustering modulesAdded histograms for cluster seed signal to both clustering moduleshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/130Fixing formatting of TestAlgorithm2019-07-29T16:03:53+02:00Morag WilliamsFixing formatting of TestAlgorithmFix formatting problem created by !129Fix formatting problem created by !129https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/129ROIs in TestAlgorithm2019-07-29T15:35:27+02:00Katharina DortROIs in TestAlgorithmIt's now possible to define ROIs in TestAlgorithm as well. Previously, only AnalysisDUT accepted ROIs. It's now possible to define ROIs in TestAlgorithm as well. Previously, only AnalysisDUT accepted ROIs. https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/128EventLoaderEUDAQ2: time sorting2019-08-07T17:28:02+02:00Jens KroegerEventLoaderEUDAQ2: time sortingThis MR adds optional timesorting to the EventLoaderEUDAQ2.
It can be configured as follows:
* `do_timesorting`: `false` --> everything as before, `true` --> fill buffer with `buffer_depth` and return earliest `StandardEvent`
* `b...This MR adds optional timesorting to the EventLoaderEUDAQ2.
It can be configured as follows:
* `do_timesorting`: `false` --> everything as before, `true` --> fill buffer with `buffer_depth` and return earliest `StandardEvent`
* `buffer_depth`: depth of buffer in which `StandardEvents` are timesorted. If `0`, no timesorting will be done but everything works as before.
__First attempt:__
As a first attempt, it's implemented as a `std::vector<"Standard Event">` which is filled until its size is `buffer_depth` and then timesorted using `std::sort`.
This was a very compact and easy-to-read implementation, however it might not be the most efficient one - as discussed in length on Thursday last week.
__Current solution:__
Now a much faster implementation is making use of `std::priority_queue` into which new elements are inserted directly into the right spot and only the first element can be popped.
This solves the issue with saw with the Timepix3, e.g. in run 866, where a small mix-up in the chronological order, i.e. 1 late event screws up the event building because until we get to that late event, no hits will be filled into any Corryvreckan event and after that event all the earlier events will be rejected because their position is `BEFORE`.
__Experimental try which didn't work:__
The solution using a `std:priority_queue` was also tested for the buffer holding sub-events and sorting them anti-alphabetically. We tested that with a toy model and also in real life `corry`, and it seems like `std::priority_queue` is mixing up the order of elements if the comparison criterion is equal which `std::sort` doesn't do.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/127New histograms for row/column cluster size2019-07-31T16:47:40+02:00Katharina DortNew histograms for row/column cluster sizeTwo new histograms for cluster size in row/column direction for associated clusters. README is updated as well.Two new histograms for cluster size in row/column direction for associated clusters. README is updated as well.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/126EventLoaderEUDAQ2: bool for time residuals2019-08-02T16:07:16+02:00Jens KroegerEventLoaderEUDAQ2: bool for time residualsThis merge requests adds the following feature to the `[EventLoaderEUDAQ2]`:
* bool to decide if time residual plots are produced or not (default is `false`, as these plots slow corry down significantly).
These plots are useless f...This merge requests adds the following feature to the `[EventLoaderEUDAQ2]`:
* bool to decide if time residual plots are produced or not (default is `false`, as these plots slow corry down significantly).
These plots are useless for detectors without time information like `CLICpix2` and slow `corryvreckan` down, so now they are optional.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/125Make filewriter write data on an event-by-event basis2019-08-25T15:51:16+02:00Paul Jean SchutzeMake filewriter write data on an event-by-event basisWith this MR, the `Filewriter` writes the data into the TTrees on an event-by-event basis. For each processed event, detector and object type, one vector of objects is stored instead of a continuous stream of the objects. The latter lead...With this MR, the `Filewriter` writes the data into the TTrees on an event-by-event basis. For each processed event, detector and object type, one vector of objects is stored instead of a continuous stream of the objects. The latter lead to an incapability of merging all hits in a certain event.
As a consequence, in some post-processing macro calling `TTree->GetEntry(eventNumber)` yields a vector of the requested object type.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/124Automatically create TProfiles from EUDAQ2 Event tags2019-08-23T13:08:10+02:00Simon SpannagelAutomatically create TProfiles from EUDAQ2 Event tagsThis checks the events for tags and creates TProfile plots over the number of events. This is only attempted if the value of the tag can be directly converted to a double-precision floating point number using `std::stod()`.
Needs testing.This checks the events for tags and creates TProfile plots over the number of events. This is only attempted if the value of the tag can be directly converted to a double-precision floating point number using `std::stod()`.
Needs testing.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/123Bring order to the universe2019-07-05T15:19:38+02:00Simon SpannagelBring order to the universeJens KroegerJens Kroegerhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/122Update installation.tex: fix missing part or clone URL2019-07-04T20:29:44+02:00Katharina DortUpdate installation.tex: fix missing part or clone URL:)
:penguin::)
:penguin:https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/121EVEUDAQ2: convert EUDAQ2 picoseconds to Corry nanoseconds when reading events2019-07-04T13:42:40+02:00Simon SpannagelEVEUDAQ2: convert EUDAQ2 picoseconds to Corry nanoseconds when reading eventsThis MR aligns our EUDAQ3 version with upstream master. There it has been decided to use `uint64_t` timestamps in picoseconds instead of nanoseconds as double.
While we might also change at some point in the future, we now just conver...This MR aligns our EUDAQ3 version with upstream master. There it has been decided to use `uint64_t` timestamps in picoseconds instead of nanoseconds as double.
While we might also change at some point in the future, we now just convert the timestamps in the EventLoaderEUDAQ2 module.
@lhuth this should solve your issue with master EUDAQ2.
@jekroege please verify and mergeJens KroegerJens Kroeger