Corryvreckan merge requestshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests2024-03-28T11:06:04+01:00https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/681Draft: Module AnalysisBeamProfile2024-03-28T11:06:04+01:00Paul Jean SchutzeDraft: Module AnalysisBeamProfileThis implements a module called `AnalysisBeamProfile`.
This module is can be used for analysing properties of a bunched beam on an event-by-event basis. What it does is the following:
* read `Pixel` objects for the corresponding detecto...This implements a module called `AnalysisBeamProfile`.
This module is can be used for analysing properties of a bunched beam on an event-by-event basis. What it does is the following:
* read `Pixel` objects for the corresponding detector from the clipboard
* create a single cluster per event
* assign central cluster position and `errorX`&`errorY` as widths based on a fit to a gaussian distribution or from statistics to (charge-weighted) projections onto the x/y-axes
* add cluster to clipboard
* plot hitmaps, projections and width/center distributions, most of them also vs event number
Points for discussion:
- [x] Renaming? I could imagine that a more generic name like `AnalysisBeamProfile` would be more suitable. We use it for [this method](https://indico.cern.ch/event/1232761/contributions/5357414/), but in principle the functionality is very generic. Any opinions?
- [ ] `Cluster->errorX()`? I abused the `errorX`&`errorY` for storing the width of the cluster. The reason is, that here we'd like to store the width of a gaussian of the cluster projection (or StdDev, depending on the configuration), and the `columnWidth`&`rowWidth` members are [Cluster-internally coded](https://gitlab.cern.ch/corryvreckan/corryvreckan/-/blob/master/src/objects/Cluster.cpp?ref_type=heads#L28) to be the extent of the cluster along these axes, computed during `addPixel(...)`. An option would be to add setter functions for the `columnWidth`&`rowWidth` members and overwrite them in the new module after the last pixel has been added. Any opinions?https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/673ClusteringSpatial: allow split clusters2024-02-06T17:24:34+01:00Gianpiero VignolaClusteringSpatial: allow split clustersThe possibility of having split clusters is implemented in Clustering4D. However, it is a purely spatial feature. Does it make sense to include it in ClusteringSpatial as well?The possibility of having split clusters is implemented in Clustering4D. However, it is a purely spatial feature. Does it make sense to include it in ClusteringSpatial as well?Gianpiero VignolaGianpiero Vignolahttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/610AnalysisEfficiency: Added fake rate analysis and plots.2023-03-03T11:34:27+01:00Finn FeindtAnalysisEfficiency: Added fake rate analysis and plots.The main idea is to look for clusters and hits that are far away from reconstructed tracks. Those are defined as fake, which neglects effects of tracking in-efficiency. There are two slightly different versions. The “radial” version cons...The main idea is to look for clusters and hits that are far away from reconstructed tracks. Those are defined as fake, which neglects effects of tracking in-efficiency. There are two slightly different versions. The “radial” version considers DUT clusters without reconstructed track in a configurable radius around them as fake. The other looks for events without tracks intercepting the DUT and considers all DUT activity in these events as fake. The former method is intended for large DUTs, the latter for small ones. Both are briefly described in the README.
I ran some tests on dSiPM data. Both methods give results that are compatible with expectations from DCR measurements at similar over-voltage and temperature, although the “radial” method yields systematically higher results. I would say some systematic studies are needed.Finn FeindtFinn Feindthttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/597AlignmentDUTResidual: ridefinition of residual2023-09-07T13:46:35+02:00Gianpiero VignolaAlignmentDUTResidual: ridefinition of residualImplemented the possibility of redefining residuals with any 2D TFormula with 'x' and 'y' representing `track intercepts` and the `cluster position` respectivelyImplemented the possibility of redefining residuals with any 2D TFormula with 'x' and 'y' representing `track intercepts` and the `cluster position` respectivelySimon SpannagelGianpiero VignolaSimon Spannagelhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/585Module AlignmentTime2024-01-31T07:04:20+01:00Finn FeindtModule AlignmentTimeStill a draft. See README.md for more detailed module description. I would like to discuss if this module makes sense at all, and possible changes before I put more efforts in. Topics for discussion:
* At the moment, the module uses pixe...Still a draft. See README.md for more detailed module description. I would like to discuss if this module makes sense at all, and possible changes before I put more efforts in. Topics for discussion:
* At the moment, the module uses pixel time stamps. So one needs to build events using the metronome, which can be a bit tricky, e.g. when time stamps are provided by an auxiliary detector.
* The guessing of initial parameters for the search can be optimized, but I think in the end users will need to configure the search properly.
* Should one do a coarse and a fine search automatically?
* Should one automatically add the shift to the geometry file?
* Add output plots for clock drifts?
This closes #93Finn FeindtFinn Feindthttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/572EventLoaderEUDAQ: Allow Re-Mapping of EUDAQ Plane IDs to Corry Names2022-11-23T10:46:19+01:00Simon SpannagelEventLoaderEUDAQ: Allow Re-Mapping of EUDAQ Plane IDs to Corry NamesSometimes the user would like to give detectors different names in Corryvreckan than provided by EUDAQ, or EUDAQ stores plane IDs in the data file which are incompatible with Corryvreckan configuration section headers. In this case, the ...Sometimes the user would like to give detectors different names in Corryvreckan than provided by EUDAQ, or EUDAQ stores plane IDs in the data file which are incompatible with Corryvreckan configuration section headers. In this case, the `remap_detectors` parameter can be used to assign new names to the individual EUDAQ plane IDs. The parameter is a 2D matrix, with two entries per row, the first being the EUDAQ plane ID and the second the desired Corryvreckan name of the detector. For example:
```toml
remap_detectors = [["USBPIX_GEN3_BOARD_-1_22", "FEI4"]]
```
would rename a EUDAQ plane called `USBPIX_GEN3_BOARD_-1_22`, incompatible with the Corryvreckan configuration, to a simple `FEI4`.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/568Creating a new module to read in data from a ALiBaVa system2022-12-01T14:49:43+01:00Fabian Simon LexCreating a new module to read in data from a ALiBaVa systemDescription:
The goal of this module is to be able to read data produced by the ALiBaVa readout system into Corryvreckan. Both the binary and the hdf file format produced by ALiBaVa are going to be supported. The raw data is going to be...Description:
The goal of this module is to be able to read data produced by the ALiBaVa readout system into Corryvreckan. Both the binary and the hdf file format produced by ALiBaVa are going to be supported. The raw data is going to be corrected for pedestal, noise, common mode and crosstalk.
Parameters that can be given to the module are the input directory and run number (to identify the input file), the lower and upper timecut (needed due to the way ALiBaVa works), the number of ignored events (to sync the events between ALiBaVa and telescope), the region of interest (to e.g do the analysis for only one of the two chips) and the polarity (as the sign of the signal changes depending on sensor type). Additionally it is going to be possible to give some sort of calibration to the module in order to convert the arbitrary ADC values into charge.
Current status:
Eventloader can read in binary files, timecuts, ignored events, ROI and polarity work as expected. Pedestal, noise and common mode correction are working properly. Pixel objects are created with ADC values instead of charge and can be used properly by other modules (e.g. Clustering).
To Do:
- Test if hdf files are read in correctly
- Implement crosstalk correction
- Implement calibration (still unclear in what way)
- Clean up the third party code for increased readabilityFabian Simon LexFabian Simon Lexhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/549EventLoaderEUDAQ2: Add Possiblity to Read Waveforms2022-08-10T15:33:41+02:00Simon SpannagelEventLoaderEUDAQ2: Add Possiblity to Read Waveforms...needs https://github.com/eudaq/eudaq/pull/664, so it would be great to merge that and then tag EUDAQ 2.5.0 so we can up the requirement in CMake [here](https://gitlab.cern.ch/corryvreckan/corryvreckan/-/blob/master/src/modules/EventLo......needs https://github.com/eudaq/eudaq/pull/664, so it would be great to merge that and then tag EUDAQ 2.5.0 so we can up the requirement in CMake [here](https://gitlab.cern.ch/corryvreckan/corryvreckan/-/blob/master/src/modules/EventLoaderEUDAQ2/CMakeLists.txt#L6).Simon SpannagelSimon Spannagelhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/546Renovate CI2022-09-14T14:27:40+02:00Simon SpannagelRenovate CIThis updates the CI a bit here and there and adds some new features:
* Merge request linting is only done on the `diff` between the new branch and `master`. This dramatically increases speed
* Full-code linting is still done in the nigh...This updates the CI a bit here and there and adds some new features:
* Merge request linting is only done on the `diff` between the new branch and `master`. This dramatically increases speed
* Full-code linting is still done in the nightlies pipeline on `master`
* A new target `lint-cmake` is format-checking and linting our CMake code (yes, sad this is even necessary...)
Enjoy.Simon SpannagelSimon Spannagelhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/542Introduce Possibility for Time-dependent Alignment2023-06-23T13:39:57+02:00Simon SpannagelIntroduce Possibility for Time-dependent Alignment# A long time ago in a galaxy far, far away...
Sometimes you had this beautiful testbeam campaign where everything is working perfectly and you have day-long runs without any hickup in your DAQ. You do wild parameter scans, remotely per...# A long time ago in a galaxy far, far away...
Sometimes you had this beautiful testbeam campaign where everything is working perfectly and you have day-long runs without any hickup in your DAQ. You do wild parameter scans, remotely performing quasi-online DQM with Corry while sitting on a beach in southern Italy. The full-reco monitoring confirms that your data is nicely correlated and your DUT is fully efficient and hevaing as expected.
Then testbeam is over and you start looking into more detail into your 12h-long runs...and find some odd effects (as always).
The mean of the residual (i.e. the position fo your detector) changes over time! :scream:
![image](/uploads/09c9a377775c5d4e8e7d406e434f0eea/image.png)
(image credit @ffeindt)
Oh dear! :deer: But you have a clever idea and go back to the environmental data logged over the full beam time, and voila, nicel correlation with the ambiant temperature:
![image](/uploads/1d45c1c89a8724b8fd9e5aca893c86d8/image.png)
(image credit @pschutze via DESY-II testbeam weather stations)
So far, so good - but how to analyze the data? Chopping them into many small runs seems odd, especially since they will have to be re-aligned individually with relatively low statistics.
Therefore, here the alternative:
# Time-Dependent Alignment Constants
With this MR, Corryvreckan gains the possibility of using time-dependent alignment constants. The basic idea of using this feature is the following:
* Take a run and perform an alignment on it. If this is a dedicated alignment run, perfect. If it is your actual data run, take a small portion of the events at the beginning, with a timescale on which you don't expect any (or only little) drift.
* Produce a new geometry file with this good alignment constants, and analyze the full run
* Observe the shift of your residuals in `x` and `y` over the full length of the run
* Perform a fit of some crazy function to it (like, a ninth order polynomial for instance)
* Go back to your geometry, and instead of (omitting some parameters...)
```ini
[MyDUT]
orientation = 11.0177deg,186.747deg,-1.07865deg
orientation_mode = "xyz"
position = -0.251129,0.408979,21.5
```
you now write:
```ini
[MyDUT]
orientation = 11.0177deg,186.747deg,-1.07865deg
orientation_mode = "xyz"
position = -0.1*x*x+0.0008*x-sin(0.007*x), 0.408979 + 0.00001*x, 21.5
alignment_update_granularity = 10s
```
into your geometry file.
# How it works
Corryvreckan will take the expression you provide in this case as the `x` position of your DUT and transform it into a `TFormula`. From this formula, the alignment constants (positions and resulting transformation matrices) are calculated. **The `x` in the formula represents TIME and is provided in nanoseconds**. This means, at the beginning of the run the formulae are evaluated and the initial position is calculated by setting the time to zero, i.e. `x = 0`.
Each time, the time of your run is incremented, the alignment constants are re-evaluated from these formulae using the current time. In order to not doing this for every single event, the `alignment_update_granularity` parameter can be used to limit this to e.g. every 10 seconds at most.
All numbers in these formulae have to be provided **in framework-internal units**, meaning e.g. in `mm` and `ns`. Since this is a bit cumbersome in some cases, especially when operating with longer timescales and smaller distances, there is the option of providing parameters separately which **can and should** use explicit units, e.g. the above example could then become:
```ini
position = [0]*x*x+[1]*x-sin([2]*x), [3] + [4]*x, [5]
position_parameters = -100um, 0.8um, 0.007, 408.979um, 0.01um, 21.5mm
alignment_update_granularity = 10s
```
These arguments are parsed, converted to internal units and placed in the formula in the respective order.
# Caveats & Prospects
* This code is still untested on *real* data, but @asimanca is at it already. :tada:
* If you use time-dependent alignment and then run the alignment procedure on the data, expect funny results. :smile:
* @pschutze was not very happy with the `TFormula` approach and suggested using a matrix with time ranges and shifts. Also a nice option, I am open to receiving merge requests :m:Simon SpannagelSimon Spannagelhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/515Parallelize Alignment2022-06-03T12:47:29+02:00Simon SpannagelParallelize AlignmentIntroduce thread pool to parallelize alignment.
To do:
* [x] Move thread pool interface to module, to be used via that
* [x] Include DUT alignment moduleIntroduce thread pool to parallelize alignment.
To do:
* [x] Move thread pool interface to module, to be used via that
* [x] Include DUT alignment modulehttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/489EventLoaderEUDAQ2: Read Subevents of StandardEvent2021-12-20T15:28:43+01:00Simon SpannagelEventLoaderEUDAQ2: Read Subevents of StandardEventWith this MR, we introduce a second FIFO cache of events read from the file. This allows to not only keep a buffer of undecoded `eudaq::RawEvent` objects around for successive decoding, but also another buffer of `eudaq::StandardEvent` t...With this MR, we introduce a second FIFO cache of events read from the file. This allows to not only keep a buffer of undecoded `eudaq::RawEvent` objects around for successive decoding, but also another buffer of `eudaq::StandardEvent` that have already been decoded.
This allows to easily treat data where a large blob of data has to be processed by the EUDAQ2 event decoder before it can be split up into subevents. Our use case is a data blob coming from a segmented acquisition of an oscilloscope. Eveny waveform corresponds to one event, but they are stored as one large chunk of data from the full segment acquisition. Now the EUDAQ2 decoder for this data type can disentangle all segments/waveforms and create separate (fully decoded) subevents for them and ship it to Corry.
@ffeindthttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/478New DetectorRole: PASSIVE2021-12-07T15:23:27+01:00Simon SpannagelNew DetectorRole: PASSIVEDetectors marked with
```ini
role = "passive"
```
will not get DetectorModule instances and hence no data will be loaded for them. They can, however, contribute with their material budget to scattering and therefore are added as planes...Detectors marked with
```ini
role = "passive"
```
will not get DetectorModule instances and hence no data will be loaded for them. They can, however, contribute with their material budget to scattering and therefore are added as planes to track candidates.
This MR also cleans up some `Module` methods and adds const'ness where const'ness belowngs. New access methods `get_regular_detectors()` and `num_regular_detectors()` help reducing the individual checks on detector roles everywhere.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/439Configuration: Warn about unused keys2021-09-27T07:39:02+02:00Simon SpannagelConfiguration: Warn about unused keysallows to spot typos more easily. Modeled after https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/475
Needs some testing still. :)allows to spot typos more easily. Modeled after https://gitlab.cern.ch/allpix-squared/allpix-squared/-/merge_requests/475
Needs some testing still. :)Lennart HuthLennart Huthhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/316Module for analysing the Material Budget of a scatterer2020-05-14T10:08:08+02:00Paul Jean SchutzeModule for analysing the Material Budget of a scattererThis new module `AnalysisMaterialBudget` aims to analyse the position-dependent kink angle of tracks at a scatterer, creating kink angle distributions and a _Material Budget Image_ with variable sizes of the image cells or the image itse...This new module `AnalysisMaterialBudget` aims to analyse the position-dependent kink angle of tracks at a scatterer, creating kink angle distributions and a _Material Budget Image_ with variable sizes of the image cells or the image itself.
The Material Budget Images show the width of the kink angle distribution of all particles traversing a given image cell. At this point, no attempt is made to translate this width into the actual material budget (x/X0), given the fact that the absolute values strongly depend on the detector setup and the detector resolution and include scattering in air and neighbouring detectors. For this, a calibration would be required for every individual setup.
Currently, this only works when using tracks of the type `Multiplet`, since it is the only track model allowing for kinks at a position without detector. In the future, it could possibly be extended to support GBL tracks, evaluating the kink angles at a certain detector plane.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/300Online monitor standard plots2020-04-30T11:30:15+02:00Paul Jean SchutzeOnline monitor standard plotsWith this minor change, the user can define, for which tracking/clustering module he'd like to display the standard plots.
We should keep in mind, that for now this is rather simple. In case of including the `TrackingMultiplet` ( !273 )...With this minor change, the user can define, for which tracking/clustering module he'd like to display the standard plots.
We should keep in mind, that for now this is rather simple. In case of including the `TrackingMultiplet` ( !273 ) this would probably mean, that an additional set of default plots would be defined, like ...
```c++
if(tracking_module == "TrackingMultiplet") {
m_config.setDefaultMatrix("tracking", ...);
}
```https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/273Add new module: TrackingMultiplet2020-05-13T10:01:57+02:00Paul Jean SchutzeAdd new module: TrackingMultipletThis MR adds a new module, `TrackingMultiplet` and a corresponding `Track` object `Multiplet`.
A multiplet track consists of two `StraightLineTrack`s, one up- and one downstream, that can be matched at the position of a scatterer. Hen...This MR adds a new module, `TrackingMultiplet` and a corresponding `Track` object `Multiplet`.
A multiplet track consists of two `StraightLineTrack`s, one up- and one downstream, that can be matched at the position of a scatterer. Hence, for the tracking, first a track finding for the two _tracklets_ is performed, then a matching of these two.
For the tracklet finding, the first and the last detector in the lists of up- and downstream detectors are used as references. Every combination of clusters in the two reference detectors is a track candidate, and clusters are added along this track if the spatial and the time range (config parameters) matches.
The candidate is discarded when the number of clusters is too low or another tracklet is found within an isolation range (config parameter) at the position to the scatterer.
For the matching, every upstream tracklet is checked for matching downstream tracklets. The closest match, if within the matching cut (config parameter), wins.
Along the way, the only change closer to the core is another getter function for `KDTree` objects, where one can now get the full `ClusterVector`.
Things you could probably help me with:
* [x] Is the time matching for the tracking handled appropriately?
* [x] Should there be a time matching between up- & downstream tracklets? If yes, how?
* [x] There's currently a lot of different spatial cuts. Should/could this be simplified?
Edit:
Some more things to check before being ready to merge:
* [x] Check on a more performant iteration over detectors suggested by @simonspa
* [x] Add module test
* [x] Check for memory leaks (duh)https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/194Add graph correlation vs time2019-11-08T09:30:23+01:00Paul Jean SchutzeAdd graph correlation vs timeTitle says it all. Well ok, it's actually correlation vs event number. Goes into the TestAlgorithm. Nice to have or not interesting?Title says it all. Well ok, it's actually correlation vs event number. Goes into the TestAlgorithm. Nice to have or not interesting?https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/94Fixing pixel tolerance cut in hasIntercept function of detector class2019-03-14T11:10:03+01:00Morag WilliamsFixing pixel tolerance cut in hasIntercept function of detector classThe function "hasIntercept()" in Detector.cpp applied a pixel tolerance cut, which is an input parameter to the function. However, this cut was applied asymmetrically such that an extra row and column were excluded on one side compared t...The function "hasIntercept()" in Detector.cpp applied a pixel tolerance cut, which is an input parameter to the function. However, this cut was applied asymmetrically such that an extra row and column were excluded on one side compared to the other.
I have changed the cut formula so it is applied equally and applies the input value (rather than the input value minus half a pixel pitch as before). To account for this I adapted the inputted pixel tolerance values used in hasIntercept() in AnalysisDUT and AnalysisEfficiency, which are the only places I found that use this function. Note the getIntercept() function was not affected.
I also added an extra plot in AnalysisDUT showing the local position of associated tracks.