Feature #1000: Run/event range - art - Fermilab Redmine

Feature #1000

Run/event range

Added by Eric Church about 10 years ago. Updated over 1 year ago.

Status:

Assigned

Priority:

Normal

Assignee:

Category:

I/O

Target version:

Capella

Start date:

05/29/2011

Due date:

08/01/2015

% Done:

Estimated time:

24.00 h

Spent time:

12.00 h

Scope:

Internal

Experiment:

MicroBooNE

SSI Package:

art

Duration: 1526

Description

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

History

#1 Updated by Rob Kutschke about 10 years ago

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.

#2 Updated by Christopher Green about 10 years ago

Category set to Navigation
Status changed from New to Feedback
Assignee set to Christopher Green

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

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.
The rest of the mechanism for handling this appears to be intact.
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.