21.0 RPVLL filters for displaced Taus added

RPVLL processing filter for displaced Tau searches added.

New Tau Filters targeting hadronically decaying tau leptons from long-lived decays. Minimal implementation: single/di-tau and tau+MET triggers targeting late 2018 data. Only RNN triggers to be used for end-of-2019 reprocessing. Implementation follows what is done for other RPVLL filters.

added 21.0 label

This merge request affects 1 package:

• PhysicsAnalysis/SUSYPhys/LongLivedParticleDPDMaker

Adding @hoide ,@ctreado ,@cohm ,@szambito ,@kdipetri ,@oabouzei ,@ykeisuke ,@jmontejo ,@leejr as watchers

added Analysis review-pending-level-1 labels

Hi @ghamity,

Could you please link to some slides showing some studies for this? In particular it would be great to see the rates you expect, and how well this works for signal, of course :)

Best, Christian

CI Result SUCCESS (hash 48252bb4)

	Athena	AthDataQuality	AthSimulation
externals
cmake
make
required tests
optional tests

Full details available on this CI monitor view
Athena: number of compilation errors 0, warnings 78
AthDataQuality: number of compilation errors 0, warnings 0
AthSimulation: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST 41691]

Hi @cohm , @hoide , @leejr ,

@ctreado commented the following via email just now:

Sorry, I didn't see this thread until now. Yes, this implementation looks good, although if you want to use the TriggerAPI-generated triggers in your trigger list, you have to add the "apitriggers" list to the "triggers" list. This is irrelevant right now, though, since the issue with the TriggerAPI has not been resolved, so the tool should be turned off before reprocessing to make sure old triggers aren't being pulled from old menus. It can be turned off by setting "doRPVLLTriggerAPI" to false. There were some issues shutting it off from the preExec, so it should just be hardcoded for now, here: https://gitlab.cern.ch/atlas/athena/blob/21.0/PhysicsAnalysis/SUSYPhys/LongLivedParticleDPDMaker/python/RPVLLTriggers.py#L194-199. Can we include this in the merge request?

I am not familiar with the TriggerAPI and am hoping we can get some help understanding this situation. If you agree that turning this off in the JOs is the best way to proceed, then @ghamity can you add a commit doing so?

Thanks! Kate

Hi @kpachal,

Your co-convener @jmontejo knows a thing or two about this tool, so he should feel free to correct/complement what I say

The TriggerAPI tool was developed so that triggers wouldn't need to be hardcoded in the trigger-based selections for derivations, DRAWs and DESDs. The idea is you as a client say "I want the lowest unprescaled MET trigger" and the tool picks the right one for each run, resolved at run-time when it looks at the input file and knows what menu was used.

We wanted this for DRAW_RPVLL and Colleen integrated it, but there seemed to be problems still with it. I didn't follow in great detail the last year or so, so I'm not sure what the specific issues were.

Best, Christian

Hi @ctreado ,

I wrote the TriggerAPI tool but I don't know what problems you are referring to, sorry if I missed that.

Was the doRPVLLTriggerAPI flag used for previous reprocessings? It seems that the flags have hardcoded triggers defined and then add more triggers from the API. https://gitlab.cern.ch/atlas/athena/blob/21.0/PhysicsAnalysis/SUSYPhys/LongLivedParticleDPDMaker/python/DVFlags.py

I'd be worried if we used the flag in the past, in case some filters forgot to hardcode triggers, got them from the API, and would lose them now.

Cheers, Javier

Hi all,

Please resolve all open threads/points and then re-add the review-pending-level-1 label.

MLB (L1)

added review-user-action-required label and removed review-pending-level-1 label

Hi @jmontejo , from a glance through various relevant requests this morning I've only seen it turned off (here: https://its.cern.ch/jira/browse/DATREP-156). It did seem as though disabling it worked from the preExec though, or at least that's what was done for the 2018-only reprocessing?

@ctreado can probably confirm if doRPVLLTriggerAPI has ever been used in practice though - I am not entirely confident saying no.

Hi @cohm @jmontejo ,

Just want to make the point that we are bypassing the use of the trigger API tool in my implementation, due to requiring subsets of the lowest unprescaled triggers. I developed the selection using the API tool, but in this merge request, our triggers are hard coded.

@kpachal @ctreado , I can add the lines of code that are being requested. Just want a confirmation on how to do this to the merger request itself. Should I just commit to the same development branch I am trying to merge?

Regards, G

Hi @ghamity, @kpachal,

Sorry for any earlier confusion. I did in fact fix the doRPVLLTriggerAPI function to be able to be turned off and on from the command line, so no additional changes are needed for this in the merge request.

To get the accurate list of triggers for each filter, it is advisable to set 'from LongLivedParticleDPDMaker.RPVLLTriggers import rpvllTrig; rpvllTrig.doRPVLLTriggerAPI=False;' in the preExec for now when running the reprocessing since there is still an issue with the RPVLLTriggers implementation, where the TriggerAPI tool is reading from the wrong trigger menu. But @jmontejo is correct that this flag was not set during the last reprocessing, but if I remember correctly, the TriggerAPI was not even integrated into the RPVLL code until AFTER the reprocessing.

Thanks, Colleen

added review-pending-level-1 label

removed review-user-action-required label

Thanks @ctreado !

@cohm , just to round up the open discussion above, this MR does increase the rate by ~double when the triggers in question are active. But they were only available for around 15 ifb of 2018 data. So the average rate increase resulting from this change, over the full Run 2 data, is about 1%. If you're happy with this, could you resolve the above discussion and we'll move ahead?

Cheers, Kate

Hi all, Please resolve all open threads/discussions and then re-label. Thanks, Pienpen (L1)

added review-user-action-required label and removed review-pending-level-1 label

added 1 commit

• f60a4166 - RPVLL Tau filters: Update (CC) dates to include 2019

Compare with previous version

added review-pending-level-1 label and removed review-user-action-required label

This merge request affects 1 package:

• PhysicsAnalysis/SUSYPhys/LongLivedParticleDPDMaker

Adding @hoide ,@ctreado ,@cohm ,@szambito ,@kdipetri ,@oabouzei ,@ykeisuke ,@jmontejo ,@leejr as watchers

CI Result SUCCESS (hash f60a4166)

	Athena	AthDataQuality	AthSimulation
externals
cmake
make
required tests
optional tests

Full details available on this CI monitor view
Athena: number of compilation errors 0, warnings 0
AthDataQuality: number of compilation errors 0, warnings 0
AthSimulation: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST 41766]

No outstanding issue, moving to L2 review. Pienpen (L1)

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

resolved all threads

added urgent label

I see no problems here, approving.

Pavol [as L2 MR shifter]

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

Hi @ghamity,

Could you also please add ATLAS Robot as developer to your fork (https://atlassoftwaredocs.web.cern.ch/gittutorial/gitlab-fork/#add-your-friendly-build-bot)?

Tadej (L2)

Hi @tadej , just did it. G

Hi @tadej @jmontejo . Is anything holding this up to be merged? I won't be around tomorrow or next week.

It's been approved so I do not see any issues that it shouldn't be merged soon. But it's now up to PROC (@pottgen).

merged

mentioned in commit a09e8b5f

added sweep:done label

added sweep:failed label

Sweep summary
failed:

• master

Hi @tadej ,

I see that there is a sweep:failed flagged activated by the nightly build. Is this an issue? It seems to be related to the master which we did not merge to. I am offline all day today. G

Hi @ghamity, you'll have to manually provide the change for master.

Hi @ghamity ,

Just to clarify - you don't have to deal with this today, and don't have to worry about it in general until r22.

Cheers, Kate

Hi, from the git tutorial [1] :

If, as a developer you know in advance that the merge request you have created cannot be moved to the master branch then set the sweep:ignore label. This will tell the cherry picking script to ignore this merge request.

Note that the terminal state of all production branch merge requests is one of sweep:ignore or sweep:done. If your merge request gets labelled as sweep:failed you must take action:

If the change should be moved to the master branch then adapt the patch and create a new merge request. One useful workflow is to make a new branch from of master, then execute git cherry-pick -m 1 XXX, where XXX is the commit hash of the merge (accessible from the merge request page; -m 1 simply refers to the first of the two parents in the merge). This will identify the cause of the conflict, allowing you to use git’s conflict resolutions tools such as git mergetool -t meld to fix the conflicts.

If the change should just be ignored, make a comment to that effect on the original merge request.

In both cases, unset the sweep:failed label and set the sweep:ignore one signalling that the situation is resolved.

[1] https://atlassoftwaredocs.web.cern.ch/gittutorial/merge-request/#cherry-picking-aka-sweeps

added sweep:ignore label and removed sweep:failed label

mentioned in merge request !28989 (merged)

mentioned in commit 1e705b32