aliroot survey: analysis p.hristov 11/06/2013. are you involved in analysis activities?(85.1% yes,...

Post on 18-Jan-2018

219 Views

Category:

Documents

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

What is your current level of experience with ALICE analysis tools? 3 Mean 3.4

TRANSCRIPT

AliRoot survey: Analysis

P.Hristov11/06/2013

2

Are you involved in analysis activities?(85.1% Yes, 14.9% No)

Involved since 4.5±2.4 yearsDedicated time (51±27)%

3

What is your current level of experience with ALICE analysis tools?

Mean 3.4

4

User Profile

5

Types of analysis

6

Analysis frameworks

7

How often do you run your analysis in the following way? ( 1 - rarely, 5 - very often) Locally: 3.4 CAF or other analysis facility: 2 On a batch system: 2.7 On GRID: 3.4 In a LEGO train: 2.7

8

What do you use to deploy GRID analysis?

9

Quality of services (1 - lowest, 5 - highest): easiness to develop a new task: 3.5 documentation of the analysis framework: 2.4 documentation of services: 2.3 alien handler functionality: 3.1 easiness to deploy analysis and run on large

data sets: 3.2 analysis tutorials: 2.9 existing example code or code of others: 4.2 available analysis pages: 2.9 analysis mailing list: 3.4

10

Time to complete analysis (hours) Achieved: 22±19 Expected: 10±10 Is it fast enough?

11

Are you aware of the LEGO framework?

Yes: 77.8%No: 6.4%No answer: 15.8%

12

Do you use the LEGO framework?

Yes: 53%No: 42.9%No answer: 4.1%

13

Reasons why people do not use LEGO trains Code under development/ not stable/ not ready

for the LEGO trains. Missing documentation/instructions No ESD trains/Only AOD centric analysis Don't believe in AOD analysis and use a batch

farm So far because my needs could not be satisfied For new analysis code, I am running the analysis

task in 'let-me-start' way, i.e. the output of my jobs is a big tree. I would check as much as possible cutting variables.

14

Reasons why people do not use LEGO trains Local batch farm is more performing, easier to use

Better debugging possibilities higher flexibility faster processing better control

Because most of what I do can be done off-grid, on (S)AF.

My analysis activities mostly involve detector studies and are mostly done on my laptop or batch systems

Running on CAF; there was not yet the lego train framework; new analysis testing

Merging of large outputs, more flexibility needed Frequent change of parameters and code

15

How useful do you consider the LEGO framework (1 - not useful, 5 - very useful)?

Mean: 4.7

16

Do you need extra functionality from the analysis framework?

17

Required functionality Easy possibility to write custom streams. more details for basic selection Larger size of the buffer for event mixing ? (Do not really

know if this is doable easily) Mainly I need better documentation. I think it's all written

but the documentation directly linked to on the offline pages is all >3 years old. Several features are completely undocumented - or at least the documentation is so obscure as to effectively not exist.

Trigger information at analysis level. Smarter merging. Now it only starts once all jobs are finished. Why not start merging when the first files are created? And then just do bookkeeping. Now we are in a situation where people doe their own merging on local clusters since that saves you 2 days!

18

Required functionality Have access from within AODs of general things useful for

all analysis, like trigger configuration (to get scalers, downscaling, etc..) and LHC information (to get lumi, etc...). Those things are mostly run-based and not event-based.

While running the merging (with a user job) a subjob can fail due to a corrupted/inaccessible file. This implies a significant loss of statistics that could be avoided if this error could be automatically detected and the job resubmitted skipping that specific file.

Embedding of real data and MC digits is missing. We run custom jobs which simulates events, read ESD of real data, convert ESD objects to digits, merge data digits with MC digits, run reconstruction, produce a new ESD, then filter to AOD. Only after that we can use the analysis framework to analyzed such embedded AOD.

19

Priorities for the analysis framework (1 - low priority, 5 -high priority) better user support: 3.6 more functionality: 2.8 development of common analysis tools: 3.6 better speed: 3.5 better documentation and examples: 4.4 better PROOF support: 3.0 better LEGO support: 3.1

20

Conclusions The most important issue is the

documentation Some of the requests show that not

everybody is ready to use AODs in the analysis. This needs additional investigations

top related