Skip to content
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

Open
wants to merge 23 commits into
base: phase2-l1t-integration-14_0_0_pre3
Choose a base branch
from

Conversation

ryanm124
Copy link

@ryanm124 ryanm124 commented May 14, 2024

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

@triggerDoctor
Copy link

Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation.

Attempts to compile this PR succeeded!

Info Value
return code 0
command eval scramv1 runtime -sh && scram b -j 8

@triggerDoctor
Copy link

Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation.

I found no issues with the code checks!

Info Value
return code 0
command eval scramv1 runtime -sh && scram b -k -j 8 code-checks && scram b -k -j 8 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:



In file included from src/L1Trigger/L1TTrackMatch/interface/DisplacedVertexProducer.h:12:
/cvmfs/cms.cern.ch/el9_amd64_gcc12/cms/cmssw/CMSSW_14_0_0_pre3/src/PhysicsTools/ONNXRuntime/interface/ONNXRuntime.h:19:10: fatal error: onnxruntime/core/session/onnxruntime_cxx_api.h: No such file or directory
   19 | #include "onnxruntime/core/session/onnxruntime_cxx_api.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
gmake: *** [config/SCRAM/GMake/Makefile.rules:1833: tmp/el9_amd64_gcc12/src/L1Trigger/L1TTrackMatch/src/L1TriggerL1TTrackMatch/DisplacedVertexProducer.h.chk_header] Error 1
gmake: Target 'check-headers' not remade because of errors.

Info Value
return code 2
command eval scramv1 runtime -sh && scram b -k -j 8 check-headers

@triggerDoctor
Copy link

Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation.

I found 10 files that did not meet formatting requirements:

  • DataFormats/L1Trigger/interface/DisplacedVertex.h
  • L1Trigger/L1TMuon/src/MicroGMTConfiguration.cc
  • L1Trigger/L1TTrackMatch/interface/DisplacedVertexProducer.h
  • L1Trigger/L1TTrackMatch/plugins/DisplacedVertexProducer.cc
  • L1Trigger/L1TTrackMatch/test/Analyzer_DisplacedMuon.C
  • L1Trigger/L1TTrackMatch/test/L1TrackObjectNtupleMaker.cc
  • L1Trigger/Phase2L1GMT/interface/TPSLUTs.h
  • L1Trigger/Phase2L1GMT/plugins/Phase2L1TGMTFwdMuonTranslator.cc
  • L1Trigger/TrackFindingTracklet/plugins/L1FPGATrackProducer.cc
  • L1Trigger/TrackTrigger/src/L1TrackQuality.cc

Please run scram b code-format to auto-apply code formatting

Info Value
return code 0
command eval scramv1 runtime -sh && scram b -k -j 8 code-format-all

@triggerDoctor
Copy link

Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation.

This PR passes available unit tests!

Info Value
return code 0
command eval scramv1 runtime -sh && scram b runtests

@triggerDoctor
Copy link

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!

Info Value
return code 1
command eval scramv1 runtime -sh && runTheMatrix.py --what upgrade -l 26834.78

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.

Copy link
Author

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;

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?

Copy link
Author

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

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.

Copy link
Author

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);

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.

Copy link
Author

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))

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.

Copy link
Author

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"),

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

Copy link
Author

Choose a reason for hiding this comment

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

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

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

Copy link
Author

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'])
Copy link

@Chriisbrown Chriisbrown May 15, 2024

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

Copy link
Author

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.

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

Copy link
Author

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){

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

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.

Copy link
Author

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.

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?

Copy link
Author

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

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.

Copy link
Author

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

Copy link
Author

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

Copy link

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?

Copy link
Author

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",

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

Copy link
Author

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

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?

Copy link
Author

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?

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

Copy link
Author

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.

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.

aTrack.settrkMVA2(qualityScore);
}
else{
aTrack.settrkMVA1(qualityScore);

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

Copy link
Author

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.

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));

Copy link
Author

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
@triggerDoctor
Copy link

Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation.

Attempts to compile this PR succeeded!

Info Value
return code 0
command eval scramv1 runtime -sh && scram b -j 8

@triggerDoctor
Copy link

Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation.

I found no issues with the code checks!

Info Value
return code 0
command eval scramv1 runtime -sh && scram b -k -j 8 code-checks && scram b -k -j 8 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:

In file included from src/L1Trigger/L1TTrackMatch/interface/DisplacedVertexProducer.h:12:
/cvmfs/cms.cern.ch/el9_amd64_gcc12/cms/cmssw/CMSSW_14_0_0_pre3/src/PhysicsTools/ONNXRuntime/interface/ONNXRuntime.h:19:10: fatal error: onnxruntime/core/session/onnxruntime_cxx_api.h: No such file or directory
   19 | #include "onnxruntime/core/session/onnxruntime_cxx_api.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
gmake: *** [config/SCRAM/GMake/Makefile.rules:1833: tmp/el9_amd64_gcc12/src/L1Trigger/L1TTrackMatch/src/L1TriggerL1TTrackMatch/DisplacedVertexProducer.h.chk_header] Error 1
gmake: Target 'check-headers' not remade because of errors.

Info Value
return code 2
command eval scramv1 runtime -sh && scram b -k -j 8 check-headers

@triggerDoctor
Copy link

Hello, I'm triggerDoctor. @aloeliger is testing this script for L1T offline software validation.

I found 11 files that did not meet formatting requirements:

  • DataFormats/L1Trigger/interface/DisplacedVertex.h
  • L1Trigger/L1TMuon/src/MicroGMTConfiguration.cc
  • L1Trigger/L1TTrackMatch/interface/DisplacedVertexProducer.h
  • L1Trigger/L1TTrackMatch/plugins/DisplacedVertexProducer.cc
  • L1Trigger/L1TTrackMatch/test/Analyzer_DisplacedMuon.C
  • L1Trigger/L1TTrackMatch/test/L1TrackObjectNtupleMaker.cc
  • L1Trigger/Phase2L1GMT/interface/TPSLUTs.h
  • L1Trigger/Phase2L1GMT/plugins/Phase2L1TGMTFwdMuonTranslator.cc
  • L1Trigger/TrackFindingTracklet/plugins/L1FPGATrackProducer.cc
  • L1Trigger/TrackTrigger/interface/L1TrackQuality.h
  • L1Trigger/TrackTrigger/src/L1TrackQuality.cc

Please run scram b code-format to auto-apply code formatting

Info Value
return code 0
command eval scramv1 runtime -sh && scram b -k -j 8 code-format-all

if(a.charge>0){
p_vec *= -1;
}
p_vec /= TMath::Sqrt(pow(p_vec[0],2)+pow(p_vec[1],2));

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.

Copy link
Author

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)));

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.

Copy link
Author

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)));

Choose a reason for hiding this comment

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

And here

Copy link
Author

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:

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?

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.

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?

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

Copy link
Author

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 {}

Choose a reason for hiding this comment

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

Suggested change
~DisplacedVertexProducer() override {}
~DisplacedVertexProducer() override = default;

Copy link
Author

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){

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));

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.

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.

Copy link
Author

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

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.

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.

@ryanm124
Copy link
Author

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
@ryanm124
Copy link
Author

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

@ryanm124
Copy link
Author

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

@ryanm124
Copy link
Author

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Algorithm Development Phase-2 Pertains to phase-2 development
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants