Enable ROI vertex usage in TauTrigger + monitor vertex position

Use TauVertexFinder to find ROI based vertex for HLT tau using the the recently introduced "HLT_IDVertex_Tau" vertex container, which is passed explicitly in the "executeVertexFinder" function. Vertex position is also added in the online monitoring (see examples below). Note:

• TauVertexFinder for HLT taus is NOT using TJVA
• changes in TauVertexFinder to bypass retrieving on track selection tool and track-to-vertex association in case of no TJVA

Monitor plots example from online monitoring ( for vertex->Z() plot the Xaxis label is actually z vertex position and not "NROis" -> corrected in the MR):

This merge request affects 4 packages:

• Reconstruction/tauRecTools
• Trigger/TrigAlgorithms/TrigTauRec
• Trigger/TrigValidation/TrigAnalysisTest
• Trigger/TriggerCommon/TriggerMenuMT

Affected files list will not be printed in this case

Adding @goetz ,@martindl ,@ademaria ,@sutt ,@vmartin ,@okumura ,@carquin ,@xiaozhon ,@dzanzi ,@bernius ,@hrussell ,@adbailey ,@malconad as watchers

added Reconstruction Tau Trigger TriggerMenu changes-trigger-counts master review-pending-level-1 labels

mentioned in merge request !42076 (closed)

changed the description

Hi Antonio, so are these vertices OK ? Or do you need anything done ti them ?

Cheers Mark

Hello Mark, I think vertices are working smoothly so far. Do you expect a large spread position in Z? I didn't put the plot in the description, but X,Y vertex position are much narrower distributions and are centered around -0.5

I would expect the z vertex to be distributed the same as the normal collision vertex, ie a Gaussian with width ~ 50 mm. At the moment, we are using the same vertex settings as for the FS vertex, except that we have enabled single track vertices. This means that we still have the tighter hole selection to remove the fakes from the FS which would likely not be needed at all here, so I am adding a flag to allow us to set this on a signature by signature basis.

In principle, it may be useful to relax the track selection further. At some point, you may want to properly tune the vertex parameters to give you the best performance for your specific needs so we can investigate that once we know everything is working. We would expect the x and y distrbutions to be quite narrow, perhaps < 0.1 mm. and with a beamline offset of around 0.5 mm - 0.7 mm depending in the sample.

Although for a tau, that may be smeared a little although I don't know how much by. I believe the tau decay length is ~ 0.1 mm, and I know that very boosted taus can even get beyond the beampipe so I think the x and y spread may be slightly worse than for usual tracks but not by much.

Looking at you "flightpath" plot, if this is the radius of the vertex, then seeing that it is quite narrow with a long tail to the positive side, might be quite reassuring.

CI Result SUCCESS (hash b0ef120f)

	Athena	AthSimulation	AthGeneration	AnalysisBase	AthAnalysis	DetCommon
externals
cmake
make
required tests
optional tests

Full details available on this CI monitor view
Athena: number of compilation errors 0, warnings 0
AthSimulation: number of compilation errors 0, warnings 0
AthGeneration: number of compilation errors 0, warnings 0
AnalysisBase: number of compilation errors 0, warnings 0
AthAnalysis: number of compilation errors 0, warnings 0
DetCommon: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 31008]

marking as urgent since it would be good to have this in the next nightly

added urgent label

added review-approved label and removed review-pending-level-1 label

merged

mentioned in commit 6ebab069

added sweep:ignore label