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"
(Or you could place the appropriate defines into the .cc files for code which
you wish to debug.
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