-e command line option ignored
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 9 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
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 9 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  eventTree->Draw("px","event==447957"); -e (11956,*,*) is equivalent to root  eventTree->Draw("px","run==11956"); -e (11956,10,*) is equivalent to root  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.
#3 Updated by Mark Messier over 9 years ago
Ack, the dashes all rendered as strikes. My examples should be:
-e (,*,447957) is equivalent to root  eventTree>Draw("px","event==447957"); -e (11956,,*) is equivalent to root  eventTree>Draw("px","run==11956"); -e (11956,10,*) is equivalent to root  eventTree>Draw("px","run==11956&&subrun==10");
#6 Updated by Gavin Davies over 7 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?