Fixes for Tesla productions under Stripping28

This MR fixes the issue found in LHCBGAUSS-1108, namely that Tesla was not producing ProtoParticle MCParticle relations tables in 'DST-style' productions, where the MC particles are not filtered.

The issue was a change in the behaviour of how the ChargedPP2MC algorithm treats RootInTES between Stripping26 (DaVinci v41r2p5) and Stripping28 (v41r4p2). The changes were for the better, and Tesla was exploiting the old behaviour in an odd way, but somehow I didn't spot this change when porting the S26 patches to S28.

I'm running a larger validation locally right now, but I'm pretty sure this is the source of the problem. This MR targets 2016-patches with the intention of becoming the v41r4p3 release.

/cc @rmatev @gcorti

Looks good as far as I get the logic.

Thanks. The general idea is that now the relations tables are now always created under /Event/Relations, e.g.

/Event/Relations/Turbo/Proto
/Event/Relations/Hlt2/Long/Protos
/Event/Relations/Hlt2/Protos/Charged

The relations tables are then always copied from these locations to /Event/Turbo/Relations/…. If Tesla().FilterMC is true, then the MC objects the relations tables point to are also copied.

The old logic changed the output location of the relations table maker depending on the value of FilterMC, but this depended on the S26 implementation of the maker, which was a bit gross.

My validations look OK, so this is good to go IMO.

assigned to @apearce

assigned to @erodrigu

merged

mentioned in commit d4c428f0

@apearce, I'm seeing build errors since days, see https://lbnightlies.cern.ch/logs/build/nightly/lhcb-2016-patches/460/x86_64-slc6-gcc49-dbg/DaVinci/, but that's probably some artefact, no? I mean, the patched DaVinci just atop the last 2016-patches release should be ok, no? I'm tempted to go ahead and tag DV.

The failures are for TurboCache which I think we don't need here anyway. So yes I agree, we can tag.

Unfortunately compilation fails so I need to do something about it - https://lbnightlies.cern.ch/release/lhcb-release/build/2351/. Investigating ...

Is it possible to exclude TurboCache from the release?

This, or I can also try for 15 min to backport the working cache from 2017 turbo.

The problem is here anyway; it should read Tesla().Streams = turbo_streams['2016'], or some other valid year, because now TurboStreamProd.streams.turbo_streams is a DataType-indexed dictionary.

The build is picking up the latest version of TurboStreamProd, where the change was introduced recently. So, another option is to pin the version of TurboStreamProd to, say, v4r1p5.

I do not have the appropriate knowledge of the Turbo code but in any case see code such as

from TurboStreamProd.streams import turbo_streams from Tesla.Configuration import Tesla Tesla().Streams = turbo_streams

Seems we were looking at the same piece of code ;-).

Specifying the TurboStreamProd version as you suggest above is a one-line change. No side effects? If OK then I would go this trivial route ... Let me know. Thanks a lot.

This being said, DaVinci v41r4p2 actually depends on TurboStreamProd v4r2p2, not v4r1p5.

Fix is at !87 (merged), and it compiles for me locally

I retagged DaVinci and retriggered a release build ... Thanks for the MR.