Le groupe informatique au L.L.R.

1. Le groupe informatiqueau L.L.R. Paulo Mora de Freitas Congrès du L.L.R., mai 2004, Paris.

2. Avec les tendances annoncées aux Journées Informatiques IN2P3/DAPNIA lors de la semaine dernière. L’informatique au L.L.R. • Introduction • Équipement • Organisation du groupe • Personnel • Service • Développement • Conclusions

3. L’informatique au L.L.R. : le cadre • ~100 personnes au laboratoire • 15 personnes dans le groupe, dont 5 font du service • Activités et besoins informatiques partout => 100 utilisateurs tous profils confondus

4. Tendance DATAGRID : autant de grilles que d’expériences, voire plusieurs grilles par expérience. Profil physicien • Calcul • Évolution des plateformes : Sun, HP => PC Linux • Utilisation des fermes de calcul du CCIN2P3 (CMS, Babar, FLC, Astroparticules) • Utilisation des sites « remote » (Babar, Phenix, H1) • Mais aussi : moyens locaux importants (puissance de calcul, volume d’espace disque, vitesse réseau) • Développement • Demandeurs de développements spécifiques on-line et off-line (nos « clients ») • Développeurs de code spécifique à leurs expériences: besoin de support et encadrement dans des évolutions techniques de taille (Ex : F77 -> OO) Le temps des règles de codage fleuve est dépassé. On est maintenant conscient que seul ce qui peut automatiquement généré et/ou contrôlé est utilisable . Le langage qui monte : python. On a besoin d’un langage gros grain, évitant aux utilisateurs/développeurs de ne pas se plonger dans le C++.

5. Profil ITA • Informatique • réseau,sauvegardes,achats,sécurité informatique, développements (PC Windows et Linux) • Administration • Comptabilité, achats, gestion personnel (PC Windows) • Électronique • Conception et simulation des cartes (PC Windows, SUN-Solaris) • Banques de tests, acquisition de données, contrôle (PC Windows ou Linux, VME, etc.) • Mécanique • conception et simulation des pièces, Catia (PC Windows)

6. Aujourd’hui, pas de choix possible entre windows, linux et MacosX : il faut supporter les trois. Coté GUI, la seule solution pour satisfaire les utilisateurs : faire du windows sur windows, du mac sur mac, du gtk sur gnome, … peut-être XML peut permettre d’avoir une description commune unique. Besoins communs : • Postes de travail (PC Windows/Linux, Mac,TX) • Bureautique (Office, StarOffice, Acroread...) • Imprimantes (A3/A4, N&B/couleur) • Accès au réseau pour : • Transfert de données et de logiciels • Recherche d’information (Web) • Communication (mail, vidéoconférence) • Accès aux imprimantes • Environnement sécurisé • Support pour l’achat, la configuration, l’installation et la maintenance du matériel informatique, des logiciel et consumables

7. Équipements collectifs • Serveurs de calcul dédiés (différentes versions du système, logiciels) par groupe de taille important au laboratoire (CMS, Babar) • 1 serveur pour usage en commun • Serveurs pour assurer des services • Web, mail, DNS, Intranet, imprimantes • Serveur de fichiers • Serveur de sauvegarde • Visioconférence • 2 lignes Numeris ->2 connexions Codec simultanées • VRVS: 1 poste public, et plusieurs PC équipés

8. Organisation du groupe • Depuis toujours une organisation « matricielle » • Même responsable de groupe depuis sa création il y a presque 30 ans (M.Rumpf) • Nouveau responsable de groupe depuis le 1er avril 2003 : • Occasion pour essayer de dépasser une gestion du type « familiale » vers un management plus proche d’une S.S.I.I. avec une « démarche qualité » (DQ) • Réunions de groupe mensuelles

9. Personnel • Taille constante depuis des années • 8 IR, 4 IE, 3 techniciens • Pyramide d’age • + politique du CNRS : gros problèmes à moyen terme • problème lourd du service • sur embaucher pour étaler la bosse

10. Pyramide des ages

11. L’activité « Service » • 1/3 du groupe : M.Bachelerie, J.Doublet, M.Maubras, C.Roy*, B.Taklifi • Mouvance TX => PC dans tous les groupes • 1 à 2 postes par personne : croissance importante en nombre et en complexité • Problèmes spécifiques • Électronique (Cadence sur SUN) • Liberté d’achat des groupes de physique : MAC • Sensés partir à la retraite d’ici quelques années

12. Parc informatique au L.L.R. : Postes de travail 143 PC (62 Linux, 81 Windows) Calcul Service 3 Serveurs biprocesseurs PC/Linux : CMS, Babar, LABO 5 Serveurs PC/Linux : Web, mail, Intranet, DNS, TiNa, Modems, 1 serveur PC/Windows NAS 15 Mac 5 TX 6 imprimantes (1 serveur Impr.) 1 HP-UX J282 LABO 1 SUN Solaris CAO 1 SUN Solaris Babar 7 SUN Solaris CAO 14 modems ~ 200 machines

13. Nouvelle configuration : Rack 1 Gbits/s Réseau Ecole PC 100 Mbits/s 1 Gbits/s serveurs TINA PC 1 Gbits/s 1 Gbits/s 1 Gbits/s 100 Mbits/s B2000 1 Gbits/s PC 100 Mbits/s SWITCH 1 Gbits/s 100 Mbits/s

14. Management côté service • Interface utilisateurs : • Une interface unique via message à support-info@poly.in2p3.fr pour : • Améliorer le temps de réponse • Garder de traces (DQ) • Analyse postérieur pour création des FAQ • Établissement de procédures (DQ) pour : • L’arrivée et le départ de personnel • Mouvement de matériel • Un correspondant informatique par expérience ou groupe • Réunions « utilisateurs » mensuelles avec compte – rendu (DQ) • En interne : • Réunions d’avancement hebdomadaires • Database du matériel informatique (J.Doublet) • Développements d’outils spécifiques en amont (D.Decotigny) • ET APRES ???

15. L’activité « Développement » • CMS • GRID: unique labo IN2P3 I.Semeniouk • Production Monte Carlo AM.Gaillac • OVAL D.Chamont • Traitement faisceau test H4 I.Semeniouk • Appui aux activités mécanique + électronique J.Gilly, M.Cerutti • Babar/Geant4 P.Mora de Freitas • FLC • Simulation du modèle détecteur G.Musat, P.Mora de Freitas • Acquisition de données banc de tests S.Chollet • GLAST • Fuzzy Clustering G.Musat • ROOT IO U.Berthon • H1 • Graphique offline M.Cerutti • Cadre d’analyse en ROOT U.Berthon • Phenix • Acquisition de données bras Nord S.Chollet EVOLUTION IMPORTANTE DES COMPETENCES

16. Ventilation des efforts dedéveloppement – mai 2004

17. Architecture des systemes d'acquisition et contrôle Banc test de cartes électroniques Developpement de drivers Programmation Microcontrolleurs – DSP LabView Théorie (ordonnancement) Calcul scientifique Packages Hautes Energies (Geant4, Root, CLHEP, ORCA, Gaudi…) Modélisalition de données Systèmes de base de données Programmation SQL Objectivity XML ROOT Java LabView Technologies « Web » (HTML, PHP, etc) Méthodologie objet (UML) Test Logiciel Remaniement Logiciel Compétences • Temps réel • Offline (Simulation, reconstruction, analyse) • Génie logiciel (modélisation et management de projets) • Modélisation et management de données • Interface home - machine (IHM) • A VOUS DE JOUER !

18. Peu de personnes par projets (trop de projets par labo ?). Il faut répartir les forces et découper les gens en morceaux. Management côté développement • Avant : • Organisation « matricielle » mais agents attachés aux expériences • Temps d’attachement relativement flou • Tendance à garder l’agent via plusieurs petits projets au long du temps • Difficulté à rationaliser l’emploie des connaissances et acquis en fonction des besoins • Transition vers : • Ventilation de l’activité des agents dans des projets et missions • Optimisation des ressources (attachement aux projets en fonction des compétences maîtrisées par l’agent) • Meilleur amortissement des efforts de formation et recyclage • Besoins dans cette évolution • Une maîtrise des compétences (DQ) • Le développement d’une « culture » dans l’évolution de cahiers de charge (il faut déjà les avoir!!!) (DQ) • « jouer le jeu » Apparition d’un support aux infrastructures/outils de développement transverse aux experiences (traduit la plus grande utilisation d’outils de dévelopement). Les développeurs ne se contente plus de développer, mais fournissent un service aux physiciens qui développent. Outils commerciaux (hors jeux à cause des grosses collaborations internationales ou tout le monde ne peut pas s’aligner et payer pour le choix centralisé) ou développement interne (trop lourde) ? ni l’un ni l’autre : open source, mais il faut contribuer vraiment au code. Nombreux outils et de plus en plus transitoires. On ne peut plus suivre. Deux approches : 1. ceux qui prechent pour une architecture hyper-flexible, hyper-ouverte, hyper-modulaire (Open-Scientist); 2. ceux qui pensent qu’on ne peut pas être complètement et suffisamment flexible pour suivre, et qu’il faut s’en tenir à quelques choix forts, et s’appuyer sur un seul environnement contraint (ROOT). LCG n’a pas arbitré clairement.

19. conclusion • Visibilité dans collaborations • stratégie d’acquis des connaissances réutilisables • Groupe fait face • à l’évolution du service (non sans peine) • à l’évolution des techniques • à l’évolution du management et du besoin d’une démarche qualité • Menaces • Problème des effectifs • Explosion de la complexité côté service • Sous utilisation des compétences