Decorations trying to be set without configurability

[kratsg]

BasicEventSelection is an abuser - it sets decorations like mcEventWeight assuming it can do that. If someone made a mini-xAOD using us, this will break the code. We have to allow the user to customize the configuration of the decoration and/or allow for the decoration to be configurable or not (eg: a global m_setDecorations argument in xAH::Algorithm.

[mmilesi]

Hi @kratsg,

I agree on having that configurable.

On a more general basis, what if a user wants to create a mini-xAOD which is augmented with some decorations (e.g., LH ID for electrons...) and then re-run on it with xAH? Are you saying it's not possible to do this?

[kratsg]

Nope.

You can't change existing decorations because they become auxdata in the mini-xAODs. You can add new ones of a different name, but can't change ones set in a previous run.

This is a RootCore thing however. On Sun, Dec 13, 2015 at 16:41 Marco Milesi notifications@github.com wrote:

Hi @kratsg https://github.com/kratsg,

I agree on having that configurable.

On a more general basis, what if a user wants to create a mini-xAOD which is augmented with some decorations (e.g., LH ID for electrons...) and then re-run on it with xAH? Are you saying it's not possible to do this?

— Reply to this email directly or view it on GitHub https://github.com/UCATLAS/xAODAnaHelpers/issues/401#issuecomment-164314972 .

[kratsg]

On a more general basis, what if a user wants to create a mini-xAOD which is augmented with some decorations (e.g., LH ID for electrons...) and then re-run on it with xAH? Are you saying it's not possible to do this?

In this particular scenario -- the way to get around it is to provide more configurability:

1. Allow for a global flag determining whether or not to apply decorations
2. Allow for a decoration name prefix to customize the prefixes for all the decorations being set

Both of these could be global algorithm options put in xAH::Algorithm