Split photon identification and isolation flag in the cutflow

At the moment in the bbyy cutflow we are storing the information about the photons passing the ID and iso requirement at the same time. It would be good to split the requirements in order to disentangle the two effects.

Tagging @alwang

added Analysis:bb𝛄𝛄 Code:CutFlow labels

assigned to @lufranco

This is doable, although not trivial. The point is in particular that you need to define some photon working point for the overlap removal. If you want to be able to access the photons without ID and iso, that means that you need to run a working point without those ID through the overlap removal as well, which is going to yield potentially different results from running directly with the ID and iso applied.

If this doesn't bother you, then you could use some

Photon:
  ID: "NoID"
  Iso: "NoIso"
  extra_wps: ["Tight_FixedCutLoose"]

and update your analysis algorithms accordingly to apply the selection only in your SelectorAlgorithm

Note that it would also require to update the config in general to support photons without ID, similar to #163

Hi @tstreble , my plan was to define "loose" photons objects, require the presence of two of them first, then on top of that apply the required tight ID and Iso cuts independently. I think that, if we want to stick to the standard H->yy strategy for the estimation of the fake photons, we would need loose photons anyways in the analysis.

Ok good, then you can just replace NoID with Loose in the previous discussion and it will be a bit simpler.

Hi all, a comment on the way how Easyjet and HGam select "two leading photons to analyse".

In HGam there is a loose selection first applied to photons, then the first two leading photons are selected to be check against the following cut (tight, iso, etc.) (HGam code).

In Easyjet, we keep all photons passing tight+iso and then select the first two leading photons to check for the following cuts (rel pt, myy,...) (Easyjet code).

So strictly speaking the logic of the two framework is different. But it is just a matter of choice.

Thanks @hsut for the clarification! My idea is to try to follow the HGam logic since we would need in the ntuple also the ID and iso photon information to make the further studies.

added DifficultyMedium label

Hi @lufranco , I have made a MR to implement a loose selection for the photons which is used for the overlap removal, you can find all the details here: !651 (merged) . Now the split of the ID and isolation requirement should be easier.
Cheers,
Giulia

Depending on whether you want to have the ID or the iso computed first, you will need to add

extra_wps: 
    - ["Tight", "NonIso"]
    - ["Tight", "FixedCutLoose"]

or

extra_wps: 
    - ["Loose", "FixedCutLoose"]
    - ["Tight", "FixedCutLoose"]

for this

the ID should go first

Thanks a lot @gdigrego ! I was wondering, the overlap removal between objects happens at the level of the PhotonSelectorAlg right? If we want to ensure OR using loose photons (as kindly explained by @tstreble in a previous comment) we should not pass the TightPhotonWP to PhotonSelectorAlg, should we?

Hi @tstreble @gdigrego @lufranco @hsut , Thanks for the help from your discussion and I have tried to get a prilimary version which could statisfy the basic requirement to split the ID and Iso and save the flag shows whether the photons pass Tight ID or Iso (haven't consider the systematic and the proper scale factor). I have submitted a merge request here: !679 (closed), please have a look and hope that is helpful!

I have just opened a MR on the same subject too... Should we coordinate a bit for the next steps in order to avoid duplication of work?

Indeed that would be welcome. Please let us know once you have decided which MR to keep

@yixiang did you agree with @lufranco about which MR to use as follow up?

Hi @tstreble, beacuse of the problems you mentioned I have tagged my MR as draft. Since it is OK for 2X2D sideband study which only consider the nominal case (ignore the SF temporarily), I will go on with the study first. So @lufranco if you would like please go ahead and I will stop now. Hope my work is helpful and we still could cross check the results, thanks!

mentioned in merge request !679 (closed)

mentioned in merge request !681 (merged)

mentioned in merge request !683 (merged)

Addressed with !681 (merged)

closed