80 likes | 203 Views
Analysis framework status. Gheata , Weekly offline meeting 3.05.07. I ssues. Streaming in PROOF mode Recent fixes and changes Event loop vs. ‘single shot’ tasks Bookkeeping & exception handling. Streaming in PROOF mode. Output data is written in containers
E N D
Analysis framework status Gheata, Weekly offline meeting 3.05.07
Issues • Streaming in PROOF mode • Recent fixes and changes • Event loop vs. ‘single shot’ tasks • Bookkeeping & exception handling
Streaming in PROOF mode • Output data is written in containers • Bad (containers are linked in the analysis tree) • New wrapper introduced to ship data • Transparent to user AliAnalysisSelector PROOF Merge()
Recent changes • AliAnalysisTask::LocalInit() • Introduced to allow local (on client) task initialization in a uniform way • Users should not create objects that will be written to outputs here, but in ConnectInputData() • Not mandatory • Disabling all branches by default • The branches requested by tasks are automatically enabled when using AliAnalysisTask::SetBranchAddress() • Minimizes size of read data
Recent changes (2) • AliAnalysisTask::Notify() • Called when starting the first tree or changing the file in a chain • Used currently by AliAnalysisTaskRL to update validity of run loader • AliAnalysisTask::OpenFile(Int_tiout) • To be called in CreateOutputObjects() before creating the objects to be written to the files specified by the output containers • Not mandatory: to be used only for big trees that cannot fit memory • Fix: CreateOutputObjects() and Terminate() called now also in the non-event loop case
Event loop vs. single shot • Event loop controlled by TSelector • Framework supports non – event loop mode • Combining the two does not work currently • E.g. processing a chain and producing a histogram, than using a task that fits the histogram in the SAME analysis manager session • Analysis split in 2 stages • Processing all tasks in event loop up to Terminate() • Starting stage 2 and executing LOCALLY all non event loop tasks • Implementation ongoing • Tasks/containers aware of their execution mode
Bookkeeping • Initial configuration of tasks, input queries and conditions – not standardized • We may need to know what configuration, what tasks produced a given data • Which were the selection criteria • Which data failed to be processed • Analysis manager may be streamed together with configuration macros in the output tree header • Configuration macros may be encapsulated in tasks
Exception handling • No state manager for the moment • A failing task makes the whole system crash • Typical analysis production run mode will connect several different analysis tasks to the same input data • Maximize profit from having data in memory • A handler for SIGSEGV and other nasty signals can be written • Can we continue after a segmentation violation, or we gracefully die ? • Stack may be corrupted, and other bad things may have happened • Run part of the analysis in a safe thread … ? • Implementing a state manager • Decoupling user code execution