Corryvreckan issueshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues2022-07-07T11:11:44+02:00https://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/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?