RECENT ATLAS ACTIVITIES

Focus on CC-IN2P3 participation

cc-atlas

LCG-FR T1&AF meeting, CC-IN2P3

May, 27th 2010

INTRODUCTION

7 TeV era (“ère de découverte”):

First collision on March, 30th 2010

8.85 nb-1 delivered (stable beams)

94% data taking efficiency (8.30 nb-1 recorded)

Not much “heavy” particles yet (~ 30 well-known W particles; >7 million at DØ/Tevatron)

M.Aleksa and B.Gorini, ATLAS Open

Executive Board meeting, 05/18/2010

http://cctools.in2p3.gt/mrtguser/

Computing activities (“la totale”):

MC production (new energy)

Reprocessing campaigns (major HEP conference dead-lines)

Physics group production (just starting)

User analysis

Data transfers

CPU at CC-IN2P3

Number of jobs at CC-IN2P3, last month,

ATLAS contributes to 42.4% on average

ATLAS

ALL

SIMULATION MC

ATLAS wide:

Most established activity

400 millions Geant4 events simulated in April

Represents ~50% of T1 activity nowadays (shared with reprocessing)

At CC-IN2P3:

Continuous, smooth production (tasks defined by bunches by ATLAS → peaks)

Significant increase of the number of jobs

http://cctools.in2p3.gt/mrtguser/mrtguser/atlas/atlasprod.html

Number of jobs running on the T1 since January 1st 2009

First coll. Data (nov. 2009)

RELATED AFS HICCUP: RELEASE INSTALLATION

ATLAS wide:

Automatic system for deployment of the release on the Grid sites

One installation per ATLAS CE, independently

At CC-IN2P3:

Releases on AFS; five CEs used for software tag publication

Several thousand jobs running simultaneously

No more overload (other sites experience overload)

Problem: still manual interventions to finalize installations

On going improvements:

Single NFS tag file shared by all CEs → five times less installations

Asynchronous replication (main failures) → other jobs can proceed without waiting replication

REPROCESSING

ATLAS wide:

Since 7 TeV collisions: two reprocessing campaigns

Standard dataflow:

RAW→ESD, other small files + ESD merging

n ESDs→AOD, dESD, other small files

Means CPU needs and very high data distribution transfers

At CC-IN2P3:

ESD: Event Summary Data (detailed data format)

AOD: Analysis Object Data (reduced physics quantities)

dESD: derived ESD (for given physics groups/studies)

FR

May II repro job submission

mean number of jobs running vs time

Site Validation

Green light,

May 13 23:00

Start submission

May 14 00:30

RAW→ESD done in 3 days

ESD→AOD done in 5 days

ATLAS Open EB meeting,

May 18, 2010, A. Klimentov

Disk resident files

May II RAW→ESD: ~6k jobs (~20%)

CC-IN2P3 provides a high memory and scratch space queue (“rescuing” queue)

Great success

Errors at CC related to ATLAS software

DATA TRANSFERS

ATLAS wide:

High numbers of files to transfer (T1↔T1+T1→T2), all activities

May 2010: ATLAS is moving on the GRID three times more files than during STEP09 (already 1.5 the computing model)

This is too much data to handle.

Data distribution finished in ~10 days, four times faster than the Computing Model.

At CC-IN2P3:

High dCache activity observed (transfers+jobs), some SRM errors

Also true for other sites, specifically sites with an unbalance association

Errors traced back to faulty pool

Otherwise very stable dcache behavior since months

FTS transfers:

CC ↔ T1: no problem

CC → T2: slow transfer rate

ADC weekly meeting,

May 10th, 2010, S. Campana

(cont'd)

Illustration of dcache activity: pool transfers

LCG, ALL

LCG, ATLAS

14Gb/s out

2.5Gb/s out

USER ANALYSIS

May 2009 - May 2010

mean number of analysis jobs running vs time

Scaling test

Real

Analysis

FR

ATLAS wide:

Scaling test

Since 7 TeV collisions started,

number of analysis jobs multiplied by two

ATLAS Open EB meeting,

May 18, 2010, A. Klimentov

USER ANALYSIS (CONT'D)

At CC-IN2P3:

Very fast growth of the number of analysis job demand

Problem: analysis jobs accumulating in the “queued” state

Reason #1: production has higher privileges than analysis

→ increase the share of the analysis activity (compared to the production)

→ limit the number of running jobs for T2 MC production

Reason #2: xrootd queue processes jobs ~10 times slower than dCache

→ close the xrootd queue

Applying those changes: queued jobs rapidly entering in running state

http://cctools2.in2p3.fr/mrtguser/mrtguser/ccin2p3/res_u_xrootd_atlas.htm

SITE IMPROVEMENTS FOR ATLAS

Frontier server + squid cache:

Installed at CC-IN2P3

Under validation

Available officially for the collaboration

Automatic survey and fixes for:

AFS consistency checks (RW/RO)

Release installation

Release customisation

Error rate on site

Automatic restart of Vobox services

CONCLUSION

The CC-IN2P3 participated to all the ATLAS computing activities and the CC-IN2P3 came up to the expectations

Projects still on the work:

Stabilize the release installation mechanism

Tune of the local batch system to allow a fast analysis turn-around

Problems to be watched:

Slow FTS transfers to T2

BACKUP

DISK SPACE

http://cctools.in2p3.gt/stockage/

USER ANALYSIS

http://cctools2.in2p3.fr/mrtguser/mrtguser/ccin2p3/res_u_xrootd_atlas.htm

AT CC-IN2P3

Catherine Biscarat

2005-04-05T18:38:29