Les calculs de QCD sur réseau au CC-IN2P3

Présentation au sujet: "Les calculs de QCD sur réseau au CC-IN2P3"— Transcription de la présentation:

1 Les calculs de QCD sur réseau au CC-IN2P3
Jaume Carbonell (Groupe “qcd”) Réunion d’expériences CC-IN2P3 Lyon, 7 Novembre 2007

2 Menu I. Les étapes d’un calcul LQCD
II. Comment le CC intervient dans chacune III. Comment nous souhaiterions qu’il intervienne… IV. Et tout cela pourquoi?

3 NB: ici le « réseau » n’est pas une « grid » mais l’espace-temps discrétisé
V= L3 x T sites L T V Sur chaque site: - 4 matrices de SU(3) (gluons) - 3 x 4 x Ns « champs » complexes (quarks)

4 I. Les étapes d’un calcul de QCD sur réseau
A. Générer le champs de gluons solution de la théorie complète: B. “Propager” les quarks dans ce “fonds”, i.e. calculer C. Calculer les observables - masses - decay constants - facteurs de forme - PDF et GPD - …. On se ramène toujours à de « simples » manipulations algébriques avec S « Configuration de jauge »

5 II. Comment le CC intervient dans chacune
A. Champs de gluons Configurations générées dans d’autres centres par des ordinateurs dédiés e.g. pour ETMC (European Twisted Mass Collaboration APENext (Roma) Blue Gene L (Julich) Mare Nostrum (Barcelona) Altix (Munich) La France a acheté en APE, installées à Roma, mais ne tient pas encore (?) son rang: Rien que dans ETMC 1/6 de l’Italie 1/20 de l’Allemagne (devient 1/100 pour LQCD) 1/2 de l’Espagne 1/2 Angleterre (devient 1/10 pour LQCD) Ceci a permis malgré tout de ne pas disparaître (!) et d’intégrer ETMC C’est la partie la plus difficile de LQCD (Cours de Ph. Boucaud 4-5 déc au LPT sur HMC/PHMC) Hors ETMC, il n’y a pas en France les moyens de calcul pour faire ce travail Le CC participe de façon essentielle dans le stockage et mise en commun des confs U(x) L T Giga se comptent par milliers (différentes masses de quarks, mailles de réseau…) ILDG (International Lattice Data Grid) pour un « trafic de confs » au niveau mondial HPSS/SRB au service de la communauté française.

6 B. Calcul des propagateurs de quarks … pour chaque conf !
On est ramené à la résolution d’un système linéaire de taille conséquente…(e.g. pour L=32 dim(D)=50 millions de réels*8) Pour L=24 les calculs se font presque tous au CC (1 calcul = 2-3 jours CPU) ramener les confs par SRB (ou rfcp) résoudre les systèmes linéaires (12 par quark) stocker les propagateurs S par SRB (du scratch de la machine distante au HPSS) L T Giga/quark ….. se comptent aussi par milliers Pour L=32 (6 jours CPU) les classes de batch du CC ne le permettent pas les essais sur PISTOO ne sont pas concluants Le CC participe de façon essentielle dans le stockage des propagateurs (HPSS/SRB) Nous avons actuellement 36 Tera sur HPSS

7 B. Calcul des observables
Les calculs consistent en des contractions de Wick et se ramènent à de simples manipulations algébriques des propagateurs S(x) Ils ne nécessitent pas des runs très longs Les difficultés viennent : - de la taille des S (Pour L=32, u+d+s=15 Giga) - du fait qu’il faut moyenner sur plusieurs centaines de propagateurs, stockés au CC Le fait de pouvoir disposer sur place d’un accès rapide à HPSS rend le CC indispensable pour mener à bien ce type de calculs Le problème est que les accès I/O massifs sont extrêmement pénalisants dès lors que plus d’un job tourne sur un « worker ». pour L=24 ça passe pour L=32 ça casse

8 III. Comment nous souhaiterions qu’il intervienne
Au niveau du stockage, surtout ne changez rien, le CC est au top !!! - Pouvons-nous continuer à stocker au même rythme (5 Tera/mois) ? - Quelles sont les conditions aux limites ? Il y a juste un « petit » problème d’accès Au niveau CPU, on aurait besoin de: - La possibilité de tourner 150 jobs simultanés, dont au moins une vingtaine sur des machines 16 Giga en classe J - Rallonger les classes batch à une semaine Il nous est très difficile de traduire cette demande en « unités IN2P3 » sans courir de risques… S’il le faut on écrira un mail a support !

9 IV. Et tout cela pourquoi ?
Il existe deux séries de travaux en LQCD utilisant le CC Collaboration ETMC Grenoble (LPSC), Orsay (LPT), Saclay (SPhN)

10 Nos résultats sur N et Δ sont parmi
les meilleurs (en toute modestie…) On poursuit avec Mais aussi avec: Parton distribution fonction (PDF, GPD) Facteurs de forme électromagnétique du N Facteurs de forme étrange (dès que les confs arriveront…) Et quelques sujets en veilleuse (QGP, Yukawa,…)

11 Facteurs de Forme Il faut introduire un couplage à “mi chemin” (F. de Green à 3 points) Jlab

12 Physique des saveurs Orsay (LPT) Etude des désintégrations semileptoniques, e.g. D → π l  avec l =e,µ Activité expérimentale CLEOC BaBar Stanford BELLE Japon LHCb CERN qui n’est pas prête de s’arrêter dans les années qui viennent On mesure les largeurs. On peut en déduire qqchose (CKM) ssi on calcule les f’s Les erreurs sur V sont dominées par les « mauvais calculs des f’s » La balle est dans le camp des théoriciens (…pour l’instant)

13

14 Conclusion La contribution du CC à la LQCD est
- Essentielle en ce qui concerne le stockage des données L’une des vocations premières du centre, et ici il excelle !!! - Très importante pour une partie des calculs « compatibles  » avec le fonctionement actuel Limitée à cause de : - petit nombre de CPU dont on dispose - classes batch inférieures aux durées des jobs (6 jours) - problèmes I/O imposant un utilisateur par machine (16 Giga) Pour nous l‘idéal serait de pouvoir tout faire au CC - Minimise les déplacements des données I/O - Assure une maintenance au top En attendant…..

15 UN GRAND MERCI ! Suzanne Poulat Thomas Kachelhoffer Wojciech Wojcik
Philippe Olivero Jean Yves Nief Julien Devemy Ghita Rahal Dominique Boutigny ….. Et tous les anonymes qui se cachent derrière « user support »