Skip to content

Conversation

@ebrondol
Copy link
Owner

@ebrondol ebrondol commented May 4, 2023

This is a fake pull request to track the review for the Kalman Filter code for HGCAL in CMSSW.

cmsbuild and others added 15 commits May 25, 2022 16:28
…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).
Copy link
Owner Author

@ebrondol ebrondol left a 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.

Copy link
Owner Author

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.

Copy link

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()
Copy link
Owner Author

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:

Suggested change
kf = cms.Modifier()
hgcal_ticl_kf = cms.Modifier()

Copy link
Owner Author

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.

Copy link

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?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exactly

Copy link
Owner Author

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/'

Copy link

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

Copy link

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?

Copy link
Owner Author

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.

Copy link
Owner Author

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"
Copy link
Owner Author

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
Copy link
Owner Author

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;
Copy link
Owner Author

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]
Copy link
Owner Author

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;
Copy link
Owner Author

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
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants