Corryvreckan issueshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues2019-10-29T13:40:51+01:00https://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/61Multiple track reconstructions modules with different pixel ranges2019-09-19T10:30:22+02:00Lennart HuthMultiple track reconstructions modules with different pixel rangesI am wondering how to implement an analysis flow like presented here (slide 15):
https://indico.cern.ch/event/731649/contributions/3237289/attachments/1778200/2891938/BTTB_Corryvreckan_tutorial_final.pdf
My idea is to read in data, perf...I am wondering how to implement an analysis flow like presented here (slide 15):
https://indico.cern.ch/event/731649/contributions/3237289/attachments/1778200/2891938/BTTB_Corryvreckan_tutorial_final.pdf
My idea is to read in data, perform clustering and then use each layer as DUT, asking for a track fit without the dut.
Is this possible? It would significantly reduce the computation time in our case, as most time is spent reading in the data.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/42Clipboard/Objects: Don't use Vector of Pointer2020-05-07T16:11:21+02:00Simon SpannagelClipboard/Objects: Don't use Vector of PointerI would like to rework the data objects and the clipboard to not use `std::vector<Object*>*` but rather just `std::shared_ptr<std::vector<Object>>` which is what is needed for not moving/copying memory around.
This is a bit involved sin...I would like to rework the data objects and the clipboard to not use `std::vector<Object*>*` but rather just `std::shared_ptr<std::vector<Object>>` which is what is needed for not moving/copying memory around.
This is a bit involved since objects store references to each other, which should be pointers, obviously. Postponing this work.https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/10Add GBL algorithm2020-01-17T18:55:59+01:00Simon SpannagelAdd GBL algorithmImplement a GBL track-refit algorithm for Corry. Mostly in view of potential test beams at PS next year and at DESY during LS2.
Requires track candidates as input, either take full `BasicTracking` tracks and simply do the re-fit, or spl...Implement a GBL track-refit algorithm for Corry. Mostly in view of potential test beams at PS next year and at DESY during LS2.
Requires track candidates as input, either take full `BasicTracking` tracks and simply do the re-fit, or split track finding and fitting in BasicTracking and then only use the track finder (probably overkill).
Also opens door to implementing alignment with GBL, where we simply need to write out the GBL tracks to binary and run `pede` on them.Simon SpannagelSimon Spannagel