lowpt ranking tuning

[slava77]

The ranking is updated for low pt (pt < 0.9) :

• penalty from *= 1.5 to *= 1.7 of the high pt
• found hit bonus from *= 1.0 to *= 0.9 of the high pt

This update is applied only during building (as in this PR it was checked for the clone-engine) in getScoreStruct method.

The tuning was made based on the initialStep built tracks; the figures of merit considered were the fakerate (decrease) while the number of hits on track is kept from dropping much. More significant changes appear to reduce the number of hits by too much. The original scan of values was done in devel as of #351 and then checked to be consistent on top of #355 as well.

Performance for a few close points

(black is what's proposed in this PR): the fake rate goes down fractionally by 20% http://uaf-10.t2.ucsd.edu/~slava77/figs/mic/mtv/ttbar50_CKF_mkFit-pr355_lowpt-penalty1.7-bonus1.0-tailPenalty1.0_m7b132b5_cb49b711/plots_initialStep.html

The reduction in the number of hits is perhaps still manageable

Compared to ttbar the number of hits in the 0.2-1GeV muon sample is reduced by about a factor of 2 less http://uaf-10.t2.ucsd.edu/~slava77/figs/mic/mtv/10muvlow_CKF_mkFit-pr355_lowpt-penalty1.7-bonus0.9-tailPenalty1.0_m9fde252_cb49b711/plots_initialStep.html

After the general tuning,

the options of applying this update only during building vs the final candidate scoring was checked. Most of the change in the fake rate is from retuning the building part http://uaf-10.t2.ucsd.edu/~slava77/figs/mic/mtv/ttbar50_CKF_mkFit-pr355_lowpt-penalty1.7-bonus0.9-tailPenalty1.0_inCands_m42e27aa_cb49b711/plots_initialStep.html

while just slightly less than a half of the hit loss for vlowpt muons is from the building part (delta mean nhtis -0.08 from building (red -orange), vs -0.11 from the final cand scoring) http://uaf-10.t2.ucsd.edu/~slava77/figs/mic/mtv/10muvlow_CKF_mkFit-pr355_lowpt-penalty1.7-bonus0.9-tailPenalty1.0_inCands_m42e27aa_cb49b711/plots_initialStep.html

The combined performance

in the mkfit "4" iteration variant out of the box:

http://uaf-10.t2.ucsd.edu/~slava77/figs/mic/mtv/ttbar50_CKF_mkFit-4-pr355_lowpt-penalty1.7-bonus0.9-tailPenalty1.0_inStruct_m66c5ff6_cb49b711/plots_ootb.html all tracks

there is in fact a small increase in the duplicate rate

High purity tracks

In the mkfit 7-iter variant

http://uaf-10.t2.ucsd.edu/~slava77/figs/mic/mtv/ttbar50_CKF_mkFit-7-pr355_lowpt-penalty1.7-bonus0.9-tailPenalty1.0_inStruct_m66c5ff6_cb49b711/plots_ootb.html OOB all tracks the changes are somewhat similar; the relative reduction in the fake rate by about 6% at a cost of 0.07 hit

similarly for high purity: the fake rate is now on average below CKF

[slava77]

I added a note about the low-pt muons in the PR description ; more plots for that are in http://uaf-10.t2.ucsd.edu/~slava77/figs/mic/mtv/10muvlow_CKF_mkFit-pr355_lowpt-penalty1.7-bonus0.9-tailPenalty1.0_m9fde252_cb49b711/plots_initialStep.html

[slava77]

following the discussion with Giuseppe, I've updated the PR to reduce the impact on the hit loss, while preserving most of the fake rate reduction. The retuning is applied only during building (as in this PR it was checked for the clone-engine) in getScoreStruct method. A half of the PR description is updated, except for mkfit-4 and mkfit-7 plots. I will add these later.

[slava77]

A half of the PR description is updated, except for mkfit-4 and mkfit-7 plots. I will add these later.

now the description is self-consistently updated

[cerati]

any objection to merge this? I'd like to recalibrate the strip cluster size on top

[slava77]

any objection to merge this? I'd like to recalibrate the strip cluster size on top

we talked about this in the UCSD meeting and the point is that this PR should get the other building cases to be in sync as well. Also, the function argument lowPtTuneSpecial should be renamed to something more related to track building.

[cerati]

ok, thanks. I'll work on top of you branch then

[slava77]

@cerati ... OTOH, all updates are expected to be technical for the default/clone-engine building. So, I think that for physics part you can just use this branch as a reference (at a cost of a rebase needed later).

[cerati]

By the way @slava77 one interesting quantity to check to make sure the decrease in number of hits is justified is the average fraction of associated hits. This can be checked form the DQM files with:

TH1F* h = (TH1F*) _file0->Get("DQMData/Run 1/Tracking/Run summary/TrackBuilding/initialStep_quickAssociatorByHits/assocFraction")
h->GetMean()

[slava77]

By the way @slava77 one interesting quantity to check to make sure the decrease in number of hits is justified is the average fraction of associated hits. This can be checked form the DQM files with:

@cerati How should I interpret it for tracks? Is this fraction times the nTotalHits supposed to be the number of associated hits? If so, I suppose that the figure of merit is the fraction*nTotalHits. Is this correct? (this still leaves a question of how to use it because a product of averages is not the same as the average of a product).

[cerati]

Hi @slava77 , yes I think if you multiply it by nTotalHits you get the total number of associated hits. How to use/interpret it depends on the actual development you are doing - for instance, in my case adding a cluster size cut I can only reduce nTotalHits, so it makes sense to look at the fraction. In your case, changing the score make it more complicated, but at least making sure that the fraction of associated hits does not degrade I think is a good sanity check.

[slava77]

I'm done here, but as we discussed earlier today, the plan was to merge this last due to more ad hoc nature of the update in the ranking, while the other developments are a bit more justified.