-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using cylindrical surfaces for track reconstruction in iLCSoft #50
Comments
Just some first thoughts: In principle the tracking can deal with cylindrical surfaces, the surface we use at the IP is a cylinder if I am not confusing things. Your |
Yes? https://github.com/iLCSoft/KalTest/blob/master/src/geomlib/TCylinder.cxx I think?
No? Maybe? Depends on the rest of your code?
That cannot be used for cylindrical surfaces? Any smearing in "phi" would move the hit outside the surface? Can you point to where you attach the surfaces to your cylindrical vertex detector layers? PS: Thanks for the detailed reproducer!
but why not make this a git commit? Don't make me do manual things for the reproducer beyond copy pasting commands. Ideally one block of commands. Use shell comments |
This file But maybe I just got lost in your reproducer. |
Just fixed it, please fetch the k4geo/lcgeo branch again. (trouble with the k4geo parallel PR, for which I changed things as well). Also no more need to apply the git patch. The output is the same as yesterday however (just tried). I'm going through your comments, thank you both a lot already!
Yes, I had seen the KalTest repo, but as you say the beampipe does not come with a measurement.
Yes, I know. I also tried DDPlanarDigiProcessor without smearing (setting ResolutionU/V to 0) so that the hits stay where they are, but to no avail. |
This is done here in VertexBarrel_detailed_o1_v02_geo.cpp
Yes, I had also found that: DDTPCDigiProcessor. What approach do you think is best? Writing a DDCylindricalDigiProcessor based on the TPC one? (removing all TPC related things, only keeping Gaussian smearing in phi and z) |
cloning DD4hep
compile DD4hep:
cloning and compiling k4geo:
Enabling the curved vertex by using this git patch:
use_ultra_light.patch
Cloning my CLDConfig repo:
Running SIM:
Running RECO:
Input: No further input files needed
Output:
dd4hep.log,
k4geo.log,
reco.log (reco.log is with TruthTracking - errors also persist with using the ConformalTracking chain)
Goal: I'm trying to use my ultra-light curved IDEA vertex in full simulation using CLD and replacing the IDEA vertex with this one. This has worked for the normal IDEA vertex detector (with ladders), but doesn't work yet with the curved variant, where the detector consists of curved silicon sensors, for which I adapted dd4hep::rec::VolSurface accordingly (see PR in DD4hep). I want to get d0 and z0 resolutions of particle gun tracks in the same way for the curved vertex as for the CLD/IDEA vertex detectors.
Problem: Using k4Marlin wrapper and the usual reco chain for the vertex (DDPlanarDigiProcessor + TruthTrackFinder/ConformalTracking+ClonesAndSplitTracksFinder) with adjusted ResolutionU und ResolutionV lets the reconstruction run, and the reco hits look reasonable (very close to the SIM hits as expected by the small resolution of 0.003 mm), but for every event I get the following error:
The resulting residuals of the tracks are way too large then in d0 and z0. The efficiencies and other track parameters look good however.
I think the problem arises from the MarlinTrk::createFinalisedLCIOTrack function, which is used both in the TruthTracking and the ConformalTracking.
Are cylindrical surfaces in general supported by iLCSoft reconstruction and are the changes I made in the DD4hep PR enough, what further needs to be changed to use a VolSurface instead of a plane surface? Since the reco hits look ok, I don't think the problem is in the DDPlanarDigitizer.
Thank you and kind regards,
Armin
The text was updated successfully, but these errors were encountered: