search

art-framework-suite / art

The implementation of the art physics event processing framework
Other
2 stars 7 forks source link

Run/event range #14

Open knoepfel opened 3 years ago

knoepfel commented 3 years ago

This issue has been migrated from https://cdcvs.fnal.gov/redmine/issues/1000 (FNAL account required) Originally created by Eric Church on 2011-02-22 20:07:44

I don't know if this is already reported as a desired feature. Would like to open a given root input file, as we do now, but dictate that I run over N events that may not be contiguous, as in this N=3 example: {run1,evt1; run212,evt5; run215, evt12}. Here's an example of how they did it at one time in python in mu2e's CMSLite: http://mu2e.fnal.gov/public/hep/computing/ioModules.shtml. Search for "eventsToProcess".

Related issues:

knoepfel commented 3 years ago

Comment by @kutschke on 2011-02-22 20:23:44

Mu2e would like this too. I notice that the CMS supported syntax makes use of the fact that cms does not zero the event number when a new lumi block starts. If any of us decide to zero the event number at a SubRun boundaries, then this facility should support that.

knoepfel commented 3 years ago

Comment by @chissg on 2011-03-08 23:54:42

I will need to do a little more investigation, but:

  1. This functionality was removed during the early days of the migration from the CMS framework because the configuration system did not support the construction of complex objects such as EventIDs.
  2. The rest of the mechanism for handling this appears to be intact.
  3. I believe I have a mechanism by which one can specify a list of events in this way as pairs or triples depending on whether one's experiment requires the subrun to uniquely specify the event (and/or whether one wishes to specify it). The syntax would be: 
    eventsToProcess: [[r1, e1], [r2, e2] ...]

    or

    eventsToProcess: [[r1, s1, e1], [r2, s2, e2] ...]

    It is possible to specify (eg),

    eventsToProcess: [[r1, e1], [r1, s1, e2]]

    and it would work with the caveat that the events would be processed with all the wildcarded events first and all the fully-specified ones last. If you're OK with that, then we can implement this fairly easily.

Let me know if this seems like a reasonable solution.