What to do about PILEUP_NTUP inputs for a RECAST workflow?

RECAST
#1

I am posting here an exchange which took place on the ATLAS Analysis Preservation Mattermost channel, since it may come in handy for future users.

Louie

Is there a standard way to deal with pileup reweihting for new samples when RECASTing an analysis?
What I mean is, if one tries to use a brand new signal sample (which is the eventual goal of all RECAST-preserved workflows I suppose!) which does not yet have an NTUP-pileup file, what’s the protocol?

Is the idea that both the input DAOD and the NTUP_PILEUP files should be provided as inputs?

Answer:

there are 2 standard ways to do this

  1. rely on auto-discovery from cvmfs
  2. have them as explicit input. This option is as we don’t want to rely on cvmfs far into the future.

In any case the most inportant thing is to document the choice made in the Readme of the RECAST workflow.

1 Like
Different inputs for RECAST
#2

This is a good question, so thanks for asking it, @lcorpe.

Following up on this in general, @lheinric has also noted that this answer also applies to the question of where to take the new signal cross section from. That is, either from CVMFS via the PMG tool or from an explicit parameter.