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

Problems with parameterized magnetic field #124

Open
1 task
kmcdermo opened this issue Jan 30, 2018 · 8 comments
Open
1 task

Problems with parameterized magnetic field #124

kmcdermo opened this issue Jan 30, 2018 · 8 comments
Assignees

Comments

@kmcdermo
Copy link
Collaborator

As we have seen a few times now, the efficiency for both building and backward fit degrades when the parameterized magnetic field is turned on. It seems to be affecting the transition region the most, and not as noticeable elsewhere.

There have already been some ideas on how to check what is happening. I wanted to post this here for quick feedback. Please feel free to add insights as it comes.

  • Check the value of magnetic field from what we expect to what is actually computed for each propagation.

For reference, I am linking the delta for the magnetic field map between a static 3.8 T field and the parameterized one made from a simple macro (magfield.C): https://kmcdermo.web.cern.ch/kmcdermo/keep_old_mictrk/magfield/fieldmap/

@osschar
Copy link
Collaborator

osschar commented Jan 30, 2018

Looking at your plot, there is no r dependence (I know we only use Bz), I think it was in the code, let me check. Oh, it is there, but the a parameter is e-11 so probably to small to notice.

` // Config for Bfield. Note: for now the same for CMS-2017 and CylCowWLids.
constexpr float Bfield = 3.8112;
constexpr float mag_c1 = 3.8114;
constexpr float mag_b0 = -3.94991e-06;
constexpr float mag_b1 = 7.53701e-06;
constexpr float mag_a = 2.43878e-11;

inline float BfieldFromZR(const float z, const float r)
{
return (Config::mag_b0zz + Config::mag_b1z + Config::mag_c1)(Config::mag_arr + 1.f);
}
`

@kmcdermo
Copy link
Collaborator Author

To make the comparison explicit, look at the following directories:

CMSSWtrack track-param matching w/ param b-field 10mu HS

image

CMSSWtrack track-param matching w/ static b-field 10mu HS

image

It seems with the parameterized field is turned on, the loss of efficiency is at around |eta| = 1.0, but improves around |eta| = 1.8.

@kmcdermo kmcdermo self-assigned this Feb 22, 2018
@kmcdermo
Copy link
Collaborator Author

I will trace a few tracks and see.

@areinsvo
Copy link
Collaborator

areinsvo commented May 8, 2020

Revisiting this issue:
Current head of devel (after PR252) vs
turning on parametric b field vs
turning it on only for interlayer propagation vs
turning it on only in the endcaps.

As you can see, the performance is slightly worse for the parametric b field, but the difference is not nearly as large as it was two years ago. This is definitely worth including in the list of improvements for the new tuning.

Head of devel (constant b field)
baseline_eff

Parametric b field
paramBfield_eff

For what it's worth, I did double check and compare our implementation to that in CMSSW and everything seems consistent.

@areinsvo
Copy link
Collaborator

One more set of plots before I add this to Pandora's Box. I ran mkFit within CMSSW with the parametric B field turned on for inter-layer propagation only (orange) or inter-layer propagation and the backward fit (black). Nominal CMSSW (blue) and mkFit (red) are also shown. The full set of plots can be found here.

The effects are mostly within the noise, except for the pt residuals with respect to eta:
Screen Shot 2020-05-20 at 3 27 47 PM

The residuals in the endcaps get closer to CMSSW but further from 0. This is contradictory to what we see in our standalone plots, where the pt diffs improve (see below). The difference probably comes from the details of the CMSSW final fit, and it probably isn't worth investigating further now. Although it would be really useful to have plots of pt resolution vs eta in our standalone validation.

Constant b field:
SKL-SP_CMSSW_TTbar_PU50_bestmatch_dinvpt_build_pt0p0_SIMVALSEED

Parameterized b field used for interlayer propagation:
SKL-SP_CMSSW_TTbar_PU50_bestmatch_dinvpt_build_pt0p0_SIMVALSEED-1

The timing is essentially identical with and without the parametric b field, at least when using a single thread within CMSSW.

@slava77
Copy link
Collaborator

slava77 commented May 22, 2020

The residuals in the endcaps get closer to CMSSW but further from 0. This is contradictory to what we see in our standalone plots, where the pt diffs improve (see below).

I'm trying to understand how to match the two plots: one is deltaPt/ptSim (dimensionless), while the other is deltaPt/(ptSim*ptReco) (in units of 1/GeV). Wild-guessing an average pt of 2 GeV, I should be looking at the bias/mode "feature" of about 0.01/GeV in the mkFIt validation d(1/pt) histogram.
For some more consistency it would be best to match the bins and variables so that we are not trying to compare tails in one case and core in the other and if these may differ.

@slava77
Copy link
Collaborator

slava77 commented May 22, 2020

For some more consistency it would be best to match the bins and variables so that we are not trying to compare tails in one case and core in the other and if these may differ.

oh, and there is an obvious eta dependence part: the concern in the comparison with the MTV is localized in the endcap, while the mkFit val plot is integrated for all eta

@areinsvo
Copy link
Collaborator

@slava77 I agree, these plots are not an apples-to-apples comparison, so maybe it's overstating it to say that the two sets of plots are contradictory. All I meant was that the pt diffs get better in our standalone validation, but the only noticeable effect in MTV is that the pt residuals get worse. As I mentioned earlier, it would be really useful to have plots of pt resolution vs eta in our standalone validation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants