Corryvreckan merge requestshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests2024-01-24T17:53:11+01:00https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/677Revert "Itk strip EC efficiency"2024-01-24T17:53:11+01:00Yajun HeRevert "Itk strip EC efficiency"This reverts commit de2e091ee3f8ba4c6c119312f667859911bd34c4This reverts commit de2e091ee3f8ba4c6c119312f667859911bd34c4https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/645Draft: Introduce SensorDesign Class2023-10-26T13:09:24+02:00Yajun HeDraft: Introduce SensorDesign Class(Everything is on behalf of Nigel Hessy)
Merge request to initiate discussion on improving the adaptability of Corryvreckan for new sensor designs by separating out the parts of a Detector Class into a new "SensorDesign" class. So the c...(Everything is on behalf of Nigel Hessy)
Merge request to initiate discussion on improving the adaptability of Corryvreckan for new sensor designs by separating out the parts of a Detector Class into a new "SensorDesign" class. So the current Detector class which "is" a design would get a pointer to a SensorDesign which would do everything that is internal to a sensor.
Then people with any new sensor with whatever arrangement of diodes can implement their design, without altering the Detector class. Detector class becomes smaller and rather unchanging: it knows the position, orientation, transform local->global and vv, as well as Dector Type (DUT, ...)
Current idea is to have a base SensorDesign class with virtual methods to convert diode indices to position and vice versa. RectangularSensor would inherit from this and implement the most common form of sensors (Timepix, Medipix, Alpide, Mimosa26, ...; HexagonalDesign; and an ATLAS Endcap Strip sensor would be a StereoAnnulusDesign.
In a Mimosa telescope, there would be one design: RectangularDesign mimosa26Design(...); with six Detectors all pointing to this same design. A single config section would give the mimosa parameters (pixel size, number of rows and columns mainly). The geometry file would have this information replaced by a string describing what SensorDesign the Detector should point to.
Many other packages have this separation of an actual instance of a detector and the design of those detectors. This change will allow import of at least some of such code, or at least with reduced changes. This split would make Corryvreckan more scalable. This would possibly allow Corryvreckan to be used in ATLAS system tests where we will have hundreds of sensors, but only 8 sensor designs.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/643Draft: EventLoaderEUDAQ2 send wave info to clipboard2023-11-30T12:54:55+01:00Manuel Alejandro Del Rio VieraDraft: EventLoaderEUDAQ2 send wave info to clipboardget_waveform_data based on get_pixel_data to save waveform vectors to the clipboardget_waveform_data based on get_pixel_data to save waveform vectors to the clipboardhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/630jobsub: add posibility to add geometry file2023-08-02T15:10:25+02:00Stephan Lachnitstephan.lachnit@cern.chjobsub: add posibility to add geometry fileThis MR adds the possibility to also specify a geometry file that contains @ variables. We use it e.g. to correct the time offsets instead of writing a new geometry file every time.
Requires !631.This MR adds the possibility to also specify a geometry file that contains @ variables. We use it e.g. to correct the time offsets instead of writing a new geometry file every time.
Requires !631.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/611Update AUTHORS.md2023-03-02T11:28:03+01:00Adriana SimancasUpdate AUTHORS.mdhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/602EventLoaderEUDAQ2: Adding individual optional pixel raw value histograms and ...2023-11-30T11:32:45+01:00Lennart HuthEventLoaderEUDAQ2: Adding individual optional pixel raw value histograms and configurable range* Adding the option to plot the raw values for all individual pixels. Highly biased to apts etc and switched off per default.
* Allow changing the raw value range instead of fixed to 1024, default 1024.* Adding the option to plot the raw values for all individual pixels. Highly biased to apts etc and switched off per default.
* Allow changing the raw value range instead of fixed to 1024, default 1024.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/582WIP: Adding uncertainty matrices of GBL2022-12-06T14:12:18+01:00Lennart HuthWIP: Adding uncertainty matrices of GBLreturning the error matrices for each GBL point. Will solve #175 (hopefully :sweat_smile: )returning the error matrices for each GBL point. Will solve #175 (hopefully :sweat_smile: )https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/581Adding uncertainty of GBL prediction on each plane2022-12-06T13:09:05+01:00Lennart HuthAdding uncertainty of GBL prediction on each planeAs requested by users I've added the position uncertainty for each layer in global and local coordinates.
Ready for review :smile:As requested by users I've added the position uncertainty for each layer in global and local coordinates.
Ready for review :smile:https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/577EtaCalculation: fixes, EtaCorrection: refactor2022-11-25T13:37:15+01:00Peter SvihraEtaCalculation: fixes, EtaCorrection: refactor- get rid of unnecessary detector name in config
- refactored eta correction
- added plot to eta correction- get rid of unnecessary detector name in config
- refactored eta correction
- added plot to eta correctionhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/570Jobsub: Fix Submission Without CSV File2022-11-15T18:10:56+01:00Simon SpannagelJobsub: Fix Submission Without CSV File...which seems broken since !182.
Now the generation of a config file and the execution of the program or submission to the batch scheduler does not depend anymore on the existence of a CSV runlist....which seems broken since !182.
Now the generation of a config file and the execution of the program or submission to the batch scheduler does not depend anymore on the existence of a CSV runlist.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/563Master2022-09-22T11:38:06+02:00Aliakbar EbrahimiMasterAccording to the ROOT reference guide for [RotationZYX](https://root.cern/doc/master/classROOT_1_1Math_1_1RotationZYX.html) and [EulerAngles](https://root.cern/doc/master/classROOT_1_1Math_1_1EulerAngles.html) Rotation3D object in PixelD...According to the ROOT reference guide for [RotationZYX](https://root.cern/doc/master/classROOT_1_1Math_1_1RotationZYX.html) and [EulerAngles](https://root.cern/doc/master/classROOT_1_1Math_1_1EulerAngles.html) Rotation3D object in PixelDetector::initialise() had wrong order of applying rotations around different axis for all three orientation modes.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/556Add Werror flag to cmake for consistency with CI2022-09-14T19:08:58+02:00Miljenko SuljicAdd Werror flag to cmake for consistency with CIIt seems to me that if CI checks the code with `-Werror` flag, it should also be included in cmake.It seems to me that if CI checks the code with `-Werror` flag, it should also be included in cmake.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/541Draft: Fix Uploading of CI Test Results2022-07-12T17:23:06+02:00Simon SpannagelDraft: Fix Uploading of CI Test ResultsSimon SpannagelSimon Spannagelhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/535Draft: Eudaq waveform2022-07-28T10:12:29+02:00Lennart HuthDraft: Eudaq waveformThis is the first draft on a waveform reading from eudaq. Relies on changes in EUDAQ (compare PR 34: https://github.com/simonspa/eudaq/pull/34)
Still WIP....This is the first draft on a waveform reading from eudaq. Relies on changes in EUDAQ (compare PR 34: https://github.com/simonspa/eudaq/pull/34)
Still WIP....Lennart HuthLennart Huthhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/531Draft: StraightLineTrack::getState(detectorID): return position at detector r...2023-01-17T14:49:43+01:00Annika VauthDraft: StraightLineTrack::getState(detectorID): return position at detector rather than at z=0So far, `StraightLineTrack::getState(detectorID)` returned the state at z=0, not the state at the z-pos of the detector for which it was requested. In contradiction to the documentation in the header file, where it's written that this fu...So far, `StraightLineTrack::getState(detectorID)` returned the state at z=0, not the state at the z-pos of the detector for which it was requested. In contradiction to the documentation in the header file, where it's written that this functions returns the "XYZPoint state at detector layer".
This is in contrast to `GblTracks::getState`, which does return the state at the detector z-postion.
The intention behind this merge request is to adapt the same behaviour for StraightLineTrack.
As far as I can tell, this also makes all the position/direction calculations in `PixelDetector::getIntercept(const Track* track)` unnecessary - or am I overlooking something here - line some global/local conversion issue when the plane origin is not at x=0,y=0?
Two more questions that came up while I looked into changing this:
1) GblTrack and Multiplet only return a position for GetState if the track is fitted and has a fitted track point at the detector plane you ask for. Is this behaviour also desired for StraightLineTrack ? I've just implemented it like that for now.
But then the tests fail. E.g. `test_io_write_rootobj.conf`:
> |10:09:44.963| (FATAL) [R:Tracking4D] Fatal internal error
> Track Object StraightLineTrack does not have any entry for detector W0013_E03
> Cannot continue...
2) At some point @simonspa commented that maybe it would be nicer if `getState` wasn't a public method, but rather `getDirection()` and `getIntercept()` should be used by other classes, Thoughts on that?
(currently getState is used by PixelDetector.cpp, AlignmentMillepede.cpp, AnalysisDUT.cpp and AnalysisTracks.cpp)
One difference in replacing those would be that in the current implementation, getIntercept() will always return something, and as stated above `getState` requires the track to have an entry for the detector for which you are calling it; so that "check" would get lost.
Bonus question: I stumbled across a "fixme" in `StraightLineTrack::calculateResiduals()`.
_"cluster->global.z() is only an approximation for the plane intersect. Can be fixed after !115"_. That merge request has been merged 2 years ago, so I guess now would be a nice time to fix the fixme :-)
But I had a look at it and couldn't figure out quite how the changes in !115 impact this function (or is it rather the other way around?).https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/513Draft: Maximum tracks per event cut in Tracking4D2022-02-24T12:19:56+01:00Miljenko SuljicDraft: Maximum tracks per event cut in Tracking4DReject events which contain more than `max_tracks_per_event`.
Please let me know if you like this change and see it as a way to implement it. If so, I will update the documentation accordingly.Reject events which contain more than `max_tracks_per_event`.
Please let me know if you like this change and see it as a way to implement it. If so, I will update the documentation accordingly.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/511Port jobsub.py to Python32022-02-14T11:09:28+01:00Simon SpannagelPort jobsub.py to Python3Needs testing.Needs testing.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/507Detectors: allow passive+aux detectors (passive material essentially)2022-02-11T09:05:06+01:00Simon SpannagelDetectors: allow passive+aux detectors (passive material essentially)@avauth here you go - please check, I'm not sure if this will have unforeseen side effects...
Will also have another look at it with a clearer mind tomorrow. :smile_cat:@avauth here you go - please check, I'm not sure if this will have unforeseen side effects...
Will also have another look at it with a clearer mind tomorrow. :smile_cat:https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/502TrackingMultiplet changes to use it for a DUT2023-02-24T17:26:33+01:00Annika VauthTrackingMultiplet changes to use it for a DUT**Update Feb 24, 2023: closing this, moving on to** !607
-------------------------
Follow-up of the discussion on mattermost:
Some changes to use TrackingMultiplet with a DUT (rather than a scatterer) - e.g. for a use case with a scat...**Update Feb 24, 2023: closing this, moving on to** !607
-------------------------
Follow-up of the discussion on mattermost:
Some changes to use TrackingMultiplet with a DUT (rather than a scatterer) - e.g. for a use case with a scatterer behind the DUT, before the downstream telescope planes.
Contains the following changes:
`TrackingMultiplet`
- gbl refit (Thanks @lhuth !)
- options "require_detectors" and "timestamp_from" (analogous to what exists in Tracking4D)
- update README accordingly
Some more changes necessary to use the Multiplet Tracks for DUT analysis (before, unless the DUT was used for building the Multiplet, DUTAssociation etc would crash with
```
"Fatal internal error
Track Object Multiplet does not have any entry for detector <dut>
Cannot continue..."
```
--> `PixelDetector.cpp / AnalysisDUT / AnalysisTracks`:
- use `getIntercept` instead of `getState` for Multiplet tracks
(getState is done quite differently for Multiplet tracks than for the others, and will fail for the DUT, unless it is used as one of the upstream or downstream detectors)
Not sure if this is the best way to fix this issue, but I also didn't see any obvious less-messy ways to do it differently
Not directly related to the Multiplets, but as I was changing this class anyway for the getState thing...
`AnalysisTracks`:
- why should I not create histos for DUT, if I run this module after DUTassociaton? removed if(d->isDUT())
Few related classes:
- added some debug-level log messages while debugging the changes above
(not directly related to the new functionality, so I could remove them again, if you think there's no future use)https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/483Fix the memory leak related with the TRef objects table (fix #156)2021-12-03T18:04:15+01:00Jordi Duarte CampderrosFix the memory leak related with the TRef objects table (fix #156)This MR fix the memory leak spotted in the issue #156. Please see details there.
I implemented the count/reset mechanism in the `ModuleManager::run` method, but I am not fully sure if there is the proper place (I could be missing someth...This MR fix the memory leak spotted in the issue #156. Please see details there.
I implemented the count/reset mechanism in the `ModuleManager::run` method, but I am not fully sure if there is the proper place (I could be missing something, I'm not an expert on the framework).