New Features in Old Framework

Issue 2a (Interactivity)

NOvA offline 3Sep2010 Issue-2a

Create a service to manage this. Use both the start event loop and end event loop callbacks.

Version 1

List the active modules and give choice of which to reconfigure. Call reconfigure() on that module.
Go back to the list until the user is done reconfiguring.
In the end event loop, allow for reprocessing the current event, go back to start of file, or continue with next event.

Our initial test will pick a particular module to reconfigure.
In our test module, we will increment a known parameter at the start event loop in response to the reconfigure.
The "interactive service" will request reprocessing of the current event.
Do this for five or so reconfigurations to the parameter.

See FWCore/Services/src/SimpleInteraction.* for an example of user input from the terminal.
See FWCore/Services/interface/UserInteraction.h for some documentation of the API to cause the reconfiguration and continued processing.
See FWCore/Integration/test/ and for examples of making it go.

Version 2 (if necessary)

Use parameter set objects and modify their contents instead of just calling the reconfigure() of the

Nice to have a bit in the output file that marks the data in the file as being built with this interactive mode.
Alternatively, outlaw the creation of an output module when the interactive mode is active.

Issue 2b (Slicer)

NOvA offline 3Sep2010 Issue-2b

We are looking for a reasonable starting point for the inheritance issue.
For the inheritance issue below, could you deal with having the following constraints
on the implementation:

1. put into the event, the collection<Track> or vector<Shower> (concrete collections)
2. extract as View<Prong> from the event for use
3. require the base class Prong to have a virtual destructor.

I think that (1) is already what you have below.

The next item (2) means that for grabbing
the elements in the base type form, you end up with a different kind of collection object
from the 'get' on the event.

In the current system, are you required to have the ROOT dictionary around for all the
base and derived types or just the base type?

Can we allow the ROOT dictionaries to
be around for the concrete types being read? This is largely behind the scenes.

All this is fine with Brian.


The view stuff works as tested in the integration test directory using
We still need an example using the Prong, Track, and Shower to be constructed.

Issue 2c (Input)

NOvA offline 3Sep2010 Issue-2c

NOvA Issue-2c Implementation Proposal