Allow the usage of "direct" extrapolation for Fast Electron like offline/HLT
Allow to use direct extrapolation for Fast Electron like offline/HLT.
Can be enabled by setting useCaloInfoInExtrap to true
Gaudi::Property<bool> m_useCaloInfoInExtrap{
this, "useCaloInfoInExtrap", false,
"use knowledge of the cluster in extrapolation"};Perhaps some expanations are in order.
In offline/HLT (they are the same code ) over the last couple of years we moved to a "direct" extrapolation to the known sampling (known since we target a specific cluster not something "arbitrary" so we have a "constrain").
More specifically the "caloExtension" method call it A (that is used in the Fast Electron Re Algo) does :
- An extrapolation all the way to the exit of the calo (so quite a bit of distance we do not need, EMB3 and full hadronic ...)
- While doing "navigation" as does not target a specific surface, but need to find where it goes.
- Doing muon material effect (in principle the electron has most probably showered somewhere soon after entry so we do not track a "single particle")
Although none of the above are "wrong"...
The problem we have is more like "please extrapolate directly to a surface somewhere in the middle of the second sampling given this cluster".
- So no need to go all the way out and then use just one intersection.
- No need to do navigation to figure where we go
- No need to do multiple scattering in the full calo volume.
Since a couple of years we can do just this (we could also do it 6-8 years ago but lets say the ability was lost at some point between ...)
So call that caloExtension method B make a surface and target it "directly"...
- I can have very well have nuked this implementation ... (i.e will not run will nuke the ouput beyond recognition)
- Even if not since we match in a window I kind of doubt we will have binary equility so some counts will change somewhere.
- One naively would prb expect something like
+/-1in the relevant "steps" (like some edge effect or extrapolations getting lost for low pt tracks in the older way)
Anyhow @damazio @eegidiop this is what I meant this can be done much faster and like offline/HLT.
Ping also @safarzad and @sutt (as asking me what we do to match calo is one of his "usual" ;) )
I do not have the full "machinery" for this part of out code. By faster here I have seen more 2x-3x in offline/HLT. And offline/HLT use this caloExtension method so ...
Merge request reports
Activity
This merge request affects 1 package:
- Trigger/TrigAlgorithms/TrigEgammaRec
This merge request affects 4 files:
- Trigger/TrigAlgorithms/TrigEgammaRec/CMakeLists.txt
- Trigger/TrigAlgorithms/TrigEgammaRec/python/TrigEgammaFastElectronConfig.py
- Trigger/TrigAlgorithms/TrigEgammaRec/src/TrigEgammaFastElectronReAlgo.cxx
- Trigger/TrigAlgorithms/TrigEgammaRec/src/TrigEgammaFastElectronReAlgo.h
added Egamma Trigger master review-pending-level-1 labels
-
Athena externals 
cmake make tests 
Full details available on this CI monitor view. Check the JIRA CI status board for known problems
removed review-pending-level-1 label
This looks very interesting, and in fact seems to increase slightly the counts which may presumabluy increase the efficiency. To test this properly, we would need this in the release, but in case it changes the performance in undesirable ways would there be any way to control using this behaviour or the original behaviour with a flag ? Or would the changes be too extensive ?
Cheers Mark
nope is not too extensive as basically is calling m_tool->method( without cluster info) vs m_tool->method(with cluster info) .
So can add back the old . You want a flag I guess I can name it "useCaloInfoInExtrap" .
I use the EMCaloExtension config that has a bit different Extrapolator config than the muon one (not sure why that was picked...) but this might not be so relevant for this call or I can modify .
As a historical note @damazio had complained many years ago for the then "new" method being slow. Formally what I do here is what was happening also in the past, stopped happening, and now is done again in offline/HLT (common) so is a "new old " method. I just did not realize that this possible cpu improvement can not be picked automatically in fast electron Rec as is not "common" code.
Edited by Christos Anastopoulos-
btw [!48585 (merged)]
is what I mean much faster, egamma Rec Builder is the offline / HLT where we extrapolate tracks to clusters to do the "pre-electrons". I guess you can see why I expect 2-3x faster is possible
Edited by Christos Anastopoulos added 1 commit
- c06b38b3 - Add the next extrapolation strategy as optional, default false
-
This merge request affects 1 package:
- Trigger/TrigAlgorithms/TrigEgammaRec
This merge request affects 4 files:
- Trigger/TrigAlgorithms/TrigEgammaRec/CMakeLists.txt
- Trigger/TrigAlgorithms/TrigEgammaRec/python/TrigEgammaFastElectronConfig.py
- Trigger/TrigAlgorithms/TrigEgammaRec/src/TrigEgammaFastElectronReAlgo.cxx
- Trigger/TrigAlgorithms/TrigEgammaRec/src/TrigEgammaFastElectronReAlgo.h
-
I need to see the CI as I use the EMCaloExtensionTool rather the "default" (which is designed for muons I think although I hope we are not picking landau e loss ... ).
If something still changes (not very likely if I recall the diff) I might know where it comes (Extrapolator configs are not "simple"). In which case I will need to do something a bit "specific" in the cfg.
Assuming I did not mis-copy the old code .... of course ... so lets wait the CI
Edited by Christos Anastopoulos -
Athena externals cmake make tests Full details available on this CI monitor view. Check the JIRA CI status board for known problems