ATLAS Offline Software
|
Classes | |
struct | AlgorithmData |
all the data a worker tracks for an individual algorithm More... | |
class | AlgorithmMemoryModule |
a Module wrapping each algorithm with its own memory monitor More... | |
class | AlgorithmStateModule |
a Module managing the state of the algorithms on the workers More... | |
class | AlgorithmTimerModule |
a Module wrapping each algorithm with its own timer More... | |
class | BaseManager |
a Manager to handle all of the basic tasks More... | |
class | BatchInputModule |
the IInputModule implementation for the batch driver More... | |
class | DirectInputModule |
the IInputModule implementation for the direct driver More... | |
class | DriverManager |
a Manager that passes callbacks through to the Driver More... | |
class | EventCountModule |
a Module tracking how many events get processed by each algorithm More... | |
class | FactoryPreloadModule |
a Module preloading all the registered factories More... | |
class | FileExecutedModule |
a Module recording when FileExecuted was called More... | |
class | GridReportingModule |
a Module that handles the reporting from the job on the grid More... | |
class | IInputModuleActions |
the actions that Module::processInputs can perform More... | |
class | LeakCheckModule |
a Module implementing a simple leak checker More... | |
class | Manager |
an interface for classes that handle job management for the Driver More... | |
struct | ManagerData |
an internal data structure for passing data between different manager objects anbd step More... | |
class | MemoryMonitorModule |
a Module monitoring memory usage at various points during the job More... | |
class | Module |
the base class for EventLoop instrumentation module More... | |
struct | ModuleData |
the data the EventLoop core classes are sharing with the Module implementation More... | |
class | OutputStreamData |
all data needed to manage a given output stream More... | |
class | PostClosedOutputsModule |
Module enabling to perform checks/actions on outputs once files are all closed. More... | |
class | RetrieveManager |
class | StopwatchModule |
a Module wrapping the TStopwatch class More... | |
class | SubmitDirManager |
a Manager to handle the submission directory itself More... | |
class | SubmitManager |
class | TEventModule |
class | TreeCacheModule |
a Module for setting the TTreeCache parameters on the input More... | |
class | WorkerConfigModule |
a Module implementation for running user configuration on the worker node More... | |
Functions | |
void | report_exception (std::exception_ptr eptr) |
print out the currently evaluated exception More... | |
|
strong |
an enum to establish an order in which to apply managers
While there should be very little inter-dependency between managers, it can matter which order they get applied in, e.g. the basic manager may set the default value of some property only to be overridden by a more specialized manager downstream.
Definition at line 26 of file ManagerOrder.h.
|
strong |
the individual steps of preparing a job for submission
Essentially the Driver and Manager objects are giant state machines, and this denotes the current overall state (with extra information in ManagerData).
It should be noted that not every step will be used on every operation (e.g. submit or retrieve), but instead there is a separate sequence of steps for each of them.
The alternative to this enum would be to have a separate callback in the Manager class for each step, which would have the advantage that there isn't one function with a very large switch
statement, but this approach has other advantages:
Enumerator | |
---|---|
initial | this is just the initial step we do, nothing really happens here |
initialSubmit | the initial submit step |
updateSubmitDir | update the submitDir variable to be an absolute path |
fillOptions | in this step we fill the options structure, combining the different locations from which we can pull configuration options. |
extractOptions | extract any options into ManagerData for which it is appropriate |
createSubmitDir | create the submission directory |
updateOutputLocation | in this step we update the output location of streams that don't yet have one defined |
addSystemAlgs | add any system algorithms to the job that may need to get added |
prepareSubmitDir | prepare files in our submission directory |
batchCreateDirectories | create the directories needed in the batch directory |
batchCreateJob | create the batch-driver job object |
batchScriptVar | create the variables needed for the batch-run script |
batchMakeScript | create the batch-run script |
batchMakeIndices | create the list of batch job indices |
submitJob | do the actual job submission |
directSaveOutput | save the output in the direct driver |
postSubmit | do whatever needs to be done after the submission is done |
finalSubmit | the final submit step |
initialResubmit | the initial resubmit step |
readConfigResubmit | read the configuration for resubmit |
batchJobStatusResubmit | read the job status in batch driver |
batchPreResubmit | do everything the batch driver needs to do before the resubmit |
doResubmit | call the actual doResubmit method |
finalResubmit | the final resubmit step |
initialRetrieve | the initial retrieve step |
readConfigRetrieve | read the configuration for retrieve |
batchJobStatusRetrieve | read the job status in batch driver |
doRetrieve | call the actual doRetrieve method |
finalRetrieve | the final retrieve step |
final |
Definition at line 41 of file ManagerStep.h.
|
strong |
the mode for creating the submission directory
Definition at line 20 of file SubmitDirMode.h.
void EL::Detail::report_exception | ( | std::exception_ptr | eptr | ) |
print out the currently evaluated exception
Definition at line 27 of file PhysicsAnalysis/D3PDTools/EventLoop/Root/MessageCheck.cxx.