Warning, /FWCore/MessageLogger/doc/defaultsAndControl.txt is written in an unsupported language. File is not indexed.
0001 MessageLogger Default Configuration and Control of Modes
0004 The issue is that we want the defaults currently (as of 6/5/07) taken from
0005 MessageLogger.cfi to be hard-wired, such that jobs not mentioning the logger
0006 at all in configuration get these. There are three difficulties that the
0007 plan presented here will address:
0009 1) When the desired defaults change, it will be a maintenance headache. And
0010 the pace of change in requested defaults is non-negligible.
0012 The use of these defaults is scattered through the MessageLoggerScribe code.
0013 This is one big file to wade through. If it were broken into coherent pieces,
0014 then the problem would change to searching through multiple smaller files;
0015 still a headache.
0017 2) We still need to provide the flexibility currently offered by the .cfg file.
0018 In particular, if a user wants to have completely different destination
0019 outputs, we should not force upon her the default files as well. This
0020 issue is highly relevant for unit testing, and may be important in other
0021 situations too.
0023 3) The appropriate defaults are in some instances defendant on the mode of
0024 running. For instance, batch reco or simulation jobs want reportEvery
0025 for FwkReport to be one; analysis jobs want it to be 100.
0027 The Plan
0030 To address (1), we should place the defaults into one structure
0031 which I will call MessageLoggerDefaults. Its ctor should take as an
0032 argument an enum MessageLoggingMode. To address (3), there should be
0033 an option to cmsRun of -mode which takes values grid, analysis, etc.
0034 One of these (likely grid) will be the default as well.
0036 Then at cmsRun time, we check the mode specified, and send a message to
0037 the scribe indicating that it will need to construct its defaults accordingly.
0039 To address (2), we note that the only serious headaches from these defaults
0040 would be the issue of different sets of destinations, and potential inability
0041 to remove or modify one of the defaulted values. The latter concern is not
0042 really problematic because any configuration settings that do appear will
0043 everride the defautls we are supplying. The destination list issue should
0044 be resolved as follows: There is a default destination list. But if the
0045 destinations vstring is present, then that list will be REPLACED by the one
0046 actually supplied.
0051 A) Use of the MessageLoggerDefaults structure:
0053 A1) By reading the .cfi file and the configure code, decide what is in
0054 the structure. We should make this nested classes, probably.
0056 A2) Create the modes enum, which must live in MessageLogger rather than
0059 A3) Write a ctor based on the existing .cfi file, for the basic default
0062 A4) Modify configure() and the like, to use these defaults. Pay attention
0063 to the issue of empty or non-empty destination list.
0065 A5) Unit test - make certain the behavior with and without the .cfi file
0066 is identical. This unit test can be written in parallel to A1-A4,
0067 and ought to send various sorts of messages so as to exercise the
0068 various settings.
0070 B) Supply of mode
0072 B1) Create a MODE opcode for the MessageLoggerQ, which causes the modes
0073 enum saved for use by configure() and the like to be transmitted.
0075 B2) Make sure the value of mode is going to be sensible even if this
0076 MODE opcode is never used, so that other non-cmsRun jobs won't be
0077 screwed up.
0079 B3) Create a --mode or -m command-line option in cmsRun which uses the
0080 MODE opcode.
0082 B4) Re-run the A5 Unit test
0084 C) Aternative modes
0086 C1) Create at least one alternative mode, for (say) analysis-style
0087 processing. Put this into the enum.
0089 C2) Modify the ctor of to MessageLoggerDefaults to react to this value.
0091 C3) Unit test the alternative mode.