Opened 10 years ago
Last modified 10 years ago
#406 reopened How to
Displaced Vertices and Smearing
Reported by: | Fabrizio Nesti | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | Delphes code | Version: | Delphes 3 |
Keywords: | vertex smearing | Cc: |
Description
Dear Delphes people,
we are interested in simulating and accessing the (displaced) vertex information for a number of objects (muons, etc), generated by long lived particles decayed within pythia.
I'd like to ask for some confirmations/help:
1- Looking at the code, it seems that already the information on track vertex is available as track->X, Y, Z. This seems to be the correct vertex, as produced by pythia. However, the reconstructed objects (e.g. muon) are not associated to a track. Would it be correct to search for at least one track say in a 0.1 cone and associate it? Or there is some better method (some pointer already filled?) We are actually doing this in root2lhco and writing the vertex in the dum1,dum2 lhco fields :).
2- Vertex smearing. Is there a smearing module/function which could be customized/applied, within delphes? I saw some smearing in PileUpMerger, but I wonder if it would be better a standalone module like "VertexSmearing" (I have limited knoweledge of pileup, though). Also, why only z, t smearing as found there? Real detectors have resolution in transverse and z directions (function of eta, pt), in my understanding. In short, what is the best approach to insert vertex smearing in the game?
thanks in advance for any insight,
Fabrizio
Attachments (3)
Change History (14)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Thanks for the prompt reply!
1) That is very nice. Only concern, if I understand, genParticle is the the generator level particle, and I am thinking that instead it may be more proper to associate a reconstructed track (if it exists in fact, and after its smearing etc.) Maybe the information inside coincides?
2) Smearing - yes one can find how the real detectors find and estimate the resolution in vertices and tracks. E.g. slide 29 of https://indico.cern.ch/event/300851/session/7/contribution/42/material/slides/0.pdf.
And it is quite direct to apply smearing it at the level of root2lhco.
But maybe it would be sensible and quite straightforward also to do it as a delphes module, to be called on the tracks (only I am wondering if to start building a new section in ModulesDict and all that.....)
Needless to say this is quite important for displaced vertex searches, including SUSY, light dark matter, neutrino masses, etc.
In any case, thanks again!
comment:3 by , 10 years ago
1) You are right in general, but since vertex is not smeared from gen to track, it does not matter, and the information coincides.
2) You can write a new module for that. You can find a guide on how to write a new module in the following tutorial.
http://indico.cern.ch/event/315979/ (click on notes and open DelphesTutorial_NewModule.txt)
comment:4 by , 10 years ago
Hi Michele,
very good - so - I did the new module :). Everything works inside, but I have a final issue that I am not able to overcome. The updated tracks seem not to be written to the root file. I tried to dig in the root details but I am still stuck, so I kindly ask for advice again. Maybe it's a basic issue I am missing.
The new module TrackVertexSmearing is based on ImpactParameterSmearing, so it contains
fInputArray = ImportArray(GetString("InputArray", "TrackMerger/tracks"));
fItInputArray = fInputArray->MakeIterator();
fOutputArray = ExportArray(GetString("OutputArray", "tracks"));
is it correct? then at the end of process,
...
mother = candidate;
candidate = static_cast<Candidate*>(candidate->Clone());
candidate->Position.SetXYZT(x, y, z, t);
candidate->AddCandidate(mother);
fOutputArray->Add(candidate);
However, in the rootfile, the tracks in the Tracks tree do not contain the new information.
Similarly, root2lhco (fTreeReader->UseBranch("Track");) does not find the new values.
Even if I comment Add(candidate) above things do not change so I am puzzled.
The module process is actually called, as I print to stdout some infos..
I tried to insert it in various places of ExecutionPath, even right before the TreeWriter.. but nope.
Evidently I am missing something simple?
thanks a lot for any help,
Fabrizio
comment:5 by , 10 years ago
Hi Fabrizio,
without having a look at your setup I will have hard time figuring out what's wrong.
Could you make a tar ball of your modified Delphes without the input file and upload it here?
(if file is too big send via mail/dropbpox/lxplus)
Thanks,
Michele
by , 10 years ago
Attachment: | delphes_3_1_2_fne_trackvertexsmearing_debug.tgz added |
---|
comment:6 by , 10 years ago
I attached it (and sent by email to cp3-delphes@…, don;t know if it's processed) thanks f
comment:7 by , 10 years ago
And just to understand the flow...
..in the exmaple FCC card, ImpactParameterSmearing is called after Momentum smearing
...
ChargedHadronMomentumSmearing
ElectronEnergySmearing
MuonMomentumSmearing
Is this correct? Will ImpactParameterSmearing see the smeared momentum, and do a double smearing?
mabe I did not understand the flow of data...
f
by , 10 years ago
Attachment: | delphes_card_SMEAR.dat added |
---|
comment:8 by , 10 years ago
Hi,
I just erased the last message so that other readers don't get confused.
Pavel had a smarter way of implementing what you need, I have attached the modified module as well now.
Cheers
Michele
by , 10 years ago
Attachment: | TrackVertexSmearing.cc added |
---|
comment:9 by , 10 years ago
Ok thanks, now everything is cleaner.
This solves all problems (well, for the time being :) )
Thanks a lot for your kind support!
f
comment:10 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:11 by , 10 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Sorry to bother again. The module and all the flow works great in delphes 3.1.2. However as adviced I tried switching to 3.2.0.
it compiles but the Muon branch appears to come out empty.. (as from fTreeReader->UseBranch("Muon") in root2lhco)
(of course if I revert Calorimeter TrackInputArray to the original TrackMerger/tracks everything goes back ok, so something breaks in the later muon flow)
Hi Fabrizio,
1) the vertex not being smeared as you say, you can simply look at the GenParticle that gave rise to the particular reco particle you are looking, and from GenParticle you have access to X,Y,Z of the vertex.
https://github.com/delphes/delphes/blob/master/examples/Example3.C#143-143
2) On PileUpMerger the reason we don't smear X,Y is that for pile-up that not relevant, due to the elongated shape of the beams, and we need the z profile just to be able to set a criterion on the the discrimination of pile-up vs. hard scattering vertices.
Unfortunately it is hard to have a general answer to your question, on your particular problem, I suggest you have a look at ATLAS or CMS analyses that involve long lived particles, and vertex searching, and parametrize the vertex resolution in the same way as they do, and then either plug it in Delphes or simply apply it on the Delphes output. A more advanced approach would consist in implementing some kind of vertex reconstruction algorithm in Delphes, but that might be complicated.
Michele