-
Notifications
You must be signed in to change notification settings - Fork 27
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
GBDT-Based Displaced Vertex Producer #1257
base: phase2-l1t-integration-14_0_0_pre3
Are you sure you want to change the base?
GBDT-Based Displaced Vertex Producer #1257
Conversation
Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation. Attempts to compile this PR succeeded!
|
Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation. I found no issues with the code checks!
I found issues with the headers. These issues likely arise from improper build files. The following is the stderr of the header checking:
|
Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation. I found 10 files that did not meet formatting requirements:
Please run
|
Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation. This PR passes available unit tests!
|
Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation I found a non-zero return code running the relval workflows for this PR!
|
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.
We normally put these files here (https://github.com/cms-data/L1Trigger-TrackTrigger) to avoid having non-readable files in this repository. You will have to put in a PR to that repository to put it in there.
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.
@@ -90,7 +90,7 @@ std::vector<float> L1TrackQuality::featureTransform(TTTrack<Ref_Phase2TrackerDig | |||
feature_map["bendchi2_bin"] = tmp_trk_bendchi2_bin; | |||
feature_map["chi2rphi_bin"] = tmp_trk_chi2rphi_bin; | |||
feature_map["chi2rz_bin"] = tmp_trk_chi2rz_bin; | |||
feature_map["tanl"] = tmp_trk_tanl; |
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.
Why is this being removed? Doesn't the prompt classifier need this?
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.
Just added this back in commit dbf8525
@@ -159,7 +159,9 @@ void L1TrackQuality::setL1TrackQuality(TTTrack<Ref_Phase2TrackerDigi_>& aTrack) | |||
} | |||
|
|||
else if (this->qualityAlgorithm_ == QualityAlgorithm::GBDT) { | |||
aTrack.settrkMVA1(ortoutputs[1][1]); | |||
if (this->featureNames_.back() == "d0"){ // temp fix, need better way to fill disp MVA |
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.
This really should have a better solution. I would suggest passing the output value through the function and setting the MVA variable in L1FPGATrackProducer.cc with an extended tracking flag since we shouldn't run this BDT unless extended tracking is running because d0 isn't filled.
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've implemented your suggestion in commit dbf8525
if (trackQuality_) { | ||
trackQualityModel_->setL1TrackQuality(aTrack); | ||
trackQualityDispModel_->setL1TrackQuality(aTrack); |
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.
There should be an extended tracking flag here since this should only run for extended tracking. There is a extended_
variable in this file that can be used.
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.
Done here dbf8525
@@ -42,27 +42,28 @@ | |||
# input and output | |||
############################################################ | |||
|
|||
process.maxEvents = cms.untracked.PSet(input = cms.untracked.int32(20)) | |||
|
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.
All the configurations in this file should be set back to the default configurations used by everyone. So the maxEvents, readFiles, skipEvents, useJobReport, fileName, etc.
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.
Reverted these changes as part of d95ffe9
l1TracksInputTag = cms.InputTag("l1tTTTracksFromExtendedTrackletEmulation", "Level1TTTracks"), | ||
l1TrackVertexCollectionName = cms.string("dispVertices"), | ||
mcTruthTrackInputTag = cms.InputTag("TTTrackAssociatorFromPixelDigisExtended", "Level1TTTracks"), | ||
ONNXmodel = cms.string("/afs/cern.ch/user/r/rmccarth/private/dispVert/CMSSW_14_0_0_pre3/src/L1Trigger/L1TTrackMatch/test/trackAndVert_NewTQMVA_model.onnx"), |
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.
Similar to Claire's comment below this also needs to be in a cms-data repository, we have one for L1TTrackMatch here: https://github.com/cms-data/L1Trigger-L1TTrackMatch
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.
Just made a PR: cms-data/L1Trigger-L1TTrackMatch#2
if(fabs(vertex.b.d0)<fabs(minD0)) minD0 = vertex.b.d0; | ||
//std::vector<float> Transformed_features = {vertex.delta_z, vertex.R_T, vertex.cos_T, vertex.d_T, vertex.chi2rzdofSum, float(vertex.numStubsSum), vertex.chi2rphidofSum, minD0, vertex.a.pt+vertex.b.pt}; | ||
std::vector<float> Transformed_features = {selectedTracks[i].pt, selectedTracks[j].pt, selectedTracks[i].eta, selectedTracks[j].eta, selectedTracks[i].phi, selectedTracks[j].phi, selectedTracks[i].d0, selectedTracks[j].d0, selectedTracks[i].z0, selectedTracks[j].z0, selectedTracks[i].chi2rz, selectedTracks[j].chi2rz, selectedTracks[i].bendchi2, selectedTracks[j].bendchi2, selectedTracks[i].MVA1, selectedTracks[j].MVA1, selectedTracks[i].MVA2, selectedTracks[j].MVA2, vertex.d_T, vertex.R_T, vertex.cos_T, vertex.delta_z}; | ||
//cms::Ort::ONNXRuntime Runtime(this->ONNXmodel_); //Setup ONNX runtime |
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.
This comment doesn't need to be here, in fact we should remove the similar comment from the TrackQuality.cc as the Runtime is now initialised (as you do) in the constructor
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.
Removed in commit 63cdfcf
mcTruthTrackInputTag = cms.InputTag("TTTrackAssociatorFromPixelDigisExtended", "Level1TTTracks"), | ||
ONNXmodel = cms.string("/afs/cern.ch/user/r/rmccarth/private/dispVert/CMSSW_14_0_0_pre3/src/L1Trigger/L1TTrackMatch/test/trackAndVert_NewTQMVA_model.onnx"), | ||
ONNXInputName = cms.string("feature_input"), | ||
featureNames = cms.vstring(['trkExt_pt_firstTrk', 'trkExt_pt', 'trkExt_eta_firstTrk', 'trkExt_eta', 'trkExt_phi_firstTrk', 'trkExt_phi', 'trkExt_d0_firstTrk', 'trkExt_d0', 'trkExt_z0_firstTrk', 'trkExt_z0', 'trkExt_chi2rz_firstTrk', 'trkExt_chi2rz', 'trkExt_bendchi2_firstTrk', 'trkExt_bendchi2', 'trkExt_MVA_firstTrk', 'trkExt_MVA', 'trkExt_MVA2_firstTrk', 'trkExt_MVA2', 'dv_d_T', 'dv_R_T', 'dv_cos_T', 'dv_del_Z']) |
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.
Are these featureNames used by the code anywhere, in the track quality code they are used in a mapping but you just use all of these in a single vector
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.
They are read in by the DisplacedVertexProducer (https://github.com/ryanm124/cmssw/blob/d95ffe97501c7e003b3bc9de7e83685ecc20a6a6/L1Trigger/L1TTrackMatch/plugins/DisplacedVertexProducer.cc#L112) but not actually used. I could build up a map of inputs using this list or just remove the list entirely, whichever you think is best.
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.
We have a map of inputs in the track quality to allow some flexibility over the inputs but if your inputs are set and you don't foresee any change I would not have these features names read in and unused and instead have a comment here in the python config about what features the BDT uses
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've turned this into a comment as you suggested here 63cdfcf
float MVA2 = iterL1Track->trkMVA2(); | ||
std::vector<edm::Ref<edmNew::DetSetVector<TTStub<Ref_Phase2TrackerDigi_> >, TTStub<Ref_Phase2TrackerDigi_> > > stubRefs = iterL1Track->getStubRefs(); | ||
int nstub = (int)stubRefs.size(); | ||
if( chi2rz<3.0 && MVA2>0.2 && MVA1>0.2 && pt>3.0 && fabs(eta)<2.4){ |
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 recommend moving these track selection criteria to the python config to avoid the hard coding of these criteria here or using the track selection producer
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 second using the track selection producer as this is much cleaner. You will just have to create another config in the python config and add whatever varibles are not already there (like MVA2), and then pass this track collection into the displaced vertex config here.
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'm looking at the track selector and I'm wondering if using this is in fact cleaner than simply moving the parameters to a python config as Christopher suggested. The selector producer seems to be made for simpler, single variable cuts while I have several selections that depend on two variables such as the MVA score of displaced (d0>1cm) tracks. The selector also is cutting on all defined variables regardless of which ones the user has overwritten so there are many wasted operations such as checking if reducedBendChi2MaxNstub5<999.9 which would always be true.
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 agree with @Chriisbrown and @cgsavard. You should add these to the python configuration of this module so the values of the cuts can be set there, but keep the logic here. I don't see where wasted checks and operations would happen there?
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.
@aloeliger For example, reducedChi2RZMaxNstub4 is defined which I'm currently not cutting on. This parameter is used as part of the chi2nstub selection which is used for every track here. So this track selection producer seems to cut on every defined variable even though for many of the default values such as this one the cut is essentially a Boolean true
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.
You shouldn't need to set a magnitude size, this is for when a variable needs to be converted from a track word variable. Since d0 is a variable directly included in the track word, no conversion is needed. You should follow what is being done for getting the z0 using the proper d0 functions from the track word class.
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've modified the displaced vertex producer to use the track selection producer here 63cdfcf
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.
Does the MC track association have to be redone after using the track selection producer? The truth association seems to not be working now after this change
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.
No, it shouldn't change anything except for where track selection is being done. The only thing I can think of is some of the files don't have the truth association included so maybe you are looking at one of those files?
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've been using the same file for testing these PR changes and I was able to get the tracking particles before. Now it's giving a null pointer for each track. I looked at the other producers that use the track selection and it seems like they don't use truth information. Has anyone done this before?
@@ -193,6 +194,16 @@ | |||
process.pTkMHT = cms.Path(process.l1tTrackerHTMiss*process.l1tTrackerHTMissExtended) | |||
process.pTkMHTEmulator = cms.Path(process.l1tTrackerEmuHTMiss*process.l1tTrackerEmuHTMissExtended) | |||
process.pL1TrackTripletEmulator = cms.Path(process.l1tTrackTripletEmulation) | |||
process.DispVert = cms.Path(process.DisplacedVertexProducer) | |||
process.printTree = cms.EDAnalyzer("ParticleTreeDrawer", |
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.
Can this be added as an optional part of the ObjectNtupleMaker rather than by default unless it is something that everyone would want running when creating the L1TTrack Objects
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 added a boolean in the cfg to run the displaced vertexing which is false by default here d95ffe9
|
||
using namespace std; | ||
|
||
class Track_Parameters |
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.
Is it necessary to create this new class? Can you just use the TTTrack class?
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.
It was convenient to define a class which contains the parameters of the projection of the track on the transverse plane just so I only calculate it once per track. Is there a preference for using functions or class methods for this type of thing?
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 preference is not necessarily for functions versus class members, but for condensing the number of in use classes to try and consolidate code and functionality.
There are at least a few things conceptually similar between TTrack
and it's parent class TTTrack_TrackWord
and this track parameters class. It would be good if the track trigger developers could try to centralize as many common elements to most types of tracks in one place if possible
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 what would you recommend? I could try inheriting from TTrack in my class and only add the extra functionality I need or I could try to do without an additional class at all.
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.
My recommendation would be to remove this class entirely, pass the L1 track into these functions and use the TTTrack/TTTrack_Word variables directly, and similarly for everywhere else this is used like here.
… when setting track quality score
aTrack.settrkMVA2(qualityScore); | ||
} | ||
else{ | ||
aTrack.settrkMVA1(qualityScore); |
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.
This is not quite doing what we want. It seems like when extended==false, trkMVA1 is being overwritten with the qualityScore from the displaced model. We should remove the else statement, and only MVA2 is filled if extended_==true.
Also, why is there an additional constraint on the displaced model being a BDT? The displaced model should just be whatever is in the configuration and this seems like it will not let any changes to occur? I think it's better to make all changes to the configs than to the hardset code
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.
Currently only the BDT is defined for displaced tracks, right? I wanted to allow for the use of extended tracking with the prompt classifiers such as the NN. I've also found it useful to use both the prompt and displaced MVA score while using the extended tracking which is why I've set it up this way.
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.
That's right. I think we should always fill MVA1 with the prompt classifier no matter what (so that would be the removal of the else statement) and if someone wants to switch the prompt classifier to another one, say a NN, then that is done in the config. Then whenever extended tracking is run, we should fill MVA2 with the displaced one in addition to the prompt MVA1 one. And if people want to change the displaced one then that should happen in the config, no additional filtering should really be done here.
So here is what I'm imagining:
if (trackQuality_) {
aTrack.settrkMVA1(trackQualityModel_->getL1TrackQuality(aTrack));
if(extended_)
aTrack.settrkMVA2(trackQualityDispModel_->getL1TrackQuality(aTrack));
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.
Okay, I've made the fix d95ffe9
…changes to ntuple maker params, removing BDT requirement on displaced track quality
Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation. Attempts to compile this PR succeeded!
|
Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation. I found no issues with the code checks!
I found issues with the headers. These issues likely arise from improper build files. The following is the stderr of the header checking:
|
Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation. I found 11 files that did not meet formatting requirements:
Please run
|
if(a.charge>0){ | ||
p_vec *= -1; | ||
} | ||
p_vec /= TMath::Sqrt(pow(p_vec[0],2)+pow(p_vec[1],2)); |
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.
Is it possible that the arguments to this vector will end up as 0? This will causes errors if so.
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.
Added a check for this in this commit 63cdfcf
std::valarray<float> p_trk_2 = calcPVec(b_in,x_dv_in,y_dv_in); | ||
std::valarray<float> p_tot = p_trk_1+p_trk_2; | ||
p_mag = TMath::Sqrt(pow(p_tot[0],2)+pow(p_tot[1],2)); | ||
openingAngle = (p_trk_1[0]*p_trk_2[0]+p_trk_1[1]*p_trk_2[1]) / (TMath::Sqrt(pow(p_trk_1[0],2)+pow(p_trk_1[1],2))*TMath::Sqrt(pow(p_trk_2[0],2)+pow(p_trk_2[1],2))); |
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.
Same question about possible division by zero errors here.
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.
Added a check for this in this commit 63cdfcf
p_mag = TMath::Sqrt(pow(p_tot[0],2)+pow(p_tot[1],2)); | ||
openingAngle = (p_trk_1[0]*p_trk_2[0]+p_trk_1[1]*p_trk_2[1]) / (TMath::Sqrt(pow(p_trk_1[0],2)+pow(p_trk_1[1],2))*TMath::Sqrt(pow(p_trk_2[0],2)+pow(p_trk_2[1],2))); | ||
R_T = TMath::Sqrt(pow(x_dv_in,2)+pow(y_dv_in,2)); | ||
cos_T = (p_tot[0]*x_dv_in+p_tot[1]*y_dv_in)/(R_T*TMath::Sqrt(pow(p_tot[0],2)+pow(p_tot[1],2))); |
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.
And here
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.
Added a check for this in this commit 63cdfcf
|
||
class Vertex_Parameters | ||
{ | ||
public: |
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.
Are there any extant Track Trigger classes for handling vertexes that would be good to centralize this class with?
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.
My personal preference would be to get rid of this class as well and use these variables directly in the DisplacedVertexProducer class to avoid another vertex-like class, but I also see why you may want to set it up like this. It doesn't quite follow how the other GTT object classes are set up so I would suggest maybe changing this class to a struct instead as it's really only holding variables to be used by DisplacedVertexProducer.
There is no vertex class that has all of these variables.
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.
can this (class => functions) be done as a "code improvement" in a second stage? L1 is requesting that this PR is merged in order for @ryanm124 to show the plots at an upcoming conference. that request is to have code to be able to reproduce the results, and it seems code improvements wouldn't be necessary for that?
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.
This is ok with me for this comment. There does seem to be some potential logic issues brought up in other comments that might need more addressing. And at minimum, the code checks and formatting should be done and It doesn't seem like the formatting has been applied. You should run these two commands:
scram build code-checks
scram build code-format
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.
Code formatting has been applied 93ea36d
class DisplacedVertexProducer : public edm::global::EDProducer<> { | ||
public: | ||
explicit DisplacedVertexProducer(const edm::ParameterSet&); | ||
~DisplacedVertexProducer() override {} |
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.
~DisplacedVertexProducer() override {} | |
~DisplacedVertexProducer() override = default; |
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've implemented this
float MVA2 = iterL1Track->trkMVA2(); | ||
std::vector<edm::Ref<edmNew::DetSetVector<TTStub<Ref_Phase2TrackerDigi_> >, TTStub<Ref_Phase2TrackerDigi_> > > stubRefs = iterL1Track->getStubRefs(); | ||
int nstub = (int)stubRefs.size(); | ||
if( chi2rz<3.0 && MVA2>0.2 && MVA1>0.2 && pt>3.0 && fabs(eta)<2.4){ |
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 agree with @Chriisbrown and @cgsavard. You should add these to the python configuration of this module so the values of the cuts can be set there, but keep the logic here. I don't see where wasted checks and operations would happen there?
//preselection cuts and plots definitions | ||
// Cut assumptions: first cut is maxEta | ||
std::vector<std::unique_ptr<Cut>> preselCuts; | ||
std::unique_ptr<TypedCut<float>> cut0(new TypedCut<float>("maxEta","max #eta",&trk_eta,2.4,true)); |
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 know this is test code and isn't really intended for main CMSSW use, but std::make_unique
is probably preferred.
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.
Does this need to go into CMSSW? It seems like a large single purpose macro, designed for one person or group only.
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.
No it doesn't, I can remove it from the PR
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.
This cannot be committed to CMSSW. It's fine here I guess, but in a PR to CMSSW all non-code files need to be committed to the data repositories.
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.
This cannot be committed to CMSSW. It's fine here I guess, but in a PR to CMSSW all non-code files need to be committed to the data repositories.
… selection producer, and added divide by 0 checks
…ng input track collection
The track selection module has broken the truth association. I suspect it's changing the addresses of the tracks which breaks the mapping between the tracks and tracking particles. Can I move the cuts back to my displaced vertex producer but have the cut values be input from the python config? Otherwise, I need someone to help get this working |
…ed bug in track truth association which affected BDT training boolean
I've removed the track selection module and moved the cut values to the python configuration in my last commit. The code is working and should be ready to merge |
…fixed<13,8>, shifting quality variables, and rescaling delta z and pt
I've added the emulation of my displaced vertexing to this PR. I need to remove some changes/files which are no longer necessary and then this PR needs to be rereviewed |
@cgsavard @aloeliger @Chriisbrown @skinnari I've finished updating the PR to include the emulation of the displaced vertexing. I've removed the changes I had made to the track selection and to the displaced track quality as they're no longer needed. Could you please rereview this PR? |
Updated version of the displaced vertex producer presented at L1 DPG: https://indico.cern.ch/event/1408668/contributions/5920520/attachments/2850847/4984793/Displaced%20Vertexing%20Low%20Fake%20DP%20Note.pdf
Contains the latest GBDT trained on Dark Photon and Neutrino Gun sample emulated tracks.
PR for displaced vertex GBDT: cms-data/L1Trigger-L1TTrackMatch#2