FYI @rmatev interested to hear your opinion on this.
As reported awhile ago by @mwhitehe (thanks!), when you run the
HltEfficiencyChecker wizard, if you come across a file that cannot be opened for whatever reason, the trigger & tupling will skip it and keep running, making a perfectly valid tuple for analysis.
ApplicationMgr will however exit with a not-very-descriptive error code 2, and so our
check_call command in
wizard.py will throw a
HltEfficiencyChecker will stop.
This is not ideal behaviour though:
- You may consider the tuple you've made to be perfectly valid since the dodgy file was simply skipped,
- The error code doesn't easily tell you what the problem was - the rest of the log shows the successful completion of a job,
- Grid sites often go down - since the tupling & trigger will naturally just keep going, why can't
I stop short of enforcing any behaviour, and print a more descriptive message if we encounter this. I added the
--ignore-broken-inputs arg so the user can get
HltEfficiencyChecker to keep going if that is what they wish.