Fix bug in neutral PFO thinning

!37239 (merged) (October 26, 2020) introduced a bug to ThinNegativeEnergyNeutralPFOsAlg which incorrectly disabled thinning of PFOs if no FlowElement container was provided. This fixes the issue, such that the FlowElement and PFO thinning are correctly independent of each other.

Tagging @jferrand, @miochoa, and @mhodgkin as this fixes the neutral PFO container size increase seen in the November validation.

This merge request affects 1 package:

• PhysicsAnalysis/AnalysisCommon/ThinningUtils

This merge request affects 1 file:

• PhysicsAnalysis/AnalysisCommon/ThinningUtils/src/ThinNegativeEnergyNeutralPFOsAlg.cxx

Adding @mhodgkin as watcher

added Analysis master review-pending-level-1 labels

Also flagging to @amete. Though the size of PFO should have already reduced when we enabled FlowElement production (because the bug is that PFO thinning only took place if the FlowElement container existed).

Thanks @mhodgkin. If I'm not mistaken FlowElements (for now counted under Jet) were enabled on 2020-11-26T2101 but I didn't notice any reduction in the PFO:

I think this is because the thinning isn't actually applied to the FlowElement collections that go into the AOD (@mhodgkin wrote the algorithms that do that, he might know more). I scheduled the thinning as part of the jet reconstruction chain for FlowElements, but we aren't doing any jet reconstruction with FlowElements before the AOD exists.

So, this fix should actually bring the event size back down when it goes in, but I suppose it also raises the question of whether we want to apply this thinning to FlowElements before they're stored in the AOD.

Hi @wbalunas the point of the thinning is to reduce the AOD size. Given we thin PFO in the AOD it follows that FlowElement should have an identical thinning algorithm applied before persistence into the AOD. So another adjustment for that would be needed?

Cheers,

Mark

Hi @mhodgkin -

Yes, I figured that was the case. I think this just means the thinning algorithm should be added to the eflowRec config that produces the FlowElement collections.

-Bill

I don't believe the PFO thinning was scheduled there, its somewhere else. Anyway this algorithm is scheduled already isn't it?

Whether it runs just depends on:

https://acode-browser1.usatlas.bnl.gov/lxr/source/athena/PhysicsAnalysis/AnalysisCommon/ParticleBuilderOptions/python/AODFlags.py#0082

I thought from the above the problem was the FE thinning is only triggered if the jet shallow copy of the FE container exists? Instead it should just use the original container which will exist in the main tier0 workflow? hmm ok I see the neutral FE is never set:

https://acode-browser1.usatlas.bnl.gov/lxr/source/athena/PhysicsAnalysis/AnalysisCommon/ThinningUtils/src/ThinNegativeEnergyNeutralPFOsAlg.h

so we should change the default value to the container name.

Cheers,

Mark

Ah, I see what's going on, the thinning algorithm is scheduled and configured independently from elsewhere in the top JO, not as part of PFO reconstruction. I wasn't aware of that, so I didn't update it to also configure the FlowElement thinning as well (I only did that in the jet config). I'll go ahead and add that in a separate MR following this one.

CI Result SUCCESS (hash 0229e4bd)

	Athena	AthSimulation	AthGeneration	AnalysisBase
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
For experts only: Jenkins output [CI-MERGE-REQUEST-CC7 24557]

looks fine, CI passed, approving

Roman(L1)

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

mentioned in merge request !38836 (merged)

merged

mentioned in commit d2e003d0

added sweep:ignore label