Microboone mu2e framework discussion 322010

See [[public:MicrobooneBuildRequirements]] in the public project.

When could this be done? (Need to talk with Mark)

  • 2 month milesstone - phase I requirements * 6 month milestone - * end of May - stable or frozen area needed for summer students

framework name

Name of the framework is a problem: BEAF, RALF

Event sections

The three level hierarchy is good enough.
The luminosity_section identifier is bad and should be subrun.

parameter set language

The python stuff is hard to understand. It is hard to learn.

The LQCD parameter set language would be better. Preprocessing to do inclusion or replacement.

The FMWK allows for overriding default set with new values.
Allows for defining a parameter and merging in a lower-level set of name/values in.

Rob asked for a translation from a python config script to the new herber JSON-like parameter set language.

will use comments to contain things like description, unit, and range of the parameter
(Marc and I discussed retaining the latest comment in the database)

Should we allow for adding parameters to a nested parameter set.
Currently the "inheritance model" of FMWK is to merge values in and not do the append.
Append does not seem to be a good thing to support because of the extra syntax it requires
in the language.
Looks like a replacement syntax is necessary. Can this be does by a preprocessor?

Should this be a variable substitution problem?

Current FMWK allows for definition of path processing.

Event display: they have a "service" that is a basic toolkit for controlling the framework and also
providing a graphics pad for displaying something. Rob points out that the geometry is not ROOT
and this ROOT based event display tool will not automatically display detector geometry. The display
toolkit is used for geometry display, for hit histogram display, and also for other things.
The current FMWK-base graphics thing is a separate executable that creates instances of the FMWK
components and runs them.

A new tracking algorithm added would need to modify the "draw track"
function of the reconstruction algorithm object. The track base class uses
implementation inhertance to give a default set of variables to fill.

Rob and Brian indicate that the demand-driven processing is interesting and somewhat neat, but
not necessary and may be difficult to explain. Rob points out that the processing will be
easy for quite a while. Brian wants to make sure it will work.

more stuff that I missed...