Add FTag event scale factor CP algorithm config

Following the example of the JVT event scale factors, a CP algorithm config for the FTAG event scale factor is introduced here.

FYI @ligang @bdong @krumnack

added Analysis BTagging CPAlgorithms labels

Jenkins please retry a build

hi @tstreble can we make this a sub-block of the FTAG one, or even directly part of the FTAG config block, such that the containerName, btagger and btagWP are set already? Then the user would just pass globalSF: True or something.

Alternatively, we also have a PerEventSFBlock available, which could be repurposed?

added 1 commit

• e748a6ef - Add FTAG event level SF computation in FTagAnalysisConfig

Compare with previous version

added 1 commit

• fc6f7cb3 - Add FTAG event level SF computation in FTagAnalysisConfig

Compare with previous version

marked this merge request as ready

Jenkins please retry a build

resolved all threads

This merge request affects 1 package:

• PhysicsAnalysis/Algorithms/FTagAnalysisAlgorithms

This merge request affects 1 file:

• PhysicsAnalysis/Algorithms/FTagAnalysisAlgorithms/python/FTagAnalysisConfig.py

Adding @krumnack ,@tadej ,@bdong as watchers

added analysis-review-required main review-pending-level-1 labels

CI Result SUCCESS (hash fc6f7cb3)

	Athena	AnalysisBase	AthAnalysis
externals
cmake
make
tests

Full details available on this CI monitor view. Check the JIRA CI status board for known problems
Athena: number of compilation errors 0, warnings 0
AnalysisBase: number of compilation errors 0, warnings 0
AthAnalysis: number of compilation errors 0, warnings 0
For experts only: Jenkins output [CI-MERGE-REQUEST-EL9 4361]

MR looks good thus approving - AR

removed analysis-review-required label

added analysis-review-approved label

removed review-pending-level-1 label

added review-approved label

merged

mentioned in commit ad44bb9d

Actually, coming back to this MR -- the per-event btagSF in this approach does not take into account JVT. Aren't the flavour tagging recommendations in general only valid for jets which pass JVT ?

The question arises also for overlap removal actually.

This would certainly benefit from a follow up by the FTAG group regarding the implementation of the recommendations, as discussed in https://its.cern.ch/jira/browse/AFT-706

FYI @ligang @bdong for FTAG software

At the same time this whole analysis block can be run on jets post JVT selections, no?

Not really, I think the interface of the FTAG block at the moment does not allow you to specify any kind of selection.

It should be possible to run a thinning block in principle to produce a new jet collection.

I think the problem I'm talking about is specific to the YAML interface. You basically cannot call the FlavourTagging outside of the Jet super-block. Which means, you cannot schedule the FlavourTagging block later on jets produced by the thinning block.

Maybe @krumnack and @jolamber have some ideas here ? I guess one option would be to use that new option from !68754 (closed) to schedule a sub-block of a superblock later, so that we are able to pick up JVT and overlap removal.

(EDIT: pasted wrong MR, updated now)

Ok, I didn't follow the whole discussion here, but a couple of points:

1. Absolutely do not use a thinning block in the middle of the CP sequence. That is asking for all kinds of problems. Also, do not try to introduce extra jet containers (or really any extra containers), that is almost always the wrong solution.
2. And using a view container wouldn't even solve the issue. You should be able to achieve the same effect by picking the right selection for the event scale factor block.
3. The issue (as I gathered) is that the event scale factor block comes too early. Essentially the linked MR is meant to allow such re-ordering. The alternative would be to reorder the registration for the specific block in the text configuration, but as a technique that may run out of steam fairly quickly.
4. The linked MR is currently a draft because I asked @jolamber if he could try to implement the functionality in a slightly different way. Essentially I thought it would be preferable to do this at the block level, allowing blocks to ask specifically to be executed after some other block.
5. At some point we may have to be able to split blocks, i.e. schedule different algorithms at different times while configuring them from the same block/options. That is not covered by the linked MR or the new MR @jolamber is preparing. I don't know if that would be needed here.

I made a new merge request (!69002 (merged)) that reorders the blocks at the block level. Both the previously linked merge request and the new merge request allow sub-blocks to be run after blocks scheduled to run at some other point.

Thanks @jolamber, I like this new dependency approach, I agree it's probably more logical to define this at block level, rather than in ConfigFactory.

I like the new MR better too, so from my perspective it can go ahead if others are happy with it.

To be addressed with !69095 (closed)