Event Display Notes¶
Purpose of an event display (high-level requirements)¶
The purpose of an event display program includes:
- Continuous visual monitoring of events in a control room
- Interactive selection of interesting events from a given input stream (copying the data from the input file to the output file for those events that are interesting)
- Visual inspection of the results of new reconstruction algorithms
- Visual inspection of the results of modification of parameters in existing reconstruction algorithms
The purpose of an event display program does not include:
- Production-level, provenance-tracked reconstruction or histogram/ntuple production program
- Writing new reconstruction results to an output file.
The first client for our event display work is NOvA. However, most if not all experiments will eventually want an event display.
Review of the current NOvA event display program¶
This summary was written on 4 January 2012, based on information from http://nusoft.fnal.gov/nova/novasoft/doxygen/html/EventDisplay_8cxx_source.html and related pages.
The currently NOvA event display program is an art program (using the standard NOvA main) that runs a special EDAnalyzer module, EVD.
EVD::beginJob() uses NOvA-specific code to create the GUI elements for the program. The EVD::analyze() function is empty.
Much of the work of the system is done in the class evdb::EventDisplay, from the package EventDisplayBase. This class is not a module, and inherits from nothing. It registers callbacks to respond to several art signals; each function is named for the signals to which it responds:
The postProcessEvent function is the one that actually displays the event.
evdb::EventDisplay directly interacts with the input source which is being managed by the art::EventProcessor, but full functionality is in place only for random access input sources - and thus only for art::RootSource.
I have not yet found where art::UserInteraction comes into use in the NOvA code.
Problems with the current scheme¶
The art::EventProcessor has much complexity that deals with making sure output files are in a consistent state, in order to deal with merging inputs, and also to deal with writing metadata so that runs and subruns are recorded into all the necessary files. The requirements for the event display do not call for this complexity. Furthermore, this protection clashes with the reconfiguration of reconstruction modules and with re-processing individual events. It seems that art::EventProcessor is not a good match for the application object of an event display application.
The input source is being manipulated outside the control of the class (art::EventProcessor) that is expecting to control it.
The callback mechanism used to invoke the postProcessEvent function may not be sufficiently protected against exceptions being thrown from within the callback.
The user interaction model is very primitive. A big problem is that ParameterSet objects are used to communicate with the modules, but the UI model turns them into strings for processing.
Possible alternative structures¶
- Provide tools (e.g. Schedule, input source interface) in a form suitable for use by experiments to write their own main; the "application class" is provided by the experiment, if at all.
- Provide an alternative application object which manages the facilities needed for an event display, and provides an abstract for the "module" to be written by the experiment that does the display, and provides suitable reconfiguration, facilities, etc.
The requirements on the batch data processing system, especially as we move toward a concurrent processing version, seems sufficiently different from the requirements of the event display program that it seems unlikely a single application class will be suitable for both.