Displaced Vertices and Smearing

[Fabrizio Nesti]

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

[Michele Selvaggi]

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

[Fabrizio Nesti]

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!

[Michele Selvaggi]

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)

[Fabrizio Nesti]

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

[Michele Selvaggi]

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

[Fabrizio Nesti]

I attached it (and sent by email to cp3-delphes@…, don;t know if it's processed) thanks f

[Fabrizio Nesti]

And just to understand the flow...

..in the exmaple FCC card, ImpactParameterSmearing is called after Momentum smearing

...
ChargedHadronMomentumSmearing
ElectronEnergySmearing
MuonMomentumSmearing

TrackMerger
ImpactParameterSmearing
...

Is this correct? Will ImpactParameterSmearing see the smeared momentum, and do a double smearing?

mabe I did not understand the flow of data...

f

[Michele Selvaggi]

Hi,

I attached a modified version of your card. Your module works fine, it is just that you have to access the vertex position in the modified track collection from Xouter, Youter, … This happens because of how the conversion between candidate and tracks is done.
If you want to access it from X, Y, Z, there is a cleaner way to do this, but one has to add a method that clears the vector of references in the candidate class.

Also, I suggest you move to 3.2.0.

Michele

[Fabrizio Nesti]

Ok thanks, now everything is cleaner.
This solves all problems (well, for the time being :) )

Thanks a lot for your kind support!

f

[Fabrizio Nesti]

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)