-
Notifications
You must be signed in to change notification settings - Fork 0
[WIP] KF v0 review #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
base: master
Are you sure you want to change the base?
Conversation
…erBtau Remove dead assignments and simplify HLTmumutkFilter
The medium properties were gained via the neutrinogun. There, the radlen was calculated. The xi was calculated from the radlen and other properties specified in the MediumProperties.h
Updated nextDisk and added HGCDiskGeomDet so that the propagator propagates to the correct z position based on the type of sensor.
measurements function gets the closest measurements to the output of the propagator based on Chi2MeasurementEstimator. HGCTrackingRecHits needed as input for estimator. The local error for the individual sensors is calculated before the event loop. Update step performed using output of propagator and measurements. TODO: Algorithm fails at low energies and at fringe regions.
A segmentation fault occurred due to missing tracks for the seeding region. Now skipping events with missing tracks. The for loop in the nextDisk() function did not account for the case where, in the forward propagation, the track moves from a scintillator tile to a silicon cell. In the context of the for loop this requires 3 iterations instead of two to move to the silicon in the next layer (scintillator, silicon, scintillator, silicon).
…SSW_13_1_0_pre1
ebrondol
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @mnmat
Thanks a lot for the work, my comments are mostly for clean-up and to include descriptions or comments in the code to improve readability.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this file needs to be re-inserted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But this is only needed for my branch and I don't think it should be part of the framework right?
|
|
||
| # This modifier is for injecting KF-based iterations in TICL. | ||
|
|
||
| kf = cms.Modifier() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest changing the name of the Modifier to make it more explicit, something along the lines of:
| kf = cms.Modifier() | |
| hgcal_ticl_kf = cms.Modifier() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remember when you open the PR to include a line with a recipe to test the Modifier for the reviewers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok sounds good. But separate from the code right? So it's gonna be in the comment section along the lines of "Test modifier on xxxxx.x" right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
exactly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The question will come on "Do you really need a new hit or you can re-use some that is already in DafaFormats/TrackingRecHit?". Be prepared to reply to this.
Moreover, there will be the question of why it needs another folder and it cannot just be under 'DataFormats/HGCRecHit/'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the reason why we can't use the TrackingRecHit directly is that it contains several pure virtual functions meaning that it can only be used as part of a derived class. I think the same goes for the rest of the objects found in DataFormats/TrackingRecHit. What I could try is to use maybe TrackerRecHit objects in https://github.com/cms-sw/cmssw/tree/master/DataFormats/TrackerRecHit2D for example. That I didn't try.
As for the folder: Sure I think I can move it to the HGCRecHit folder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But come to think of it. The HGCRecHit is based on a different type of RecHit so maybe it does make sense to separate the two?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I agree with you.
Let's keep it as it is and if they ask in the review to move it, I would say either we move it in 'DataFormats/TrackingRecHit' or in 'DataFormats/TrackerRecHit2D'. Maybe better the first one because I looked into the classes of the 2D and I don't think there is one that we can simple use for our scope.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Decide:
- what to keep in the rechit object
- in case you want to keep it for debugging purposes make another branch and clean up this one
| #include <vector> | ||
| #include <array> | ||
| #include "DataFormats/HGCalReco/interface/Trackster.h" | ||
| #include "DataFormats/HGCalReco/interface/KFHit.h" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clean up if needed.
| traj_kf.swap(newcands_kf); | ||
| } | ||
|
|
||
| // Propagator loop used purely for testing purposes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to move to debug branch?
| } | ||
|
|
||
| FreeTrajectoryState fts = trajectoryStateTransform::outerFreeState(tkx.front(),bfield_.product()); | ||
| std::cout << "Rescale Factor: None" << std::endl; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this version of the code, the rescaling is not implemented. TBH, I would implement it and keep it to the user in case they want to play with it.
| @@ -0,0 +1,114 @@ | |||
| // Author: Marco Rovere - [email protected] | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
to be changed
| } | ||
|
|
||
| // Collect hits with estimate | ||
| int depth = disk->layer()+1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would call it layer if this is indeed what it is. depth can be a bit mysterious
| if (rho < rmin[layer]) rmin[layer] = rho; | ||
| } | ||
|
|
||
| int layer = ddd->getLayerOffset(); // FIXME: Can be made less stupid |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
stupid question: why this and not firstLayer(): https://github.com/cms-sw/cmssw/blob/master/Geometry/HGCalCommonData/interface/HGCalDDDConstants.h#LL70C23-L70C23
?
This is a fake pull request to track the review for the Kalman Filter code for HGCAL in CMSSW.