Functions | |
| These are in mini functions in MessageService src MessageLogger such as | preModule (Sometimes the module name is modified, as in:MessageDrop::instance() ->moduleName=curr_module_+"{ctor}";and we shall want to introduce some sort of consistancy on that.) Note that any function that tries to do this with a module must be supplied(in its signature) with const ModuleDescription &desc.preModule and its brethren are not names known to the framework.They become relevant because in the MessageLogger ctor we have lines like iRegistry.watchPreModule(this |
| iRegistry | watchPostModule (this,&MessageLogger::postModule) |
| iRegistry | watchPreModuleConstruction (this,&MessageLogger::preModuleConstruction) |
| iRegistry | watchPostModuleConstruction (this,&MessageLogger::postModuleConstruction) |
| the full set is shown in Appendix B the code for the module creates a class derived from | EDAnalyzer (see EDAnalyzer.h in the Framework package).This could |
| See appendix A for details of module types other than EDAnalyzer EDAnalyzer has the virtual following void EventSetup const &virtual void | beginJob (EventSetup const &) |
| virtual void | beginJob () |
| virtual void | endJob () |
| virtual void | beginRun (Run const &, EventSetup const &) |
| virtual void | endRun (Run const &, EventSetup const &) |
| virtual void | beginLuminosityBlock (LuminosityBlock const &, EventSetup const &) |
| virtual void | endLuminosityBlock (LuminosityBlock const &, EventSetup const &) |
| virtual void | respondToOpenInputFile (FileBlock const &fb) |
| virtual void | respondToCloseInputFile (FileBlock const &fb) |
| virtual void | respondToOpenOutputFiles (FileBlock const &fb) |
| virtual void | respondToCloseOutputFiles (FileBlock const &fb) |
| for in the course of each when the analysis path comes to this the | analyze () method gets called by the framework.But this is actually a sandwich of up to 2S+1 calls |
| for in the course of each when the analysis path comes to this the including up to two for each then that function is | called (In the MessageLogger, we register preModule in this way.) b) analyze() is called.c) If the service registers watchPostModule function |
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is | called (In the MessageLogger, we register postModule in this way.) So for each of the"life-cycle-events" |
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of we should do whatever is appropriate in terms based either on module label OR on a generic for this life cycle event In rare special ML activity like triggering a summary We should establish these in the pre and probably should restore them in the post although under the assumptions that we know all the cycle and handle each pre and that nothing of interest occurs in the frame work BETWEEN post this and pre we could take a shortcut and do without the post callbacks I should probably just make those conditional code A few general routines should label declareRunEvent(string) declareRunEvent(EventID)-----------------------------------------------------------------Appendix A | writeLuminosityBlock (LuminosityBlockPrincipal const &lb)=0and openFile(FileBlock const &fb) |
| virtual void | beginOfJob () |
| virtual void | startingNewLoop (unsigned int)=0 |
| virtual Status | duringLoop (const edm::Event &, const edm::EventSetup &)=0 |
| virtual Status | endOfLoop (const edm::EventSetup &, unsigned int iCounter)=0 |
| virtual void | endOfJob () |
| debug enabled based on file_close watchPostCloseFile *AfterFile Activities having one argument in which is a string const &and is not the module name These need to leave RunEvent alone watchPrePathBeginRun that is a ModuleDescription const &watchPreModuleConstruction *nominal | ctor (also validation check) watchPostModuleConstruction *"AfterModConstruction"watchPreModuleBeginJob *nominal+"@beginJob"watchPostModuleBeginJob *"AfterModBeginJob"watchPreModuleEndJob *nominal+"@endJob"watchPostModuleEndJob *"AfterModEndJob"watchPreModule *nominal watchPostModule *"PostModule"watchPreModuleBeginRun *nominal+"@beginRun"watchPostModuleBeginRun *"AfterModBeginRun"watchPreModuleEndRun *nominal+"@endRun"watchPostModuleEndRun *"AfterModEndRun"watchPreModuleBeginLumi *nominal+"@beginLumi"watchPostModuleBeginLumi *"AfterModBeginLumi"watchPreModuleEndLumi *nominal+"@endLumi"watchPostModuleEndLumi *"AfterModEndLumi"watchPreSourceConstruction *nominal(also validation check) watchPostSourceConstruction *"AfterSourceConstruction" |
Variables | |
| How the MessageService Sets Up the Module Name This document describes how the module | name |
| How the MessageService Sets Up the Module Name This document describes how the module and any suppression | information |
| How the MessageService Sets Up the Module Name This document describes how the module and any suppression gets where the logger needs | it |
| How the MessageService Sets Up the Module Name This document describes how the module and any suppression gets where the logger needs in response to some function in a module getting to the point where it is about to be called The key action in the MessageService itself is a sequence link | curr_module_ = ":" |
| descToCalcName_ [&desc] =curr_module_ | |
| messageDrop | moduleName = curr_module_ |
| messageDrop | debugEnabled |
| These are in mini functions in MessageService src MessageLogger | cc |
| These methodes of iRegistry are found in ActivityRegistry h in the ServiceRegistry | package |
| the full set is shown in Appendix B | Meanwhile |
| the full set is shown in Appendix B the code for the module creates a class derived from for different sorts of | modules |
| See appendix A for details of module types other than EDAnalyzer EDAnalyzer has the virtual following void | functions |
| So | |
| for | example |
| for in the course of each | event |
| for in the course of each when the analysis path comes to this | module |
| for in the course of each when the analysis path comes to this the including up to two for each | service |
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of we should do whatever is appropriate in terms | of |
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of we should do whatever is appropriate in terms based either on module label OR on a generic for this life cycle event In rare | cases |
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of we should do whatever is appropriate in terms based either on module label OR on a generic for this life cycle event In rare special ML activity like triggering a summary We should establish these in the pre | callback |
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of we should do whatever is appropriate in terms based either on module label OR on a generic for this life cycle event In rare special ML activity like triggering a summary We should establish these in the pre and probably should restore them in the post although under the assumptions that we know all the cycle and handle each pre | correctly |
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of we should do whatever is appropriate in terms based either on module label OR on a generic for this life cycle event In rare special ML activity like triggering a summary We should establish these in the pre and probably should restore them in the post although under the assumptions that we know all the cycle and handle each pre and that nothing of interest occurs in the frame work BETWEEN post this and pre | that |
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of we should do whatever is appropriate in terms based either on module label OR on a generic for this life cycle event In rare special ML activity like triggering a summary We should establish these in the pre and probably should restore them in the post although under the assumptions that we know all the cycle and handle each pre and that nothing of interest occurs in the frame work BETWEEN post this and pre we could take a shortcut and do without the post callbacks I should probably just make those conditional code A few general routines should | suffice |
| InputSource is somewhat different and EDLooper has a slightly different | set |
| Appendix | B |
| Appendix that is a string const &watchPrePathBeginRun watchPrePathEndRun watchPrePathBeginLumi watchPrePathEndLumi watchPreProcessPath The following activities have one argument by the time the module specific code is reached In each of these that is a ModuleDescription const &watchPreModuleConstruction watchPostModuleConstruction watchPreModuleBeginJob watchPostModuleBeginJob watchPreModuleEndJob watchPostModuleEndJob watchPreModule watchPostModule watchPreModuleBeginRun watchPostModuleBeginRun watchPreModuleEndRun watchPostModuleEndRun watchPreModuleBeginLumi watchPostModuleBeginLumi watchPreModuleEndLumi watchPostModuleEndLumi watchPreSourceConstruction | watchPostSourceConstruction |
| Appendix that is a string const &watchPrePathBeginRun watchPrePathEndRun watchPrePathBeginLumi watchPrePathEndLumi watchPreProcessPath The following activities have one argument by the time the module specific code is reached In each of these that is a ModuleDescription const &watchPreModuleConstruction watchPostModuleConstruction watchPreModuleBeginJob watchPostModuleBeginJob watchPreModuleEndJob watchPostModuleEndJob watchPreModule watchPostModule watchPreModuleBeginRun watchPostModuleBeginRun watchPreModuleEndRun watchPostModuleEndRun watchPreModuleBeginLumi watchPostModuleBeginLumi watchPreModuleEndLumi watchPostModuleEndLumi watchPreSourceConstruction we describe the | arguments |
| Appendix that is a string const &watchPrePathBeginRun watchPrePathEndRun watchPrePathBeginLumi watchPrePathEndLumi watchPreProcessPath The following activities have one argument by the time the module specific code is reached In each of these that is a ModuleDescription const &watchPreModuleConstruction watchPostModuleConstruction watchPreModuleBeginJob watchPostModuleBeginJob watchPreModuleEndJob watchPostModuleEndJob watchPreModule watchPostModule watchPreModuleBeginRun watchPostModuleBeginRun watchPreModuleEndRun watchPostModuleEndRun watchPreModuleBeginLumi watchPostModuleBeginLumi watchPreModuleEndLumi watchPostModuleEndLumi watchPreSourceConstruction we describe the Run | Event |
| Appendix that is a string const &watchPrePathBeginRun watchPrePathEndRun watchPrePathBeginLumi watchPrePathEndLumi watchPreProcessPath The following activities have one argument by the time the module specific code is reached In each of these that is a ModuleDescription const &watchPreModuleConstruction watchPostModuleConstruction watchPreModuleBeginJob watchPostModuleBeginJob watchPreModuleEndJob watchPostModuleEndJob watchPreModule watchPostModule watchPreModuleBeginRun watchPostModuleBeginRun watchPreModuleEndRun watchPostModuleEndRun watchPreModuleBeginLumi watchPostModuleBeginLumi watchPreModuleEndLumi watchPostModuleEndLumi watchPreSourceConstruction we describe the Run triggers MSqSUM watchJobFailure *jobFailure triggers MSqSUM watchPreSource *module label | source |
| debug enabled based on source watchPostSource * | PostSource |
| watchPreOpenFile * | file_open |
| debug enabled based on file_open watchPostOpenFile *AfterFile watchPreCloseFile * | file_close |
| debug enabled based on file_close watchPostCloseFile *AfterFile Activities having one argument in | call |
| debug enabled based on file_close watchPostCloseFile *AfterFile Activities having one argument in which is a string const &and is not the module name These need to leave RunEvent alone watchPrePathBeginRun * | RPath |
| __pad0__ | |
|
virtual |
Definition at line 58 of file moduleTracking.txt.
|
virtual |
Definition at line 59 of file moduleTracking.txt.
Definition at line 63 of file moduleTracking.txt.
|
virtual |
Definition at line 61 of file moduleTracking.txt.
| for in the course of each when the analysis path comes to this the including up to two for each then that function is called | ( | In the | MessageLogger, |
| we register preModule in this | way. | ||
| ) |
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is called | ( | In the | MessageLogger, |
| we register postModule in this | way. | ||
| ) |
| debug enabled based on file_close watchPostCloseFile* AfterFile Activities having one argument in which is a string const& and is not the module name These need to leave RunEvent alone watchPrePathBeginRun that is a ModuleDescription const& watchPreModuleConstruction* nominal ctor | ( | also validation | check | ) |
|
pure virtual |
| the full set is shown in Appendix B the code for the module creates a class derived from EDAnalyzer | ( | see EDAnalyzer.h in the Framework | package | ) |
|
virtual |
Definition at line 60 of file moduleTracking.txt.
Definition at line 64 of file moduleTracking.txt.
|
virtual |
|
pure virtual |
Definition at line 62 of file moduleTracking.txt.
| These are in mini functions in MessageService src MessageLogger such as preModule | ( | Sometimes the module name is | modified, |
| as in:MessageDrop::instance() -> | moduleName = curr_module_ + "{ctor}"; and we shall want to introduce some sort of consistancy on that. |
||
| ) | const |
|
virtual |
Definition at line 66 of file moduleTracking.txt.
|
virtual |
Definition at line 68 of file moduleTracking.txt.
|
virtual |
Definition at line 65 of file moduleTracking.txt.
|
virtual |
Definition at line 67 of file moduleTracking.txt.
|
pure virtual |
| iRegistry watchPostModule | ( | this | , |
| &MessageLogger::postModule | |||
| ) |
| iRegistry watchPostModuleConstruction | ( | this | , |
| &MessageLogger::postModuleConstruction | |||
| ) |
| iRegistry watchPreModuleConstruction | ( | this | , |
| &MessageLogger::preModuleConstruction | |||
| ) |
|
pure virtual |
Definition at line 109 of file moduleTracking.txt.
| __pad0__ |
Definition at line 270 of file moduleTracking.txt.
| Appendix that is a string const& watchPrePathBeginRun watchPrePathEndRun watchPrePathBeginLumi watchPrePathEndLumi watchPreProcessPath The following activities have one argument by the time the module specific code is reached In each of these that is a ModuleDescription const& watchPreModuleConstruction watchPostModuleConstruction watchPreModuleBeginJob watchPostModuleBeginJob watchPreModuleEndJob watchPostModuleEndJob watchPreModule watchPostModule watchPreModuleBeginRun watchPostModuleBeginRun watchPreModuleEndRun watchPostModuleEndRun watchPreModuleBeginLumi watchPostModuleBeginLumi watchPreModuleEndLumi watchPostModuleEndLumi watchPreSourceConstruction we describe the arguments |
Definition at line 146 of file moduleTracking.txt.
| Appendix B |
Definition at line 146 of file moduleTracking.txt.
| debug enabled based on file_close watchPostCloseFile* AfterFile Activities having one argument in call |
Definition at line 236 of file moduleTracking.txt.
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of we should do whatever is appropriate in terms based either on module label OR on a generic for this life cycle event In rare special ML activity like triggering a summary We should establish these in the pre and probably should restore them in the post callback |
Definition at line 81 of file moduleTracking.txt.
| Appendix that is a string const& watchPrePathBeginRun watchPrePathEndRun watchPrePathBeginLumi watchPrePathEndLumi watchPreProcessPath The following activities have one argument by the time the module specific code is reached In each of these cases |
Definition at line 81 of file moduleTracking.txt.
| These are in mini functions in MessageService src MessageLogger cc |
Definition at line 19 of file moduleTracking.txt.
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of we should do whatever is appropriate in terms based either on module label OR on a generic for this life cycle event In rare special ML activity like triggering a summary We should establish these in the pre and probably should restore them in the post although under the assumptions that we know all the cycle and handle each pre correctly |
Definition at line 81 of file moduleTracking.txt.
| curr_module_ = ":" |
Definition at line 10 of file moduleTracking.txt.
| messageDrop debugEnabled |
Definition at line 16 of file moduleTracking.txt.
| descToCalcName_[&desc] =curr_module_ |
Definition at line 13 of file moduleTracking.txt.
| Appendix that is a string const& watchPrePathBeginRun watchPrePathEndRun watchPrePathBeginLumi watchPrePathEndLumi watchPreProcessPath The following activities have one argument by the time the module specific code is reached In each of these that is a ModuleDescription const& watchPreModuleConstruction watchPostModuleConstruction watchPreModuleBeginJob watchPostModuleBeginJob watchPreModuleEndJob watchPostModuleEndJob watchPreModule watchPostModule watchPreModuleBeginRun watchPostModuleBeginRun watchPreModuleEndRun watchPostModuleEndRun watchPreModuleBeginLumi watchPostModuleBeginLumi watchPreModuleEndLumi watchPostModuleEndLumi watchPreSourceConstruction we describe the Run Event |
Definition at line 222 of file moduleTracking.txt.
| for example |
Definition at line 70 of file moduleTracking.txt.
Definition at line 233 of file moduleTracking.txt.
| watchPreOpenFile* file_open |
Definition at line 231 of file moduleTracking.txt.
| See appendix A for details of module types other than EDAnalyzer EDAnalyzer has the virtual following void functions |
Definition at line 51 of file moduleTracking.txt.
| How the MessageService Sets Up the Module Name This document describes how the module and any suppression information |
Definition at line 4 of file moduleTracking.txt.
| How the MessageService Sets Up the Module Name This document describes how the module and any suppression gets where the logger needs it |
Definition at line 4 of file moduleTracking.txt.
Definition at line 70 of file moduleTracking.txt.
| messageDrop moduleName = curr_module_ |
Definition at line 14 of file moduleTracking.txt.
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of modules |
Definition at line 44 of file moduleTracking.txt.
Definition at line 4 of file moduleTracking.txt.
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of we should do whatever is appropriate in terms of |
Definition at line 81 of file moduleTracking.txt.
Definition at line 38 of file moduleTracking.txt.
Definition at line 226 of file moduleTracking.txt.
| debug enabled based on file_close watchPostCloseFile* AfterFile Activities having one argument in which is a string const& and is not the module name These need to leave RunEvent alone watchPrePathBeginRun* RPath |
Definition at line 236 of file moduleTracking.txt.
| for in the course of each when the analysis path comes to this the including up to two for each service |
Definition at line 74 of file moduleTracking.txt.
Definition at line 114 of file moduleTracking.txt.
| So |
Definition at line 70 of file moduleTracking.txt.
| watchPreSourceRun* module label source |
Definition at line 222 of file moduleTracking.txt.
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of we should do whatever is appropriate in terms based either on module label OR on a generic for this life cycle event In rare special ML activity like triggering a summary We should establish these in the pre and probably should restore them in the post although under the assumptions that we know all the cycle and handle each pre and that nothing of interest occurs in the frame work BETWEEN post this and pre we could take a shortcut and do without the post callbacks I should probably just make those conditional code A few general routines should suffice |
Definition at line 81 of file moduleTracking.txt.
| for in the course of each when the analysis path comes to this the including up to two for each then that function is then that function is EITHER associated with a module OR independent of we should do whatever is appropriate in terms based either on module label OR on a generic for this life cycle event In rare special ML activity like triggering a summary We should establish these in the pre and probably should restore them in the post although under the assumptions that we know all the cycle and handle each pre and that nothing of interest occurs in the frame work BETWEEN post this and pre that |
Definition at line 81 of file moduleTracking.txt.
| Appendix that is a string const& watchPrePathBeginRun watchPrePathEndRun watchPrePathBeginLumi watchPrePathEndLumi watchPreProcessPath The following activities have one argument by the time the module specific code is reached In each of these that is a ModuleDescription const& watchPreModuleConstruction watchPostModuleConstruction watchPreModuleBeginJob watchPostModuleBeginJob watchPreModuleEndJob watchPostModuleEndJob watchPreModule watchPostModule watchPreModuleBeginRun watchPostModuleBeginRun watchPreModuleEndRun watchPostModuleEndRun watchPreModuleBeginLumi watchPostModuleBeginLumi watchPreModuleEndLumi watchPostModuleEndLumi watchPreSourceConstruction watchPostSourceConstruction |
Definition at line 146 of file moduleTracking.txt.
1.8.11
