Corryvreckan issueshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues2020-05-18T15:23:30+02:00https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/91Follow-up from "Add GeneralBrokenLines as new Track Model"2020-05-18T15:23:30+02:00Simon SpannagelFollow-up from "Add GeneralBrokenLines as new Track Model"The following discussions from !230 should be addressed:
- [ ] @simonspa started a [discussion](https://gitlab.cern.ch/corryvreckan/corryvreckan/merge_requests/230#note_3094274): (+2 comments)
> Okay, this we discussed and should ...The following discussions from !230 should be addressed:
- [ ] @simonspa started a [discussion](https://gitlab.cern.ch/corryvreckan/corryvreckan/merge_requests/230#note_3094274): (+2 comments)
> Okay, this we discussed and should certainly resolve. Question is whether this should be part of this MR or come later.
- [ ] @simonspa started a [discussion](https://gitlab.cern.ch/corryvreckan/corryvreckan/merge_requests/230#note_3094319):
> Picking this up once more - we agreed that the way the patter recognition is done here could be improved in future tracking modules but that we need the `refTrack` here. Let's maybe add a few lines of code comment to explain the reason so we remember this in a few months form now?
- [ ] @simonspa started a [discussion](https://gitlab.cern.ch/corryvreckan/corryvreckan/merge_requests/230#note_3094330): (+1 comment)
> That's not really nice but I of course understand why it's there. Is there a way we can make these plots more generic so they would make sense for both models? In principle they are superseded by the kink histograms, no?
- [x] @simonspa started a [discussion](https://gitlab.cern.ch/corryvreckan/corryvreckan/merge_requests/230#note_3094504): (+1 comment)
> Do we need this when we have a copy constructor?
The following discussion from !243 should be addressed:
- [x] @jekroege started a [discussion](https://gitlab.cern.ch/corryvreckan/corryvreckan/merge_requests/243#note_3122290): (+3 comments)
> Maybe we should keep this as a `LOG(TRACE)`?2.0Lennart HuthLennart Huthhttps://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/104Follow-up from "Add new module: TrackingMultiplet": Add GBL compatibility2020-08-27T10:55:03+02:00Paul Jean SchutzeFollow-up from "Add new module: TrackingMultiplet": Add GBL compatibilityThe following discussion from !273 should be addressed:
- [ ] @simonspa started a [discussion](https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/273#note_3329601): (+7 comments)
> Sorry, it's three in the end.
...The following discussion from !273 should be addressed:
- [ ] @simonspa started a [discussion](https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/273#note_3329601): (+7 comments)
> Sorry, it's three in the end.
>
> Currently your module only allows to create `Mutliplet` tracks. In principle there is nothing that is against also allowing other tracks to be formed based on the track candidates you find - or am I mistaken?
In its current implementation, `TrackingMultiplet` only supports the `TrackModel` `Multiplet`. With some changes it should be possible and would be worth extending this with a `GblTrack` compatibility, utilizing the known material budget of e.g. the `DUT` or parsing the material budget via the configuration. As a first step, this applies to known scatterers only, such as e.g. present in Telescope+DUT studies. Unknown scatterers are somewhat more tricky and to my knowledge require more changes in the `GblTrack` implementation.2.0Simon SpannagelPaul Jean SchutzeLennart HuthSimon Spannagelhttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/110Move checks in getIntercept to track2020-05-18T08:57:10+02:00Simon SpannagelMove checks in getIntercept to trackSince tracks now know more about the geometry, we should move the checks done in
```cpp
PositionVector3D<Cartesian3D<double>> PixelDetector::getIntercept(const Track* track) const;
```
to the tracks themselves I guess.Since tracks now know more about the geometry, we should move the checks done in
```cpp
PositionVector3D<Cartesian3D<double>> PixelDetector::getIntercept(const Track* track) const;
```
to the tracks themselves I guess.2.0https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/114Follow-up on !310: add CI test for AlignmentMillepede2020-05-18T08:57:09+02:00Jens KroegerFollow-up on !310: add CI test for AlignmentMillepedeWhile preparing !310, I was not able to get `AlignmentMillepede` to converge, neither on the inital alignment used for the other CI alignment test nor on the final alignment of the latter.
Keep in mind and investigate later.While preparing !310, I was not able to get `AlignmentMillepede` to converge, neither on the inital alignment used for the other CI alignment test nor on the final alignment of the latter.
Keep in mind and investigate later.2.0