Project

General

Profile

Support #7308

-e/--estart command line option not working

Added by Herbert Greenlee over 4 years ago. Updated 6 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Application
Target version:
Start date:
11/11/2014
Due date:
% Done:

100%

Estimated time:
Scope:
Internal
Experiment:
MicroBooNE
SSI Package:
art
Duration:

Description

Lar command line option -e/--estart seems not to work:

$ lar -c track_rereco_ana.fcl -s crash_471.root -n 100 -e 471
.
.
.
11-Nov-2014 09:50:18 CST Initiating request to open file crash_471.root
11-Nov-2014 09:50:18 CST Initiating request to open file crash_471.root
11-Nov-2014 09:50:18 CST Successfully opened file crash_471.root
11-Nov-2014 09:50:18 CST Successfully opened file crash_471.root
.
.
.
TimeModule> run: 1 subRun: 5 event: 401 rns RandomNumberSaver 0.000386


Related issues

Related to art - Feature #9594: Accessing a specific event from the command lineClosed2015-07-13

Related to art - Feature #1000: Run/event rangeAssigned2011-05-292015-08-01

Has duplicate art - Support #20847: problem with handling '--estart' / '-e' options in art 2.10.04 (Mu2e flavor)Closed2018-09-15

History

#1 Updated by Christopher Green over 4 years ago

  • Tracker changed from Bug to Support
  • Category set to Application
  • Status changed from New to Feedback
  • Assignee set to Christopher Green
  • SSI Package art added
  • SSI Package deleted ()

The -e option is not intuitive, but is behaving as intended: the unspecified EventID items (Run, SubRun) are taken to be (1, 0) unless specified on the command line, so you have told the application to start processing at (1, 0, 471) instead of the (I believe) intended (1, 5, 471). You may have to specify source.firstSubRun: 5 in FHiCL in order to get the desired behavior in this case.

There is an outstanding issue to improve the behavior of the event, subrun and run specification features of the application, but this has never risen high enough on the priority list to be tackled.

Please let us know if the FHiCL workaround does the job for you.

#2 Updated by Kyle Knoepfel over 4 years ago

  • Target version set to 521

#3 Updated by Christopher Backhouse about 4 years ago

The intuitive behaviour I would say is that -e should skip to the first event with that number regardless of the run/subrun. Technically you could have the fcl parameters default to -1 (or completely un-set) to indicate that.

A further extension might be to allow -e aa:bb:cc to set firstRun: aa etc.

Nobody on NOvA uses the -e option because unless your file is run 1 it essentially doesn't work. But if it did work I think it would be very popular. Currently I fairly frequently edit the module I'm debugging to put if(evt.event() != aa) return; into my produce() function, which is clearly not ideal.

#4 Updated by Christopher Green about 4 years ago

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

#5 Updated by Marc Paterno over 3 years ago

#6 Updated by Marc Paterno over 3 years ago

  • Target version changed from 521 to 2.01.00

The time estimate is zero because the work is included in the related issues.

#7 Updated by Kyle Knoepfel about 3 years ago

  • Target version changed from 2.01.00 to Vega

#8 Updated by Kyle Knoepfel about 1 year ago

  • Target version changed from Vega to Capella

#9 Updated by Kyle Knoepfel 10 months ago

  • Has duplicate Support #20847: problem with handling '--estart' / '-e' options in art 2.10.04 (Mu2e flavor) added

#10 Updated by Kyle Knoepfel 10 months ago

  • Target version changed from Capella to 3.02.00

#11 Updated by Kyle Knoepfel 10 months ago

  • Status changed from Feedback to Resolved
  • Assignee changed from Christopher Green to Kyle Knoepfel
  • % Done changed from 0 to 100

See the notes for feature #9594.

#12 Updated by Kyle Knoepfel 6 months ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF