Corryvreckan merge requestshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests2023-11-28T11:40:49+01:00https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/664OnlineMonitor: Resolving Issues with Threading2023-11-28T11:40:49+01:00Simon SpannagelOnlineMonitor: Resolving Issues with ThreadingThis MR contains some fixups to !650 since @pschutze and me experienced issues with some modules when attempting do online monitoring, manifesting itself in seemingly random crashes deep within different parts of ROOT, changing whenever ...This MR contains some fixups to !650 since @pschutze and me experienced issues with some modules when attempting do online monitoring, manifesting itself in seemingly random crashes deep within different parts of ROOT, changing whenever restarting.
This was traced back to be a threading issue, so this MR implements the following changes:
* The `TApplication` is created on the main thread - this removes the random crashes but leaves the spawned thread with an empty ROOT directory
* Passing the `gDirectory` ti the spawned GUI thread and `cd()`ing into it explicitly restores access to the histograms
* The `gui_running` is now a `std::atomic<bool>` to be thread-safe
* An additional `gui_ready` atomic bool blocks the main thread `initialize()` method until the GUI has been properly initialized. This removes possible race conditions between histogram creating/filling in other modules and the booking and access thereof from the GUI thread.
@aloeschc would you be so kind to look at this and test this since it touches your work?https://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/676Update copyright year2024-02-01T15:59:45+01:00Simon SpannagelUpdate copyright yearhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/674Fix detector size2024-03-20T17:02:34+01:00Lennart HuthFix detector sizeWe only give the Detetcor::size() in local. This MR changes it to global and local dimensions.We only give the Detetcor::size() in local. This MR changes it to global and local dimensions.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/666Transformation of Errors in Radial Detectors + Radial Clustering2023-12-20T14:16:25+01:00Maximilian CasparTransformation of Errors in Radial Detectors + Radial ClusteringError Transformation:
Make sure the detector resolution transforms correctly from radial to cartesian coordinates. This is achieved using gaussian error transformation.
Symbolic derivation of the derivatives used in the error transformat...Error Transformation:
Make sure the detector resolution transforms correctly from radial to cartesian coordinates. This is achieved using gaussian error transformation.
Symbolic derivation of the derivatives used in the error transformation: [Resolution.md](/uploads/10ca696d94a0c7f939373e2dd7dfa9dc/Resolution.md)
ToDo: Test this with the Allpix^2 implementation of the geometry (as in IT-4086/EP/ATLAS) that Radek is working on.
Radial Clustering: Introduce a new module (ClusteringRadial) that uses the radial clustering concept and gives cluster statistics not only in x/y but also in R/Phi. The clustering algorithm is the same as in ClusteringSpatial, but everything is handled in radial coordinates, and the cluster centre is found using a weighted average that considers individual strip resolutions.
ToDo: Look at the output of the histograms in a few scenarios to judge whether the bounds are correct.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/649Draft: Evaluate spatial cuts and residuals based on detector model2023-11-08T17:54:59+01:00Radek PrivaraDraft: Evaluate spatial cuts and residuals based on detector modelThis MR comes as a follow-up from the discussions in MR !644.
It attemps to solve the complication in `DUTAssociation` and `AlignmentDUTResiduals` modules, where in the case of detector models not natively using cartesian coordinates (e...This MR comes as a follow-up from the discussions in MR !644.
It attemps to solve the complication in `DUTAssociation` and `AlignmentDUTResiduals` modules, where in the case of detector models not natively using cartesian coordinates (e.g. radial detectors use polar coordinates) detector model has to be checked and recalculations are necessary to properly evaluate spatial cuts or residuals in the correct coordinate system. (No such detector model is currently a part of the `master` branch and only exist in WIP branches.)
The proposed solution is to evaluate spatial cuts and residuals in "native coordinates" (name is subject to change if something else would be preferred) which are defined via two `Detector` (pure virtual) member functions
- `Detector::getNativePosition(localPosition)`
- `Detector::getNativePosition(column, row)`
For pixel detectors (including hexagonal detectors), the native coordinates are identical to local cartesian coordinates, and so these two functions simply call their respective `getLocalPosition()` functions, seemingly only adding unnecessary function calls. For detector models using other coordinate systems, however, the local cartesian coordinates can be transformed to a desired system via the `getNativePosition()` functions and therefore ensure proper handling of spatial cuts and residuals.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/613Draft: Improve handling of timing references2023-03-06T13:31:44+01:00Eric BuschmannDraft: Improve handling of timing referencesThis MR updates the `EventLoaderTimestamp` module to treat devices connected to the TDC input of a SPIDR board as a physical (1x1 pixel) detector and treat timestamps as hits in this detector.
We plan to then use this as an auxiliary det...This MR updates the `EventLoaderTimestamp` module to treat devices connected to the TDC input of a SPIDR board as a physical (1x1 pixel) detector and treat timestamps as hits in this detector.
We plan to then use this as an auxiliary detector to improve track timestamps (similar to the `ImproveReferenceTimestamp` module, but more generic).https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/600Update FASTPIX Event Loader and Analysis2023-09-07T10:14:55+02:00Justus BraachUpdate FASTPIX Event Loader and Analysishttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/569Bent sensors2023-03-05T14:58:24+01:00Mihail Bogdan BlidaruBent sensorsThese changes allow the analysis of bent sensors. This is possible using coordinate transformations between the flat state and an ideal cylindrical geometry.
To help visualise changes in this new coordinate system, helper histograms are...These changes allow the analysis of bent sensors. This is possible using coordinate transformations between the flat state and an ideal cylindrical geometry.
To help visualise changes in this new coordinate system, helper histograms are added in `AnalysisDUT`.
Finally, a new subchapter is added to the manual detailing how to use such a curved geometry.
Note: https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/463 can be disregarded. Comments received there should have been implemented in this version.
Note2: Example of raw data, analyzed root files (GBL, straightline), geometry, configs : https://cernbox.cern.ch/s/YBMgGVfbIRUmaBohttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/530Draft: Add magnetic fields and curved tracks2022-12-01T15:06:33+01:00David BacherDraft: Add magnetic fields and curved tracksTrack models that include curvature are needed for the correct reconstruction of testbeam data with a magnetic field.
I added a completely new track model `HelixTrack` which fits a helix to the measurement points, similar to the `Straigh...Track models that include curvature are needed for the correct reconstruction of testbeam data with a magnetic field.
I added a completely new track model `HelixTrack` which fits a helix to the measurement points, similar to the `StraightLineTrack` without magnetic field. The `HelixTrack` is able to perform a straightline fit if no magnetic field is given, such that this new model could also fully replace the `StraightLineTrack` model.
Additionally I implemented the curvature from the magnetic field to the `GblTrack` model.
TO DO:
- [x] Implement user definable magnetic field parameter
- [x] Add `HelixTrack` model
- [x] Add curvature to `GblTrack` model
- [ ] Add correct measurement error handling to helix fit
- [ ] Add documentation
If the `HelixTrack` model should replace the `StraightLineTrack` model, also the other models and modules need to be checked and adapted (e.g. `Multiplet`).
I tested the current implmentation with some very basic tests using simulated data with 250 GeV protons and a 3T magnetic field along the x-axis. So far `HelixTrack` and `GblTrack` give very compatible results. More thorough test still need to be done (magnetic field orientations, alignment, etc.). Help is very welcome for this :)
Cheers, Davidhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/472added python executable2021-12-16T16:16:38+01:00Carsten Burgardcburgard@cern.chadded python executableAdded a python executable that makes use of the new features.Added a python executable that makes use of the new features.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/470preparing everything for python binary2022-03-02T15:35:24+01:00Carsten Burgardcburgard@cern.chpreparing everything for python binaryrefactoring corry to create dictionaries for python bindings of some core classesrefactoring corry to create dictionaries for python bindings of some core classeshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/457WIP: New Analysis Plugin for ItkStrip detectors2021-09-15T12:36:26+02:00Jens DopkeWIP: New Analysis Plugin for ItkStrip detectorsPlugin to allow specific analysis of Itk Strip detectors, needing a time of arrival read from a separate deviceID in the eudaq input stream. Can't CI-check the compilation as needs eudaq :-(Plugin to allow specific analysis of Itk Strip detectors, needing a time of arrival read from a separate deviceID in the eudaq input stream. Can't CI-check the compilation as needs eudaq :-(