Rebasing data-set/event identifiers

[knoepfel]

One of the complaints about art is that a framework job has no way of handling multiple events with the same identifier. Clearly, the framework must be able to distinguish between events. However, consider two input files from different simulated datasets:

• Background file: Run 1, Subrun 0, Events [0, 1000)
• Signal file: Run 1, Subrun 0, Events [0, 1000)

A user cannot easily run a framework job with both of these files due to the duplicate event numbers, even though the events are unrelated.

With the new framework, it should be possible to rebase event numbers, so that both files can be used in the same framework job. Rebasing in this case means prepending the identifiers with another identifier (e.g.):

• Background events: Dataset "background", Run 1, Subrun 0, Events [0, 1000)
• Signal events: Dataset "signal", Run 1, Subrun 0, Events [0, 1000)

thus removing the identifier collision.

It is not clear that doing the opposite of a rebase (i.e. removing an identifier prefix) should be supported.

[marcpaterno]

In the collider world, a common practice is to merge together detector readout "real data" taken with a minimum-bias trigger and simulated "signals" (or even several simulated "backgrounds"). This process seems to be an instance where the opposite of rebasing might be useful.

Does DUNE have the need for this sort of thing?

[knoepfel]

I believe DUNE does need such a thing. For art, such merging has been done by mixing a "primary" event (whose identifier cannot be duplicated by any other event) with secondary events, whose identifiers are mostly inconsequential.

We might decide, however, to achieve such overlays/merges/mixing a different way with the new framework. So I agree that the opposite of rebasing may be useful; it's just not clear to me yet that it is.