Corryvreckan issueshttps://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues2020-05-18T16:48:17+02:00https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/118Follow-up from "GBL with correct treatment of rotations"2020-05-18T16:48:17+02:00Simon SpannagelFollow-up from "GBL with correct treatment of rotations"The following discussion from !254 should be addressed:
- [x] @simonspa started a [discussion](https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/254#note_3443692): (+1 comment)
> Since I really dislike this way of ...The following discussion from !254 should be addressed:
- [x] @simonspa started a [discussion](https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/254#note_3443692): (+1 comment)
> Since I really dislike this way of debug output but there seems to be a need for logging in the track class (which I understand and support), please go ahead and use the central logger for this.2.0https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/117Add Manual Chapter on Objects2021-01-25T18:00:41+01:00Simon SpannagelAdd Manual Chapter on ObjectsWith more and more (and more complex) object types we should add a separate chapter to the user manual explaining their use and behavior. This is especially important for the different Track objects, we can describe the track model and f...With more and more (and more complex) object types we should add a separate chapter to the user manual explaining their use and behavior. This is especially important for the different Track objects, we can describe the track model and fitting routine in detail there.2.0https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/116Follow-up from "GBL with correct treatment of rotations"2020-05-18T16:48:38+02:00Simon SpannagelFollow-up from "GBL with correct treatment of rotations"The following discussion from !254 should be addressed:
- [ ] @simonspa started a [discussion](https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/254#note_3443646): (+1 comment)
> I would prefer if we could keep the...The following discussion from !254 should be addressed:
- [ ] @simonspa started a [discussion](https://gitlab.cern.ch/corryvreckan/corryvreckan/-/merge_requests/254#note_3443646): (+1 comment)
> I would prefer if we could keep the plane construct completely contained within the track. Now it is pretty dirty since we need to construct a plane (allocate) then copy it into the track etc. This exposes quite some "inner workings" which is not nice.2.0https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/115Inclduing Detetcor.hpp into objects leads to linking error2021-11-12T13:05:32+01:00Lennart HuthInclduing Detetcor.hpp into objects leads to linking errorDuring the discussions for !254, it turned out that it would be convenient to have functions like
`TRack::GetIntercept(std::shared_ptr<Detetcor>` in order to not expose technicalities to the user in the modules. I started moving this fu...During the discussions for !254, it turned out that it would be convenient to have functions like
`TRack::GetIntercept(std::shared_ptr<Detetcor>` in order to not expose technicalities to the user in the modules. I started moving this functionality in https://gitlab.cern.ch/lhuth/corryvreckan/-/tree/fix_getIntercept
I just got stuck with a linking error. See below. IF someone has the solution? :rocket:
```
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/CorryvreckanObjects.dir/GblTrack.cpp.o: in function `corryvreckan::GblTrack::getIntercept(std::shared_ptr<corryvreckan::Detector>) const':
/home/lhuth/software/corryvreckan/src/objects/GblTrack.cpp:30: undefined reference to `corryvreckan::Detector::getType[abi:cxx11]() const'
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /home/lhuth/software/corryvreckan/src/objects/GblTrack.cpp:31: undefined reference to `corryvreckan::Detector::getName[abi:cxx11]() const'
collect2: error: ld returned 1 exit status
make[2]: *** [src/objects/CMakeFiles/CorryvreckanObjects.dir/build.make:333: src/objects/libCorryvreckanObjects.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:518: src/objects/CMakeFiles/CorryvreckanObjects.dir/all] Error 2
make: *** [Makefile:163: all] Error 2
```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.0https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/113Double-quotes issue in Detector.cpp2020-05-26T09:45:38+02:00Morag WilliamsDouble-quotes issue in Detector.cppIn line 76 of `Detector.cpp` (https://gitlab.cern.ch/corryvreckan/corryvreckan/-/blob/master/src/core/detector/Detector.cpp#L76):
```
m_calibrationfile = config.getPath("calibration_file");
```
the path string is taken with the d...In line 76 of `Detector.cpp` (https://gitlab.cern.ch/corryvreckan/corryvreckan/-/blob/master/src/core/detector/Detector.cpp#L76):
```
m_calibrationfile = config.getPath("calibration_file");
```
the path string is taken with the double-quotes (") around it from the config file.
This seems not to be the case for other path variables, for example the `detectors_file`. The cause of this is currently unknown.2.0https://gitlab.cern.ch/corryvreckan/corryvreckan/-/issues/111Clustering4D logic of the time cut2020-10-23T17:20:52+02:00Jens KroegerClustering4D logic of the time cutAnother thing I stumbled upon while investigating the DESY 2019 data with a focus on the Timepix3 clustering:
In the while loop that does the actual clustering (see [here](https://gitlab.cern.ch/corryvreckan/corryvreckan/-/blob/master/s...Another thing I stumbled upon while investigating the DESY 2019 data with a focus on the Timepix3 clustering:
In the while loop that does the actual clustering (see [here](https://gitlab.cern.ch/corryvreckan/corryvreckan/-/blob/master/src/modules/Clustering4D/Clustering4D.cpp#L130)), the logic is as described on the slides attached.
**In short:** The time cut not "absolute", i.e. limiting the time distance between earliest and latest pixel in a cluster but between two consecutive clusters.
That's why we see this "slow drop-off" after the expected edge from the time cut as seen on the slides. **Is this on purpose?**
**after correction** on the slides refers to making it cut between earliest and latest pixel for a try.
[2020-04-29_StatusUpdate_JensKroeger_short.pdf](/uploads/eaf540d11b6ce1fe4df866b6d6e448ae/2020-04-29_StatusUpdate_JensKroeger_short.pdf)2.0https://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/106Resiudals in both, local and global coordinates2020-05-18T16:49:00+02:00Lennart HuthResiudals in both, local and global coordinatesCurrently, the residuals in all track-objects are in global x/y. This ignores rotations.
We should implement local (x,y only) and global (x/y/z) residuals.Currently, the residuals in all track-objects are in global x/y. This ignores rotations.
We should implement local (x,y only) and global (x/y/z) residuals.2.0Lennart HuthLennart Huthhttps://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/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/100Tracking4D + GBL after the most downstream tracking plane2020-05-20T15:13:17+02:00Mateus Vicente Barreto PintoTracking4D + GBL after the most downstream tracking planeConsidering the MIMOSA26 + Timepix3 telescope available at DESY TB24, I am currently trying to analyze the Timepix3 (placed downstream from all MIMOSA26 planes) as a DUT.
Therefore, I am using just the MIMOSA26 planes for the GBL tracki...Considering the MIMOSA26 + Timepix3 telescope available at DESY TB24, I am currently trying to analyze the Timepix3 (placed downstream from all MIMOSA26 planes) as a DUT.
Therefore, I am using just the MIMOSA26 planes for the GBL tracking, and I would like to check the track intersection in the TPX3 plane.
Nevertheless, this is currently not possible as the GBL track is not well defined outside the first and last tracking layers.
I wonder if it would be useful to extrapolate the last lag of the GBL track towards infinite in order to find its intersection on any plane downstream of the last tracking plane.
How could we still take into account the scatterer from the last plane?
How different would it be from using a straight track found with using just the last two planes?
Thanks for the help!2.0Lennart HuthLennart Huthhttps://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 Huth