+ All Categories
Home > Documents > Computing, STAR and the RCF 200-300 KB/event ... with a TPC at its heart ... Using the RCF job...

Computing, STAR and the RCF 200-300 KB/event ... with a TPC at its heart ... Using the RCF job...

Date post: 21-May-2018
Category:
Upload: tranliem
View: 213 times
Download: 1 times
Share this document with a friend
30
Jerome LAURET RHIC S&T DOE Review Computing, STAR and the RCF Facility Science and Technology DOE Review of the Relativistic Heavy Ion Collider July 6-8 th 2005
Transcript

Jerome LAURETRHIC S&T DOE Review

Computing, STAR and the RCF

Facility Science and Technology DOE Review of the Relativistic

Heavy Ion Collider

July 6-8th 2005

Jerome LAURETRHIC S&T DOE Review

Guidance

Priorities & Prospects Status and Performance analysis using

RCF Accomplishments Productivity Issues

Jerome LAURETRHIC S&T DOE Review

Priorities

Our activities = Our priorities Deliver quality data to the Physicists for quality science

Evaluate, plan, and integrate new technologies, methodologies, computational techniques designed to better achieve program goals

Develop an environment fostering collaboration with others and welcoming outsourcing

Support for our user community & analysis

Data mining, data production

Seems a bit “scholar”, order reflects priorities

CS R&D (calib techniques, tracking …)

Grid computing …

Jerome LAURETRHIC S&T DOE Review

Online data flow

Online● Event “Pool” based framework

● “Standard” approach - used by most modern experiment● Designed to improve IO online (striped “cheap” disk)

● Data is pushed to HPSS (offline realm)● Fraction used online to perform fast calibration / analysis

Trigger

RO EvtBuilder

Replication

pftpEvtBuilder

Trigger

Jerome LAURETRHIC S&T DOE Review

DAQ IO Rates

Rates ~ 100 Hz, 50-60 MB/sec sufficient to coverfor the data rates and needs FOR NOW

Later program requires x10 rates (DAQ1000 – R&D)

Jerome LAURETRHIC S&T DOE Review

2005

/2/2

4 12

:20

2005

/2/2

7 12

:520

05/3

/2 1

4:45

2005

/3/5

16:

1520

05/3

/8 1

5:15

2005

/3/1

1 13

:25

2005

/3/1

4 12

:15

2005

/3/1

7 16

:35

2005

/3/2

0 16

:55

2005

/3/2

3 18

:25

2005

/3/2

6 17

:520

05/3

/29

18:1

520

05/4

/1 1

6:45

2005

/4/4

20:

4520

05/4

/8 7

:520

05/4

/11

10:2

520

05/4

/14

9:25

2005

/4/1

7 7:

3520

05/4

/20

5:45

2005

/4/2

3 4:

520

05/4

/26

2:15

2005

/4/2

9 2:

520

05/5

/2 0

:25

2005

/5/4

23:

2520

05/5

/7 2

1:35

2005

/5/1

0 19

:55

2005

/5/1

3 18

:520

05/5

/16

16:1

520

05/5

/19

14:2

520

05/5

/22

12:4

520

05/5

/25

10:5

520

05/5

/28

9:5

2005

/5/3

1 7:

2520

05/6

/3 6

:45

2005

/6/6

5:5

2005

/6/9

14:

3520

05/6

/12

12:4

520

05/6

/15

10:5

520

05/6

/18

9:15

2005

/6/2

1 7:

2520

05/6

/24

12:1

520

05/6

/27

13:1

5

0.001.002.003.004.005.006.007.008.009.00

10.0011.0012.0013.0014.00

Rates to HPSS

HPSS support for our DAQ/Raw data and network is more than adequate …

Number of tape drives maximum 10 is sufficient

Jerome LAURETRHIC S&T DOE Review

Data safety

Accounting reveals some minor losses – Two sources Online

• Year3+HPSS failures not handled and not enough buffer, miss-accounting (fraction reported missing was temporary data)

• Corrected immediately, now 99.3% safe• Remaining losses due to hardware losses

Offline• Aging HPSS – % files regularly lost• Remaining un-identified losses, safety

greater than 99.93%

Some other problem with HPSS Periods with reduced access concerning for later program

scaled up need Problems are however generally addressed and resolved with

method by qualified RCF personnel

0.00%

1.00%

2.00%

3.00%

4.00%

5.00%

6.00%

7.00%

8.00%

9.00%

3 4 5

RHIC running year

%ta

ge o

ffset

Jerome LAURETRHIC S&T DOE Review

Data Sets sizes - Year4

Raw Data Size <> ~ 2-3 MB/event (HPSS) Needed only for calibration, production – Not centrally (NFS) or

otherwise stored

Real Data size Data Summary Tape+QA histos+Tags+run information and

summary: <> ~ 2-3 MB/event Micro-DST: 200-300 KB/event

Total Year4

DAQ DST/eventMuDST

productionAnalysis

Data Reduction Flow

Jerome LAURETRHIC S&T DOE Review

How long ?

Since Year4 for RHIC experiments moved out of the fast production turn around mode …Year scale production cycles

Jerome LAURETRHIC S&T DOE Review

Before prod - Calibration notes

Never under-estimate its importance STAR is not only a large acceptance, multi-purpose detector

with a TPC at its heart Rule #1 Whatever can go wrong WILL go wrong Rule #2 When you think you have it under control, something

else comes up

We got it all (Field distortions, twist, pile-up, ...) and survived But we “lost” our dreams for immediate data

usability a while back …

Typically, pre-production pass requires ~ 10% of the data pre-processed BEFORE a big production wave ½ for TOF SpaceCharge, beam line, drift velocity verification dE/dx, SVT & FTPC alignment

Jerome LAURETRHIC S&T DOE Review

Offline - Production model ... As fast as possible

Centralized – Tier0 BNL data production Note: User Analysis balanced on Tier0/Tier1 ALL REAL DATA produced at BNL. EVENT files get copied on HPSS at the end of a

production job

Achievable during the run Online: QA & Fast Online Calibration Offline: Fast-Offline production

• Fraction of the data ; up to 5-10 % processed• TPC Laser runs identifiable (naming convention) all processed• Automatic calibration of TPC drift velocity, offline QA, calorimeter, TOF, FTPC, ...

Re-distribution When production done, system is automated If “sanity” checks (integrity and checksum), files become immediately available to the

end-user 30 seconds after the file is produced at Tier0 30 mnts to Tier1 (PDSF) – Strategy implies dataset IMMEDIATE replication

Jerome LAURETRHIC S&T DOE Review

1.2 pass based model We know we need 20% needed for calibration (0.2) 1 pass = 1 time chance, if something goes wrong, the data

set CANNOT be reproduce, the science CANNOT be delivered

We STRONGLY believe in a minimum 2.5 passes 10% fast calibration (as data arrives) 10% slow calibration 10% R&D 2 passes, each pass twice as fast = better & faster

quality data and science A breathing margin for an already over-worked team

Past resource estimates

Jerome LAURETRHIC S&T DOE Review

Required Comparison of CPU Delivered to Projected

1,000

10,000

100,000

2004 2005 2006 2007 2008 2009 2010

Year

CPU

(kSI

2K)

ProjectedRequirement (1.2passes)

Delivered (DefaultFunding)

Delivered(AugmentedFunding) Adjustedrequirement (2.5passes)

Several solutions to recover resources• More money flows to RHIC computing• Resources are borrowed from other providers (NSF / TerraGrid, …)• Resource are gathered from other collaborators

Missing SPEC to default funding

010002000300040005000600070008000

2004

2005

2006

2007

2008

2009

2010

Year

CPU

(kSI

2k)

Missing SPEC todefault funding

Jerome LAURETRHIC S&T DOE Review

Opportunities & prospects

Allocation to NSF TeraGrid Provides a fraction of the missing spec on

first year, less later• Also provide a superb opportunity for DOE/NSF

resource exchange• Grid interoperability exercise and building the

future in this area

Remote institutions• Several coming with 100ds of CPU within the next

2 years• May be at reach if Grid activities continue to be

viably supported (funding for PPDG ends soon)

Jerome LAURETRHIC S&T DOE Review

Current Status - OSG

New Grid opportunity The OpenScience Grid,

STAR is part of it and working with optimism and confidence the agency will see and understand its value

Our grid is expanding

Jerome LAURETRHIC S&T DOE Review

Efficiencies and productivity with current RCF resources

Every time one speaks of “efficiency”, “performance” or “productivity”, the word “business” crosses my mind …

Jerome LAURETRHIC S&T DOE Review

Efficiencies and productivity with current RCF resources

In general good Our code itself is very robust

Losses (crash) are below 0.1% at worst• Main reason for low rate: FastOffline or automated calibration

catches problems Problems found are fixed on a weekly schedule

Technology factor & limitations Using the RCF job submission software “black box”

• New system designed to be scalable (good)• Efficiency purely based on success / failure trapped by the

system (HPSS staging, miscellaneous) shows some concerning trends [later period may show improvements]

Jerome LAURETRHIC S&T DOE Review

Efficiencies current resourcesNew and Old Reco systems

0102030405060708090

100

1/8/2003 5/8/2003 9/8/2003 1/8/2004 5/8/2004 9/8/2004 1/8/2005 5/8/2005

Date (YYMMDD)

Effic

ienc

y

Old system efficiency slightly dropped mainly

due to HPSS tape drive allocationTrend is similar with other experiment (in fact, the graph

represents an average)

New and Old Reco systems

0102030405060708090

100

1/8/2003 5/8/2003 9/8/2003 1/8/2004 5/8/2004 9/8/2004 1/8/2005 5/8/2005

Date (YYMMDD)

Effic

ienc

y

Efficiency is 20% lower average over a yearTrend lately to the increase (hopefully will remain)

Jerome LAURETRHIC S&T DOE Review

Efficiencies current resources& Communication with the RCF in other area

CPU/Linux team much improved with a (new) set of motivated, qualified and friendly people

Outstanding communication with the Storage / disk team Helped in the evaluation of several storage system

• In fact, IO stressed tested all of them• Best tuned to real life science, lead to better scalable solution -

Currently invested in PANASAS• Has resolved some of our most important IO bottlenecks

Concerns Grid support seemed slow (was slow?)

• Tickets response time of months scale (operation downtime)• Discussed and hopefully corrected• Good support for Virtual Organization related tasks

HPSS scalability• Lots of mysterious features and behavior• System will change in future, the knowledge is there though …

Jerome LAURETRHIC S&T DOE Review

Year 4 data produced to date

production62GeV

pp

ppMinBias

ProductionPP

ProductionPPnoBarrel

ProductionPPnoEndcap

ProductionCentral

ProductionHalfHigh

ProductionHalfLow

productionMinBiasHT

ProductionMinBias

ProductionHigh

ProductionLow

ProductionMid

0102030405060708090

100

% d

one

production62GeV

pp

ppMinBias

ProductionPP

ProductionPPnoBarrel

ProductionPPnoEndcap

ProductionCentral

ProductionHalfHigh

ProductionHalfLow

productionMinBiasHT

ProductionMinBias

ProductionHigh

ProductionLow

ProductionMid

00.5

11.5

22.5

33.5

44.5

55.5

Mon

ths

Nonetheless, all data planned for production is now produced

Jerome LAURETRHIC S&T DOE Review

Production status Initial prediction based on 85% duty factor are -10% off.

New model –Merging analysis and reconstruction resources Moved event generator simulation to Grid-based production

• success rate reported in PPDG DOE quarterly report Jan-Mar-05 was 100% over 500 jobs

• Average success rate [85-90]%

Similar reached target for year5 data Still however ~ 6 months worth of

year 4 data Year 5 lags behind as a side effect

Resource OFFLOAD surely helps whenever resources are reachable / viable

The facility is providing resources and support to get the job done within the 1.2 passes expectations

Reconstruction CPU usage, non-normalized logbook CPU hours

0

5000

10000

15000

20000

25000

07/ 2002-12/ 2002 01/ 2003-06/ 2003 07/ 2003-12/ 2003 01/ 2004-06/ 2004 07/ 2004-12/ 2004 01/ 2005-06/ 2005 07/ 2005-12/ 2005*

Grid/Reco, CPU hours

RCAS/Reco, CPU hours

Jerome LAURETRHIC S&T DOE Review

Other Accomplishments Regardless of the current resource situation, several projects were

carried to success or ongoing DAQ100 new cluster finder New Integrated Tracker for STAR (ITTF)

• Strong validation procedure compares significant dataset for High Pt bias and several other Physics

• Project delayed due to lack of resources (human & CPU) Pileup-proof Vertex finder development (depends on previous)

Drop of the legacy gstar framework, now starsim• Allows for transition to integrated simulation / reconstruction a-

la Alice Virtual Monte-Carlo• Project will be reviewed later this year

Three new sub-systems code in production (reconstruction, simulation and embedding)

ROOT / Qt development made at BNL …

Jerome LAURETRHIC S&T DOE Review

Other accomplishment made in collaboration with others

Production-mode data transfer using the SDM DataMover Strong and long standing partnership with the SDM centre at

LBNL• Successful development of production Grid-aware tools• “Data Grid” architecture

Replica Registration Service (RRS) Allows on arrival file registration / availability to analysis

GridCollector Serves sub-events from distributed files to users – Speed x4 An interactive Grid analysis framework

• Relies in SRM technology, second generation of Data Grid development

Jerome LAURETRHIC S&T DOE Review

GridCollector

“tags” (bitmap index) based need to be define a-priori [production] Current version mix production tags AND

FileCatalog information (derived from event tags)

Usage in STAR Rest on now well tested, deployed and robust SRM (DRM+HRM)

• Next generation of SRM based tools - ”caching out” on past R&D• Immediate Access and managed storage space• Files moved transparently by delegation to SRM service

Easier to maintain, prospects are enormous• “Smart” IO-related improvements and home-made formats no faster than using GridCollector

(a priori) • Physicists could get back to physics• And STAR technical personnel better off supporting GC

It is a WORKING prototype of Grid interactive analysis frameworkGeneralized, user analysis may gain ins peed

1

2

3

4

5

6

0.01 0.1 1

selectivity

spee

dup

elapsed CPU

Jerome LAURETRHIC S&T DOE Review

STAR Unified Meta-Scheduler Gateway to user batch-mode analysis Flexible policy-based grid-ware, Collects usage statistics User DO NOT need to know about the popular ”batch” flavour of the day

(adaptable technology - plug-in) Has allowed to optimize resource usage

IO throttling is automated Best queue / resource found – Grid AWARE Integrated to the file catalog, a distributed disks approach (locally

attached to sparse nodes) is possible Scavenger hunt for resources is in place

Non negligible actually, 100 TB of distributed disk comparing to 130 TB central (NFS, PANFS)

Still a lot to be done Some spiky features in resource utilization needs better understanding

and development of enhanced meta-scheduling policies

SUMSThe STAR Unified Meta-Scheduler, A front end around evolving technologies for user analysis and data production

Jerome LAURETRHIC S&T DOE Review

Pedestal&flow subtractedPedestal&flow subtracted

Phys Rev. Letter 91 (2003) 072304

The real measure of accomplishments and productivity

Beautiful results internationally known

Jerome LAURETRHIC S&T DOE Review

The real measure of accomplishments and productivity

Electron identification:TOFr |1/ß-1| < 0.03TPC dE/dx electrons!!!

nucl-ex/0407006Hadron identification: STAR Collaboration, nucl-ex/0309012Hadron identification: STAR Collaboration, nucl-ex/0309012

Phys. Lett. 94 (2005) 062301Phys. Lett. B 616 (2005) 8

Jerome LAURETRHIC S&T DOE Review

The real measure of accomplishments and productivity

Jerome LAURETRHIC S&T DOE Review

Productivity in STAR Scientific Achievement in STAR

STAR Publication trend

0

2

4

6

8

10

12

14

16

2001 2002 2003 2004 2005

Tota

l num

ber o

f pub

licat

ions

#PLB#PRC#PRL

0.002.004.006.008.00

10.0012.0014.0016.0018.0020.00

1995

1996

1997

1998

1999

2000

2001

2002

2003

2004

2005

ChinesePolishFrenchGermanEnglish

2692 citations

28 PRL, 15 PRC, 4 PLB published to date

Jerome LAURETRHIC S&T DOE Review

Summary & conclusions RCF related

Provides resources adequately within 1.2 pass model New technology integration and support time scale (i.e. production

scheduling system, Grid support) has side effects and needs emphasis Mass Storage reliability and scalability concerns Communication and knowledge much-improved = right direction Several collaborative activities leading to better tuned solutions

STAR related 2.5 passes needed in STAR

• Implies search for additional resources We have a clear plan toward success but

• Grid computing a strategic choice already at the heart of our production• Difficulty to perform computing R&D within resource figure: both (in)human and

hardware• Even harder to make long term support for projects (ITTF,…)• Lots of activities however needed for the future

Scientific productivity, the best measure of success is outstanding


Recommended