Corryvreckan issueshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues2024-01-31T07:04:20+01:00https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/93Alignment4D2024-01-31T07:04:20+01:00Jens KroegerAlignment4DAt the BTTB8, the question came up whether we also support a 4D alignment, i.e. finding the correct time_shift to move the time residuals to zero.
This is currently not implemented. I'm just opening the ticket as a reminder/place for di...At the BTTB8, the question came up whether we also support a 4D alignment, i.e. finding the correct time_shift to move the time residuals to zero.
This is currently not implemented. I'm just opening the ticket as a reminder/place for discussion.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/87CI-Testing: Allow multiple #PASS conditions2023-11-24T10:51:20+01:00Jens KroegerCI-Testing: Allow multiple #PASS conditionsAfter a discussion with @simonspa we concluded:
It would be a really powerful improvement to allow for multiple #PASS conditions in the CI automated testing.
This could be done as follows:
Instead defining the ctest as running corry an...After a discussion with @simonspa we concluded:
It would be a really powerful improvement to allow for multiple #PASS conditions in the CI automated testing.
This could be done as follows:
Instead defining the ctest as running corry and parsing the terminal output for the pass condition, the terminal output could be written to a log file and then parsed multiple times for different conditions.
Currently, the whole analysis needs to be re-run as a separate test for a different pass condition.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/101Follow up on !269 : Possible Improvements in Tracking4D2022-07-07T11:11:44+02:00Jens KroegerFollow up on !269 : Possible Improvements in Tracking4DThis ticket is a reminder on the open discussion in
https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/269#note_3351466
******
> Just a question that came up in the silicon discussion today:
Currently, the first and las...This ticket is a reminder on the open discussion in
https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/269#note_3351466
******
> Just a question that came up in the silicon discussion today:
Currently, the first and last planes of the telescope are taken as the initial reference planes if I understand correctly. Is this always a suitable approach?
What if the last plane has a (significantly) worse spatial resolution than the second to last?
> Let's maybe approach this in a two-step model: we agree that this MR is a major improvement over what is currently available and merge it. And after that we think about all possible corner cases for odd set-ups and maybe introduce new features.
What do you think?2.0https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/160Auto-Extend X Axes2022-06-07T14:32:09+02:00Simon SpannagelAuto-Extend X AxesIdentify relevant histograms and configure them to auto-extend their x-axes (e.g. *F() vs t* or *F() vs n_event*.
@pschutze could you do this or at least drop the code here that's necessary? Thanks!Identify relevant histograms and configure them to auto-extend their x-axes (e.g. *F() vs t* or *F() vs n_event*.
@pschutze could you do this or at least drop the code here that's necessary? Thanks!Paul Jean SchutzePaul Jean Schutzehttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/149Moving on to c++172021-11-12T14:14:26+01:00Lennart HuthMoving on to c++17Within !444 we started discussing moving to c++17.
I would in general be in favour of updating the requirements. Are there any remarks from anyone?Within !444 we started discussing moving to c++17.
I would in general be in favour of updating the requirements. Are there any remarks from anyone?https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/137environment variables in config files2021-02-08T16:12:09+01:00Carsten Burgardcburgard@cern.chenvironment variables in config filesIt would be great if a feature could be added to the config reader that would allow to make use of environment variables in config files, such that e.g. `$PWD` could be used to easily switch between different setups.It would be great if a feature could be added to the config reader that would allow to make use of environment variables in config files, such that e.g. `$PWD` could be used to easily switch between different setups.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/138keyboard escape handling2021-02-03T13:36:21+01:00Carsten Burgardcburgard@cern.chkeyboard escape handlingCurrently, `corry` is not very lenient towards `CTRL+C` or `CTRL+Z` when run on a terminal. It would be nice if these keyboard breaks could be respected more thoroughly.Currently, `corry` is not very lenient towards `CTRL+C` or `CTRL+Z` when run on a terminal. It would be nice if these keyboard breaks could be respected more thoroughly.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/65Use fit instead of RMS for prealignment2020-03-20T16:11:51+01:00Katharina DortUse fit instead of RMS for prealignmentCurrently, the Prealignment module uses the RMS to adjust the telescope planes such that the correlation peak is located around 0. In case of a skewed background this can cause problems since the location of the peak cannot be determined...Currently, the Prealignment module uses the RMS to adjust the telescope planes such that the correlation peak is located around 0. In case of a skewed background this can cause problems since the location of the peak cannot be determined easily from the RMS.
Suggestion: Find the max. value of the histogram and perform a (Gaussian?) fit around it to obtain the peak position. Alternatively, a proper peak finding algorithm can be implemented.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/30Resolutions to detector file2019-11-11T11:04:17+01:00Simon SpannagelResolutions to detector fileAdd resolutions to detector file:
* intrinsic position resolution to calculate hit uncertainty (see Timepix3Clustering)
* time resolution to select search window individually for each detector
Document in manualAdd resolutions to detector file:
* intrinsic position resolution to calculate hit uncertainty (see Timepix3Clustering)
* time resolution to select search window individually for each detector
Document in manualhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/76Allow Data Duplication2019-10-29T13:40:51+01:00Simon SpannagelAllow Data DuplicationWe should allow for data which are not from the event-defining detector to be duplicated.
Imagine the (very real) situation in which we have a very short frame with a high rate produced by the DUT to define out event. Now we would like ...We should allow for data which are not from the event-defining detector to be duplicated.
Imagine the (very real) situation in which we have a very short frame with a high rate produced by the DUT to define out event. Now we would like to add M26 data to it with its very long frame length. This works fine for the first event, but the subsequent DUT frames will not have any data assigned to them because the M26 reader already went to the next frame and evaluates this as position `AFTER`.
If we retain the event even if classified as `DURING` and re-evaluate the next time, in the case above it would again return `DURING` and we would re-assign it.
In the more "normal" case where we really moved on, we will simply evaluate it as `BEFORE` and move on to the next event.
Is there a flaw in this logic or does this make sense?https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/60EventloaderEUDAQ2 can only handle triggerIDsync data2019-09-12T15:05:14+02:00Lennart HuthEventloaderEUDAQ2 can only handle triggerIDsync dataThe current implementation of the converter can only handle TLU/NI events sorted by triggerID. For eventID synched data, the first plane read in is always skipped.The current implementation of the converter can only handle TLU/NI events sorted by triggerID. For eventID synched data, the first plane read in is always skipped.Jens KroegerJens Kroegerhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/46Unify Configuration Keys?2018-12-20T15:19:10+01:00Simon SpannagelUnify Configuration Keys?Since we are getting closer and closer to
* the tutorial to be held at BTTB
* version 1.0
I think it would be worth considering a unification and renaming of all configuration keys of all modules, e.g. `inputDirectory` -> `input_direct...Since we are getting closer and closer to
* the tutorial to be held at BTTB
* version 1.0
I think it would be worth considering a unification and renaming of all configuration keys of all modules, e.g. `inputDirectory` -> `input_directory` etc.
Opinions?https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/17Data handling: Implement output_directory2018-12-19T11:01:49+01:00Simon SpannagelData handling: Implement output_directoryImplement global framework parameter `output_directory` to allow specification of the output directory, just as done in Allpix Squared.
Relevant code:
https://gitlab.cern.ch/allpix-squared/allpix-squared/blob/master/src/core/Allpix.cpp#...Implement global framework parameter `output_directory` to allow specification of the output directory, just as done in Allpix Squared.
Relevant code:
https://gitlab.cern.ch/allpix-squared/allpix-squared/blob/master/src/core/Allpix.cpp#L151
Make sure all algorithms which write files obey folder. Probably best to implement something in the base class similar to Allpix Squared's `createOutputFile()`:
https://gitlab.cern.ch/allpix-squared/allpix-squared/blob/master/src/core/module/Module.cpp#L71https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/41OnlineMonitor: Show multiple DUTs2018-12-19T10:53:48+01:00Simon SpannagelOnlineMonitor: Show multiple DUTsThe OnlineMonitor should open one tab per DUT instead of one called "DUTPlots". The name of the tab should correspond to the name of the respective DUT detectorThe OnlineMonitor should open one tab per DUT instead of one called "DUTPlots". The name of the tab should correspond to the name of the respective DUT detectorSimon SpannagelSimon Spannagelhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/40Add Test Cases and a CI Testing Stage2018-12-12T10:07:22+01:00Simon SpannagelAdd Test Cases and a CI Testing StageFor every detector/DUT supported, we should add one test case with abbreviated data files, placed on the newly created EOS project space to be found at `/eos/project/c/corryvreckan/`. A script should be able to download these files and e...For every detector/DUT supported, we should add one test case with abbreviated data files, placed on the newly created EOS project space to be found at `/eos/project/c/corryvreckan/`. A script should be able to download these files and execute the framework with the corresponding configuration files.
The output checked should e.g. be the number of tracks found.
This way we can monitor that new additions or changes do not break compatibility with our existing setups and data sets.Simon SpannagelSimon Spannagelhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/37Provide CMVFS Installation2018-11-13T15:25:36+01:00Morag WilliamsProvide CMVFS InstallationProvide central CMVFS installation for SLC6 and CC7Provide central CMVFS installation for SLC6 and CC7https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/22Allow for multiple DUTs2018-11-08T16:44:30+01:00Simon SpannagelAllow for multiple DUTshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/33Ability not to set `DUT` parameter2018-11-08T16:43:56+01:00Morag WilliamsAbility not to set `DUT` parameterAbility to run without `DUT` set (sort of telescope-only mode). Need to see which modules require the DUT to exist.Ability to run without `DUT` set (sort of telescope-only mode). Need to see which modules require the DUT to exist.Morag WilliamsMorag Williams