Project

General

Profile

Feature #1000

Run/event range

Added by Eric Church over 8 years ago. Updated over 1 year ago.

Status:
Assigned
Priority:
Normal
Assignee:
Category:
I/O
Target version:
Start date:
05/29/2011
Due date:
08/01/2015
% Done:

0%

Estimated time:
24.00 h
Spent time:
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

Related to art - Feature #9594: Accessing a specific event from the command lineClosed07/13/2015

Related to art - Support #7308: -e/--estart command line option not workingClosed11/11/2014

History

#1 Updated by Rob Kutschke over 8 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 over 8 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:
  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.

#3 Updated by Christopher Green over 8 years ago

  • Status changed from Feedback to Accepted
  • Assignee deleted (Christopher Green)
  • Priority changed from Normal to Low

#4 Updated by Walter E Brown almost 8 years ago

  • Tracker changed from Feature to Meeting
  • Priority changed from Low to Normal

#5 Updated by Christopher Green over 6 years ago

  • Tracker changed from Meeting to Feature
  • Due date set to 09/30/2013
  • Category changed from Navigation to I/O
  • Target version set to 1.09.00
  • Estimated time set to 24.00 h
  • Scope set to Internal
  • Experiment - added
  • SSI Package art added

#6 Updated by Christopher Green almost 6 years ago

  • Target version changed from 1.09.00 to 521

#7 Updated by Marc Paterno over 4 years ago

  • Target version changed from 521 to 1.18.00

#8 Updated by Christopher Green over 4 years ago

  • Due date changed from 09/30/2013 to 08/01/2015

#9 Updated by Marc Paterno over 4 years ago

  • Status changed from Accepted to Assigned
  • Assignee set to Paul Russo
  • Start date changed from 02/22/2011 to 05/29/2011
  • Experiment MicroBooNE added
  • Experiment deleted (-)

#10 Updated by Christopher Green about 4 years ago

  • Target version changed from 1.18.00 to 834

#11 Updated by Marc Paterno about 4 years ago

  • Related to Feature #9594: Accessing a specific event from the command line added

#12 Updated by Marc Paterno about 4 years ago

  • Related to Support #7308: -e/--estart command line option not working added

#13 Updated by Marc Paterno about 4 years ago

  • Target version changed from 834 to 2.01.00

#14 Updated by Kyle Knoepfel over 3 years ago

  • Target version changed from 2.01.00 to Vega

#15 Updated by Kyle Knoepfel over 1 year ago

  • Target version changed from Vega to Capella


Also available in: Atom PDF