MessageLogger Tutorial Examples

Enabling LogDebug Messages From One or More Modules

# enablingLogDebugMessages.py
# ------------------------------------

import FWCore.ParameterSet.Config as cms
process.MessageLogger = cms.Service("MessageLogger",
       destinations   = cms.untracked.vstring(                          #1
                                             'myDebugOutputFile'        #2
                    ),
       ,myDebugOutputFile       = cms.untracked.PSet(                   #3
                       , threshold = cms.untracked.string('DEBUG')      #4
                       , default = cms.untracked.PSet(                   
                                        limit = cms.untracked.int32(-1) #5
        ),
       debugModules = cms.untracked.vstring(                            #6
                      'myAnalysisModule')                               #7
)                                                                       #8

# set the number of events
process.maxEvents = cms.untracked.PSet(
    input = cms.untracked.int32(200)
)
 
process.myAnalysisModule = cms.EDAnalyzer('ModuleThatIssuesMessages')
process.anotherModule = cms.EDAnalyzer('ModuleThatIssuesMessages')
process.p = cms.Path(process.myAnalysisModule,
                    process.anotherModule)                              #9

Important Caveat:

By default, LogDebug(...) and LogTrace(...) are pre-processed to become complete no-ops. They are macros set up to disappear from the code completely, unless the symbol EDM_ML_LOGDEBUG is defined at compile time.

So even if you correctly follow all the steps in the below example configuration file, by default you will not see the LogDebug output. To enable this, you can rebuild the relevant package with a scram directive telling it to define this symbol:

      scram b -j8 USER_CXXFLAGS="-DEDM_ML_LOGDEBUG"

Explanation:

In the above example, one file, named myDebugOutputFile.log, would be produced. It will contain all the output which would be there by default (errors and warnings) but also info messages and messages produced by myAnalysisModule calling LogDebug and/or LogTrace.

On line 1, we define a vstring named destinations=cms.untracked.vstring(... . Every confugration file should have this vstring defined; the name destinations is a keyword telling the logger that one or more files for output are going to be created.

On line 2, we name a file destination. In this example, this is the only destination we name.

On line 3, we start a PSet with a name matching one of the destinations we had specified. In this case, that name is myDebugOutputFile. The contents of this PSet will control the behavior of just that destination. The name of the file produced will be taken from the name of the destination; in this case, myDebugOutputFile.log.

On line 4, we are controlling the behavior of this destination. In this case, we are saying that the threshold for responding to messages issues is at the level of DEBUG. This means that this destination will respond to (and output) message issued via edm::LogDebug and anything at least that serious -- this means all messages.

Line 5 tells the logger what limit to use for any message category it has o more specific instructions about. In this case, the value -1 stands for no limit at all. Without this, the limit for unspecified messages at the DEBUG level might be (by default) too low to get the output you wanted.

Line 6 is the key to enabling LogDebug output. Messages at the DEBUG lesvel will ordinarily be as totally ignored as possible, generally not even being examined by an output destination which you might have configured with a threshold of DEBUG.

Line 7 specifies that for the module myAnalysisModule the logger should not suppress the LogDebug (and LogTrace) messages. Note that nothing was said about the module anotherModule so LogDebug messages issued from there will not clutter the output. One could have said

      debugModules = cms.untracked.vstring( '*')

to enable DEBUG messages from every module.

Line 8 completes the configuration of the MessageLogger. The other lines of this example are generic lines to tell CMSrun how many events to process, which modules to use, and so forth.

Line 9 specifies two modules in the path, but only one of these will have DEBUG messages enabled (see line 7).

-- MarkFischler - 31-Aug-2010