Uso del GRID en generación masiva de Datos: Sistema de producción del Experimento ATLAS

Uso del GRID en generación masiva de Datos: Sistema de producción del

Experimento ATLAS

Santiago González de la [email protected]

CERN(European Organization for Nuclear Research)

Sistema de producción del experimento ATLAS

2/34Santiago González de la Hoz

Introducción Objetivo de esta charla Experimento ATLAS Programa “Data Challenges (DC)”

Sistema de Producción de ATLAS Base de datos de producción Supervisor: Windmill Ejecutores: Lexor, Capone y Dulcinea Data Management: Don Quijote

Fases de producción de los DC2 Los 3 “sabores” Grid (LCG, GRID3 y NorduGrid) Producción de ATLAS en los DC2

Análisis de datos utilizando el sistema de producción Conclusiones



IntroducciónObjetivo de esta charlaExperimento ATLASPrograma “Data Challenges (DC)”



Objetivo de esta charla/curso ProblemaProblema “real” con el que se encuentra un experimentoexperimento, en este caso

ATLAS. Posible soluciónsolución a dicho problema, el GRIDel GRID Uso del GridUso del Grid para la resolución de dicho problema

Experimento ATLAS Uno de los 4 experimentos que se están construyendo en el CERN

Dos de carácter general (ATLAS y CMS) Uno para la física del b (LHCb) Uno para el estudio de iones pesados (ALICE)

Se colocará en el túnel del futuro colisionador de hadrones LHC Colisionador protón-protón Energía en centro de Masas de 14 TeV Alta luminosidad (1034 cm-2 s-1)



Mont Blanc, 4810 m

Geneva





Toma de datos empieza en 2007 Level 3 Trigger: 100 sucesos/s,

siendo el tamaño de ≈ 1 MB/suceso

Volumen de datos ≈ 1 PB/año durante 10 años

CPU estimada para procesar datos en el LHC: 200.000 PCs actuales

Esto genera 3 problemas: Almacenamiento de datos Procesado Usuarios dispersos por todo el

mundo

TECNOLOGÍAS GRID

Posible solución



Programa Data Challenges (DC) La colaboración ATLAS en el año 2002 diseño el programa “Data Challenges

(DC)” con el objetivo de validar su: Modelo de Computación Software Modelo de datos Empezar a usar y probar las tecnologías GRID

Con los DC1 se consiguió (no se utilizó el GRID): Desarrollar y desplegar el software necesario para la producción de sucesos a gran

escala. Participaron en la producción institutos de todo el mundo.

Con los DC2 se ha conseguido producir sucesos a gran escala utilizando el middleware GRID desarrollado en tres proyectos (sabores de Grid) : LHC Computing Grid project (LCG), en el cual participa el CERN y el IFIC GRID3 NorduGRID



Sistema de producción de ATLAS(ver charla Julio Lozano)Base de datos de producciónSupervisor: WindmillEjecutores: Lexor, Capone y DulcineaData Management: Don Quijote



La base de datos de producción, la cual contiene la definición de los trabajos.

El supervisor “windmill”, el cual consulta la base de datos para obtener la definición de los trabajos y se los pasa a los ejecutores de cada Grid en formato XML.

Los ejecutores, hay uno por cada sabor Grid. Ellos reciben la definición del trabajo en formato XML y la convierten en el “job description language (JDL)” de cada “sabor” Grid.

Don Quijote, Atlas Data Management system, el cual se encarga de: Transferir ficheros desde su

localización temporal hasta su destino final en un Storage Element (SE)

Registrar los en el catálogo correspondiente a cada Grid (replica location service).

Atlas diseño un sistema de producción automático para poder llevar a cabo su producción masiva de datos en los DC2.

El sistema de producción de ATLAS consiste en 4 componentes:



Definición de trabajos en la base de datos Prodcom: Es una herramienta

interactiva gráfica que nos permite fácilmente definir una gran cantidad de trabajos en la base de datos

Esta hecho en Java y se puede correr como un applet

En la definición del trabajo elegimos: Nuestra transformación* Los ficheros de entrada (ponemos su

LFN, logical file name) Los ficheros de salida (LFN) Donde queremos que se guarden los

ficheros de salida (SE)*Transformación: Es un shell script que espera

una serie de parámetros de entrada y ejecuta “athena.py”, otro “programa” para la generación, simulación, etc.. de sucesos en ATLAS.



Definición de trabajos en la base de datos Los trabajos se

crean en la base de datos y se les asigna automáticamente un ID

También se monitoriza su estado.



Declaración de una transformación en la base de datos: phpORADmin:

interfaz web de ATLAS con la base de datos.

La transformación se declara

Se definen los parámetros de entrada que necesita dicha transformación



Supervisor: Windmill Es una implementación Es una implementación

del software “supervisor” del software “supervisor” para la gestión de la para la gestión de la producción de ATLAS. producción de ATLAS.

Consulta la base de datos Consulta la base de datos para obtener la definición para obtener la definición de los trabajos.de los trabajos.

Interacciona con varios Interacciona con varios “ejecutores” para la “ejecutores” para la distribucción, ejecución y distribucción, ejecución y monitorización de los monitorización de los trabajos en los diferentes trabajos en los diferentes Grids (a través de XML, Grids (a través de XML, utilizando un jabber utilizando un jabber server, )server, )

Configuración: Windmill Se configura modificando el fichero windmill.xmlSe configura modificando el fichero windmill.xml

Jobselection: <grid>LCGANALYSIS</grid>. Para coger los

trabajos en la base de datos con inputhint LCGANALYSISDatabase: <oraconnection>atlas_prodsys_dev/prodsys@devdb</oraconnection>. Elegimos la base de datos



Ejecutores: Lexor, Dulcina y Capone Por diseño son una Por diseño son una

interfaz entre el interfaz entre el supervisor (que es supervisor (que es único) y los tres único) y los tres “sabores” Grid.“sabores” Grid.

La información que La información que reciben del supervisor reciben del supervisor en XML, la convierten en XML, la convierten en el JDL (Job en el JDL (Job Description Language) Description Language) de que “sabor” Grid de que “sabor” Grid

Envían los trabajos a Envían los trabajos a los correspondientes los correspondientes Computing Elements Computing Elements asociados con dicho asociados con dicho sabor de Grid.sabor de Grid.

Configuración: Lexor (LCG) Se configura modificando el fichero lexor.cfgSe configura modificando el fichero lexor.cfg

Elección de Resource Broker y BDII Puedes habilitar o deshabilitar centros

El fichero lexor_wrap.sh:El fichero lexor_wrap.sh: Baja, instala y ejecuta la transformación Hace el “stage in” de los ficheros necesarios de entrada

(utilizando Don Quijote, DQ) Hace el “stage out” de los ficheros de salida (DQ)



Data Management System: Don Quijote (DQ) El objetivo de DQ es integrar El objetivo de DQ es integrar

todos los servicios de gestión de todos los servicios de gestión de datos (data managment) datos (data managment) usados por los tres Grids y por usados por los tres Grids y por lo tanto por el Experimento lo tanto por el Experimento ATLAS.ATLAS.

De esta forma los datos se De esta forma los datos se pueden replicar y registrar de pueden replicar y registrar de forma transparente entre los forma transparente entre los diferentes catálogos de los tres diferentes catálogos de los tres “sabores” grids.“sabores” grids.

Realmente hay tres servidores Realmente hay tres servidores DQ, uno para cada Grid, pero DQ, uno para cada Grid, pero para el usuario final, esto es para el usuario final, esto es totalmente transparente. Como totalmente transparente. Como si solo hubiera unosi solo hubiera uno

Utilización Don Quijote: Corres el script eligiendo el tipo de Grid y el Corres el script eligiendo el tipo de Grid y el

LFN para dicho fichero:LFN para dicho fichero: dms2.py –g lcg get dms2.py –g lcg get

rome.004100.recov10.T1_McAtNLO_top._0021rome.004100.recov10.T1_McAtNLO_top._00211.AOD.pool.root1.AOD.pool.root



Fase de producción de los DC2Los 3 “sabores” Grid (LCG,

GRID3 y NorduGrid) Producción de ATLAS en los DC2



Fases de producción de los DC2Fases de producción de los DC2

HitsMCTruth

Digits(RDO)

MCTruth

BytestreamRaw

Digits

ESDGeant4

Reconstruction

Reconstruction

Pile-upHitsMCTruth

Digits(RDO)

MCTruth

Physicsevents

EventsHepMC

EventsHepMC

HitsMCTruth

Geant4

Geant4

Digitization

Digits(RDO)

MCTruth

BytestreamRaw

Digits

BytestreamRaw

Digits

BytestreamRaw

DigitsEventsHepMC

HitsMCTruth

Geant4Pile-up

Digitization

Mixing Reconstruction ESD

Pyt

hia

Event generation

Detector Simulation

Digitization (Pile-up)

ReconstructionEventMixingByte stream

EventsHepMC

Min. biasEvents

Piled-upevents Mixed events

Mixed eventsWith

Pile-up

~5 TB 20 TB 30 TB20 TB 5 TB

TBVolume of datafor 107 events

Persistency:Athena-POOL

BytestreamRaw

Digits

ESDReconstruction

BytestreamRaw

Digits

BytestreamRaw

Digits

Digits(RDO)

MCTruth

Mixing



Process No. of events

Event/size

CPU power

Volume of data

MB kSI2k-s TBEvent generation

107 0.06 156

Simulation 107 1.9 504 30

Pile-up/Digitization

107 3.3/1.9 ~144/16 ~35

Event mixing & Byte-stream

107 2.0 ~5.4 ~20

Los DC2 de ATLAS empezaron la fase de simulación en Julio 2004 y Los DC2 de ATLAS empezaron la fase de simulación en Julio 2004 y acabó en Septiembre del mismo año. acabó en Septiembre del mismo año.

Se generaron 10 millones de sucesos distribuidos en 100000 trabajosSe generaron 10 millones de sucesos distribuidos en 100000 trabajos La digitalización y el Pile-up acabaron en Diciembre 2004 y corrió La digitalización y el Pile-up acabaron en Diciembre 2004 y corrió

sobre una muestra de 2 millonessobre una muestra de 2 millones Se utilizaron las tecnologías Grid (3 proyectos)!!!!! Se utilizaron las tecnologías Grid (3 proyectos)!!!!!



Los tres “sabores” Grid LCG (http://lcg.web.cern.ch/LCG/)

The job of the LHC Computing Grid Project – LCG – is to prepare the computing is to prepare the computing infrastructure for the simulation, processing and analysis of LHC data for all four of the LHC infrastructure for the simulation, processing and analysis of LHC data for all four of the LHC collaborations.collaborations. This includes both the common infrastructure of libraries, tools and frameworks required to support the physics application software, and the development and deployment of the computing services needed to store and process the data, providing batch and interactive facilities for the worldwide community of physicists involved in LHC.

NorduGrid (http://www.nordugrid.org/) The aim of the NorduGrid collaboration is to deliver a robust, scalable, portable and fully is to deliver a robust, scalable, portable and fully

featured solution for a global computational and data Grid systemfeatured solution for a global computational and data Grid system. NorduGrid develops and deploys a set of tools and services – the so-called ARC middleware, which is a free software.

Grid3 (http://www.ivdgl.org/grid2003/) The Grid3 collaboration has deployed an international Data Gridhas deployed an international Data Grid with dozens of sites and

thousands of processors. The facility is operated jointly by the U.S. Grid projects iVDGL, GriPhyN and PPDG, and the U.S. participants in the LHC experiments ATLAS and CMS.

Los tres proyectos utilizan Globus. Solamente Los tres proyectos utilizan Globus. Solamente existen pequeñas diferencias en el middleware existen pequeñas diferencias en el middleware



ARC is based on Globus Toolkit with core services replaced

– Currently uses Globus Toolkit 2

Alternative/extended Grid services:

– Grid Manager that • Checks user credentials

and authorization• Handles jobs locally on

clusters (interfaces to LRMS)

• Does stage-in and stage-out of files

– Lightweight User Interface with built-in resource broker

– Information System based on MDS with a NorduGrid schema

– xRSL job description language (extended Globus RSL)

– Grid Monitor Simple, stable and non-

invasive

LCG-2 core packages:– VDT (Globus2,, condor)

– EDG WP1 (Resource Broker, job submission tools)

– EDG WP2 (Replica Management tools) + lcg tools

• One central RMC and LRC for each VO, located at CERN, ORACLE backend

– Several bits from other WPs (Config objects, InfoProviders, Packaging…)

– GLUE 1.1 (Information schema) + few essential LCG extensions

– MDS based Information System with significant LCG enhancements (replacements, simplified)

– Mechanism for application (experiment) software distribution

Grid environment built from core Globus and Condor middleware, as delivered through the Virtual Data Toolkit (VDT)

– GRAM, GridFTP, MDS, RLS, VDS

…equipped with VO and multi-VO security, monitoring, and operations services

…allowing federation with other Grids where possible, eg. CERN LHC Computing Grid (LCG)

– USATLAS: GriPhyN VDS execution on LCG sites

– USCMS: storage element interoperability (SRM/dCache)

NORDUGRID LCG GRID3



•100 centros, 22 paises (Estos números aumentan rápidamente)•6558 TB•~10000 CPUs (compartidas)

LCGLCG Esta Esta

infraestructura infraestructura lleva trabajando lleva trabajando desde el 2003.desde el 2003.

Los recursos Los recursos (tanto de (tanto de computación computación como de como de almacenamiento) almacenamiento) están instalados están instalados en RC (Regional en RC (Regional Centers) Centers) conectados por conectados por redes de alta redes de alta velocidad. velocidad.



NorduGridNorduGrid Es una colaboración de Es una colaboración de

investigación formada investigación formada principalmente por los principalmente por los países nórdicos, aunque países nórdicos, aunque hay otros países.hay otros países.

Fueron los únicos que Fueron los únicos que contribuyeron a los DC1 contribuyeron a los DC1 utilizando el Grid.utilizando el Grid.

Son los únicos que Son los únicos que soportan diferentes soportan diferentes distribuciones a RedHat. distribuciones a RedHat.

•11 paises, 40+ centros, ~4000 CPUs, •~30 TB almacenamiento



GRID3GRID3 Dicha infraestructura lleva trabajando desde Nov 2003.Dicha infraestructura lleva trabajando desde Nov 2003. Actualmente corriendo 3 aplicaciones de Física de Altas Actualmente corriendo 3 aplicaciones de Física de Altas

Energías y 2 de Biología.Energías y 2 de Biología. Mas de 100 usuarios corriendo en Grid3. Mas de 100 usuarios corriendo en Grid3.

Sep 04•30 centros, multi-VO•Recursos compartidos•~3000 CPUs



Producción de ATLAS en los DC2

-20000

0

20000

40000

60000

80000

100000

120000

140000

4062

3

4062

6

4062

9

4070

2

4070

5

4070

8

4071

1

4071

4

4071

7

4072

0

4072

3

4072

6

4072

9

4080

1

4080

4

4080

7

4081

0

4081

3

4081

6

4081

9

4082

2

4082

5

4082

8

4083

1

4090

3

4090

6

4090

9

4091

2

4091

5

4091

8

Days

Nu

mb

er

of

job

s

LCGNorduGridGrid3Total

Simulación G4

Day

# V

alid

ated

Job

s

total



LCG1%

2%

0%

1%

1%

21%

2%

1%

1%

10%

8%4%1%4%

0%

1%

4%

2%

2%

0%

3%

1%

13%

0%

0%

1%

1%11%

1% 4%

at.uibk

ca.triumf

ca.ualberta

ca.umontreal

ca.utoronto

ch.cern

cz.golias

cz.skurut

de.fzk

es.ifae

es.ific

es.uam

fr.in2p3

it.infn.cnaf

it.infn.lnf

it.infn.lnl

it.infn.mi

it.infn.na

it.infn.roma

it.infn.to

nl.nikhef

pl.zeus

tw.sinica

uk.bham

uk.ic

uk.lancs

uk.man

uk.ral

uk.shef

uk.ucl

NorduGrid

50%

12%

8%

3%

3%

3%

3%

2%

2%

2%

2%

2%

2%

2%

2%

0%

0%

SWEGRID

brenta.ijs.si

benedict.aau.dk

hypatia.uio.no

farm.hep.lu.se

fire.ii.uib.no

fe10.dcsc.sdu.dk

lxsrv9.lrz-muenchen.de

atlas.hpc.unimelb.edu.au

grid.uio.no

lheppc10.unibe.ch

morpheus.dcgc.dk

genghis.hpc.unimelb.edu.au

charm.hpc.unimelb.edu.au

lscf.nbi.dk

atlas.fzk.de

grid.fi.uib.no

ATLAS DC2 - CPU usage

41%

30%

29%

LCG

NorduGrid

Grid3

Grid3

5%

12%

13%

4%

6%

10%6%

1%

1%

4%

4%

13%

1%

3%

0%

17%

1%

BNL_ATLAS

BNL_ATLAS_BAK

BU_ATLAS_Tier2

CalTech_PG

FNAL_CMS

IU_ATLAS_Tier2

PDSF

Rice_Grid3

SMU_Physics_Cluster

UBuffalo_CCR

UCSanDiego_PG

UC_ATLAS_Tier2

UFlorida_PG

UM_ATLAS

UNM_HPC

UTA_dpcc

UWMadison

Producción de ATLAS en los DC2



Análisis de datos utilizando el sistema de producción



Definimos una transformación de Análisis Se definen los parámetros:

<infilename> ..... name of input file (full path)“

<histfilename> .... HIST output filename"

<ntuplefilename> .... NTUPLE output filename"

<nevt> ........... number of output events to be processed"

<skip> ........... number of input events to be skipped" Implementamos nuestro algoritmo de análisis (Usamos en este caso ttbar)

get_files -jo ttbarExample_jobOptions.py Se genera el fichero de configuración para correr Athena

cat >> input.py << EOF

EventSelector.InputCollections=file_list

theApp.EvtMax = $NEVT

theApp.SkipEvents = $SKIP

HistogramPersistencySvc.OutputFile = "$HISTFN";

NTupleSvc.Output = [ "FILE1 DATAFILE='$NTUPFN' OPT='NEW'" ]

EOF Corremos Athena con las opciones de nuestro trabajo

time athena.py ttbarExample_jobOptions.py input.py >& logANA



Declaramos la transformación en la base de datos: usando phpORAdmin.

Definimos los trabajos en la base de datos asociados a dicha transformación: con prodcom

Instalamos una instancia de Windmill y Lexor configurados para que ejecuten nuestros trabajos:

Se instaló en el UI (lcg2ui2.ific.uv.es), y se utilizó el Resource Broker (lcg2rb2.ific.uv.es) y BDII del IFIC-Valencia.

Modificamos el wrapper (Lexor_wrapper.sh) de Lexor para que pudiera coger nuestra transformación:

wget http://ific.uv.es/~sgonzale/kitvalidation/packages/10.0.0.1/JobTransforms-10-00-00-01.tar.gz

tar xvzf JobTransforms-10-00-00-01.tar.gz



Se utilizó el siguiente dataset: rome.004100.recov10.T1_McAtNLO_top

Muestra ttbar 50 sucesos por fichero, un total de 7000 ficheros

Se definieron 70 trabajos con 100 ficheros de entrada en la base de datos utilizando prodcom: e.g. Rome.004100.recov10.T1_McAtNLO_top._[00001-00100].AOD.pool.root

Se enviaron y ejecutaron estos trabajos utilizando nuestra instancia de Lexor+windmill Los trabajos corrieron en diferentes institutos LCG (ific.uv.es, gridpp.rl.ac.uk,

farmnet.nikhef.nl, etc..) Cada trabajo produjo 3 ficheros de salida, los cuales

fueron almacenados en Castor (IFIC-Valencia, Taiwan, CERN), por ejemplo: rome.analysis.large.23.hist.root rome.analysis.large.23.ntup.root rome.analysis.large.23.log

Los 70 histogramas fueron concatenados en uno: Utilizamos para ello la macro de root: $ROOTSYS/bin/hadd Los histogramas fueron abiertos con RFIO (almacenados en Castor)



Reconstrucción de la masa invariante del W desintegrándose a jet-jet (W->jj): A la izquierda uno de los 70 histogramas producidos a través del sistema de producción de ATLAS a

la Grid A la derecha una vez hecho el encadenamiento de los 70 histogramas Hemos analizado 350000 sucesos350000 sucesos!!!



El trabajo solo dura 4 minutos en el Worker Node, pero tarda en total 4 Horas: Se “pierde” mucho tiempo copiando los ficheros de entrada al Worker Node (la redla red y las cintas en el

caso de Castor) donde realmente el trabajo corre, copiando los ficheros de salida al Storage Element seleccionado y enviando el trabajo al Computing Element elegido por el Resource Broker.

Parece lógico en este caso (Análisis) mandar el trabajo allá donde estén los datos de entrada.



Conclusiones



ATLAS ha sido el primer experimento LHC que ha utilizado las tecnologías GRID para llevar a cabo una producción masiva de datos simulados a la totalidad del ejercicio. Se han utilizado 3 “sabores” de GRID. La producción ha sido llevada acabo de una forma coherente y automática.

Los Data Challenges 2 nos han enseñado que todos los elementos involucrados en el sistema de producción de ATLAS necesitan mejoras En tres meses (Julio a Septiembre 2004), se enviaron mas de 235000

trabajos, se consumió mas de 1.5Millones specint2000/mes de CPU y se produjeron más de 30 TB de datos.

El modelo de análisis propuesto por ATLAS se probó con éxito en el sistema de producción. En menos de 4 horas 350000 sucesos fueron “analizados”. Dichos sucesos

estaban almacenados en diferentes lugares por todo el mundo y los trabajos de análisis se ejecutaron en un gran abanico de centros.

Documents

Uso del GRID en generación masiva de Datos: Sistema de producción del Experimento ATLAS