Feature #1632

-e command line option ignored

Added by Mark Messier over 8 years ago. Updated over 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
SSI Package:


I'm trying to use the -e command line option like the following:

nova -c eventdump.fcl -n 1 -e 447957 novadata.root

[novadata.root is found in /nova/app/users/messier/novasoft/art-work/TrackFit]

Rather than skipping to the specified event number, the program processes the first event in the file and stops. Before you ask, yes, the specified event is in the file - I can see it using the event display. Now, one thing is that might be relevant, the file has mixed events from several subruns and the event numbers are not contiguous. I would still expect this feature to work for a file of this sort, however.

BTW, the processing starts with the first event whether I use the -n 1 or not.


#1 Updated by Christopher Green over 8 years ago

  • Category set to Navigation
  • Status changed from New to Feedback
  • Assignee set to Christopher Green
  • Target version set to 1.00.00

I have ascertained that specifying fully the run, subrun and event desired does indeed select the correct event, or the nearest one after it if it does not exist. However, not specifying firstSubRun or firstRun does not tell the system to process the first event with the specified event number regardless of run or subrun number. Indeed, the behavior is somewhat ill-defined: If the obvious, "don't care" behavior of unspecified run and subrun is followed, then what happens if we have the first event being (11955,12,50000) even though there is an event exactly numbered (11956,10,447957)? We could maybe institute a symbol notation for exact, wild, nearest, etc, but I think that would need discussion.

If we have a quorum at this week's meeting I think I'd like to discuss it. Please let me know what you think.


#2 Updated by Mark Messier over 8 years ago

Chris, thanks for the feedback.

I guess I didn't understand the syntax of the -e flag. The help message from "nova --help" says it is the "Event # of the first event to process". Sounds like one number to me. Perhaps more informative would be "(run,subrun,event) numbers of first event to process". If in fact my reading of your feedback is correct.

My 2 cents on how this should work is that it should be kept analogous to selections made on TTree's during root plotting. So, for example:

-e (*,*,447957) is equivalent to root [0] eventTree->Draw("px","event==447957");
-e (11956,*,*)  is equivalent to root [0] eventTree->Draw("px","run==11956");
-e (11956,10,*) is equivalent to root [0] eventTree->Draw("px","run==11956&&subrun==10");

I think this is what most people would expect based on their experience selecting tree entries in root sessions. That is, the input module should only deliver events matching the selection criteria and deliver all the events that match the selection criteria. If no events match, then the job is empty; if one matches, one event is processed; if 100 events match, 100 events go through the job, etc...

This changes the meaning from "first event to process", but that's OK IMHO since we already have --nskip to control the first event.

Thanks again,

#3 Updated by Mark Messier over 8 years ago

Ack, the dashes all rendered as strikes. My examples should be:

-e (,*,447957)  is equivalent to root [0] eventTree>Draw("px","event==447957");
-e (11956,,*)   is equivalent to root [0] eventTree>Draw("px","run==11956");
-e (11956,10,*) is equivalent to root [0] eventTree>Draw("px","run==11956&&subrun==10");

#4 Updated by Walter E Brown about 8 years ago

  • Tracker changed from Bug to Meeting
  • Assignee deleted (Christopher Green)
  • Target version deleted (1.00.00)

#5 Updated by Christopher Green over 7 years ago

  • Tracker changed from Meeting to Feature
  • Status changed from Feedback to Closed

NOvA has agreed internally that this is not high enough in priority to spend further time on this issue.

#6 Updated by Gavin Davies over 6 years ago

We would like to reopen this ticket.
It has been agreed internally that this option will become increasingly useful when we are looking at beam spill trigger files that do not increment events 1-by-1.

Can we understand the difficulty in making this option available?

#7 Updated by Dominick Rocco over 5 years ago

We would still like this ticket to be open. NOvA's triggers are virtually always non-sequential. We waste a lot of time figuring out which --nskip to supply when debugging.

Also available in: Atom PDF