Transverse impact parameter discrepancy between full and fast simulation

[saracreates]

When comparing CLD full simulation in H->uu to CLD fast simulation (IDEA delphes card with silicon tracker that follows CLD geometry and resolution), the distributions of the transverse impact parameter (IP) d0 do not match. Full simulation has a wider distribution. However, the longitudinal IP z0 seems to have the same distribution in fast and full simulation (see histograms).

Fast simulation results of d0 match expectations (https://arxiv.org/abs/2202.03285).

Might this come from detector geometries used in full simulation CLD that are neglected in fast sim? Or is there an other explanation?

For documentation reasons, I attach the thorough investigation of the comparison of track parameters to this issue.

Helix_track_parameters-1.pdf

[Zehvogel]

This delphes card?

https://github.com/delphes/delphes/blob/a66659d22039c9599a8cc1c58e5f1803c36b125a/cards/delphes_card_FCCeeDetWithSiTracking.tcl#L209-L302

[Zehvogel]

You probably want to investigate this with simpler data first, i.e. particle gun at fixed energies and angles.

[andresailer]

Also things to know to actually understand what is going

• How where the fast sim samples created?
• How where the full sim samples created?
• What software versions were used?
• What was used for the reconstruction?
• How do you calculate d0?

[saracreates]

This delphes card?

https://github.com/delphes/delphes/blob/a66659d22039c9599a8cc1c58e5f1803c36b125a/cards/delphes_card_FCCeeDetWithSiTracking.tcl#L209-L302

Yes this should be it.

[saracreates]

Also things to know to actually understand what is going

@andresailer thanks for the constructive comment!

* How where the fast sim samples created?

I created them from this data: /eos/experiment/fcc/ee/generation/DelphesEvents/winter2023_training/IDEA_SiTracking/ using FCCAnalyses, see this repo.

* How where the full sim samples created?

Brieuc created the data I used: /eos/experiment/fcc/prod/fcc/ee/test_spring2024/240gev/Hbb/CLD_o2_v05/rec/ and as you see CLD version 5 was used.

* How do you calculate d0?

In full and fast simulation I access d0 from the trackstate of the (charged) particle (e.g. track.D0). But this value is with respect to (0,0,0) and not to the primary vertex. Therefore, in both versions, d0 is recalculated with respect to the primary vertex. Here, you can find the fast sim function and here, the respective full sim function that I have implemented myself and does the exact same thing as in fast sim.

* What software versions were used?

For full sim I used source /cvmfs/sw.hsf.org/key4hep/setup.sh -r 2024-04-12.

* What was used for the reconstruction?

I am unsure how to answer as I did not specify anything, so probably the standard reconstruction chains.

I hope this answered the questions, let me know if I missed details.

[andresailer]

Also things to know to actually understand what is going

@andresailer thanks for the constructive comment!

* How where the fast sim samples created?

I created them from this data: /eos/experiment/fcc/ee/generation/DelphesEvents/winter2023_training/IDEA_SiTracking/ using FCCAnalyses, see this repo.

* How where the full sim samples created?

Brieuc created the data I used: /eos/experiment/fcc/prod/fcc/ee/test_spring2024/240gev/Hbb/CLD_o2_v05/rec/ and as you see CLD version 5 was used.

Which of the two productions did you use?

* How do you calculate d0?

In full and fast simulation I access d0 from the trackstate of the (charged) particle (e.g. track.D0). But this value is with respect to (0,0,0) and not to the primary vertex. Therefore, in both versions, d0 is recalculated with respect to the primary vertex. Here, you can find the fast sim function and here, the respective full sim function that I have implemented myself and does the exact same thing as in fast sim.

Which trackstate do you use as input?
How do you get the primary vertex position?
What are the primary vertex positions for full and fast sim samples? Are the distributions on Monte Carlo level the same?

* What software versions were used?

For full sim I used source /cvmfs/sw.hsf.org/key4hep/setup.sh -r 2024-04-12.

The questions is in reference to which version was used for simulation and reconstruction, not for analysis.

* What was used for the reconstruction?

I am unsure how to answer as I did not specify anything, so probably the standard reconstruction chains.

Again, with respect to the samples created, not their analysis (of course analysis software versions could also matter).

I hope this answered the questions, let me know if I missed details.

See more questions above.

[saracreates]

Hi Andre - thanks for the follow up!

Which of the two productions did you use? (referring to full sim data creating)

I used /eos/experiment/fcc/prod/fcc/ee/test_spring2024/240gev/Hbb/CLD_o2_v05/rec/*/*/Hbb_rec_*.root for all 7 flavors.

Which trackstate do you use as input?
How do you get the primary vertex position?
What are the primary vertex positions for full and fast sim samples? Are the distributions on Monte Carlo level the same?

I do: auto track = particle.getTracks()[0].getTrackStates()[0]; // get info at interaction point
And I use the primary vertex position associated with one event from the collection "PrimaryVertices"
I have not compared the primary vertex positions in full and fast sim yet. This is a good idea to start with.

The questions is in reference to which version was used for simulation and reconstruction, not for analysis.

I can not answer the question then, as I have not created the samples myself.

Again, with respect to the samples created, not their analysis (of course analysis software versions could also matter).

Same for this.

[BrieucF]

Hi Sara,

I used /eos/experiment/fcc/prod/fcc/ee/test_spring2024/240gev/Hbb/CLD_o2_v05/rec///Hbb_rec_*.root for all 7 flavors.

Only /eos/experiment/fcc/prod/fcc/ee/test_spring2024/240gev/Hbb/CLD_o2_v05/rec/00016562/ should be used. There was a pre-production under /eos/experiment/fcc/prod/fcc/ee/test_spring2024/240gev/Hbb/CLD_o2_v05/rec/00016520/ which was buggy. I cleaned it some time ago but depending on when you did the plots, using * might cause a problem. And now there is a new one (with LCFIPlus jets enabled) under /eos/experiment/fcc/prod/fcc/ee/test_spring2024/240gev/Hbb/CLD_o2_v05/rec/00016783 so you would mix productions.

The questions is in reference to which version was used for simulation and reconstruction, not for analysis.

SteeringFile = cld_steer.py
ExtraCLIArguments=--vertexSigma 0.0098 2.54e-5 0.646 0.0063
softwareVersion = key4hep_240412
simulationApplication = ddsim
configVersion = key4hep-devel-2
configPackage = fccConfig

See: https://github.com/HEP-FCC/FCCDIRAC/pull/8/files#diff-49881c0c7d2bf58ff707e79dde5c522082b9a497c0e79928e8a5f1eb0071be87

[andresailer]

And I use the primary vertex position associated with one event from the collection "PrimaryVertices"

But the PrimaryVertex collection comes from reconstruction? Do you not get the MC-truth primary vertex?

[BrieucF]

Additional information: the buggy pre-production was cleaned in July 2024 so you should not be affected by that since you ran on the RECO samples after this. Anyway the bug was a rare crash with LumiCal collections missing (FCALSW/FCalClusterer@5ffeca1) so this should not impact your distributions, and this pre-production only had 1000 events while the bug free one has 1M. We have to look for something else.

[andresailer]

Where or what are the settings for the delphes samples?

[saracreates]

And I use the primary vertex position associated with one event from the collection "PrimaryVertices"

But the PrimaryVertex collection comes from reconstruction? Do you not get the MC-truth primary vertex?

As far as I am aware the "PrimaryVertices" edm4hep::VertexCollection are the reconstructed primary vertices.

[saracreates]

@andresailer

I've done a comparison of the primary vertices (PV) in fast and full simulation.

• in fast sim, the MC PV are used to calculate d0
• in full sim, the reco PV are used to calculate d0

In fast and full sim the MC PV look as expected (at 250 GeV: $x = 9.87$ $\mu$ m, $y= 25.4$ nm, $z= 0.65$ mm). In full sim, I have taken the vertex of the MC $u$ quarks of the Higgs (as I look at $H \rightarrow u \bar{u}$ data) to get the "MC PV".

But in full simulation, we see that the reconstructed $x$ is off by one order of magnitude and reconstructed $y$ is off completely.

This might be the source for the discrepancy in d0, as the PV is used as a reference for the displacement.

[andresailer]

It looks like the beamspot was constrained too strongly in the reconstruction of the PV, so if you compare just the d0 with the MC vertex things are looking better?

We need to adapt the beam spot parameters

CLDConfig/CLDConfig/HighLevelReco/JetAndVertex.py

Lines 90 to 92 in cb1fb09

	"BeamSizeX": ["38.2E-3"],
	"BeamSizeY": ["68E-6"],
	"BeamSizeZ": ["1.97"],

[saracreates]

I have not checked yet if using the MC PV in full sim fixes the discrepancy in d0. I will let you know once I have those plots too.

Anyway, the reco PV in full sim seems to need a fix.

[saracreates]

Here the plot with the fit of d0 using the MC PV in full sim: The discrepancy diminishes:

[andresailer]

The changes in the beamspot are not going to resolve the d0 discrepancy.

[saracreates]

Here the plot with the fit of d0 using the MC PV in full sim: The discrepancy diminishes:

@andresailer you say, that the discrepancy in d0 comparing fast and full simulation on MC level that we see here is non negligible?

[andresailer]

It looks significant, doesn't it?

But Leonhard is right that this should be studied in simpler events.

It could be that this is due to whatever assumptions are done in the fast sim, missing material interactions. Or something wrong in the reconstruction of tracks, there is sufficient circumstantial evidence to support that notion as well.

[saracreates]

Hi!

Using the new data with the fixed beam spot constrains did not solve the problem:

While debugging I found an other issue related to the vertex smearing on MC level. As a correct MC vertex is the first step towards a correct reco vertex, I suggest fixing this issue first. I have opened an other issue in dd4hep to discuss this.

[saracreates]

Hi!

The MC vertex issue was fixed (vertex smearing was applied twice).

Still, the reco PV is off, although beam spot parameter constrains seem to have been fixed: #62

Any ideas what might go wrong with reconstructing the PV?

[Zehvogel]

I would naively guess that the problem is this?

CLDConfig/CLDConfig/HighLevelReco/JetAndVertex.py

Line 122 in f9db347

"PrimaryVertexFinder.BeamspotSmearing": ["false"],

See in LCFIPlus:
https://github.com/lcfiplus/LCFIPlus/blob/39cf1736f3f05345dc67553bca0fcc0cf64be43e/src/algoEtc.cc#L80-L103

[saracreates]

Line 122 in f9db347
"PrimaryVertexFinder.BeamspotSmearing": ["false"],

Great idea! Did help for one order of magnitude in y, but did not solve the problem completely:

[Zehvogel]

Hm, I am also not so sure if it really does what we want. It is just the only place in LCFIPlus that I found that even uses the beam size that we supply :/