Non-physics parameter handling

Each of the modules we've opened while looking through the NOvA code for examples contained configuration parameters that do not affect physics, but are nonetheless very important for debugging and understanding the current state of processing. The typical example is "DebugLevel" and "VerbosePrintLevel". Placing these into to physics configuration parameter section is a bad solution, because they become a permanent part of the provenance for that module.

The solution to this problem is to move all non-physics parameters out of the physics parameter sets. To do this, we propose creating a new subsection in the services block named "non_physics_options" (feel free to suggest something better). This parameter set will be passed to each of the modules as a second constructor parameter, if this constructor exists. The substructure of this parameter set is up to the developers and the experiment. There can be a high-level debug level and module type or instance debug levels within it.

Unanswered questions: How easy is it to permit one and two argument constructors for the modules?
Answer: unknown how to do this. might be impossible.

Brian mentioned that proper use of the message logger might solve the problem.
Multiple people pointed out that these debug level might still be useful because unnecessary calculations might be performed at higher debug levels.
Mark is afraid of bad performance of message loggers.

In the end, this feature was viewed as adding too much complexity for little gain. They will not trust to metadata for physics results anyway and will not be comparing jobs with different debug levels. The general solution is not what they want for this.

The solution for this is to use the LogDebug and LogVerbose functions of the message facility to do the work of the "untracked parameters".