EGEE User Forum

Europe/Zurich
CERN

CERN

Description

The EGEE (Enabling Grids for E-sciencE) project provides the largest production grid infrastructure for applications. In the first two years of the project an increasing number of diverse users communities have been attracted by the possibilities offered by EGEE and have joined the initial user communities. The EGEE user community feels it is now appropriate to meet to share their experiences, and to set new targets for the future, including both the evolution of the existing applications and the development and deployment of new applications onto the EGEE infrastructure.

The EGEE Users Forum will provide an important opportunity for innovative applications to establish contacts with EGEE and with other user communities, to plan for the future usage of the EGEE grid infrastructure, to learn about the latest advances, and to discuss the future evolution in the grid middleware. The main goal is to create a dynamic user community, starting from the base of existing users, which can increase the effectiveness of the current EGEE applications and promote the fast and efficient uptake of grid technology by new disciplines. EGEE fosters pioneering usage of its infrastructure by encouraging collaboration between diverse scientific disciplines. It does this to evolve and to expand the services offered to the EGEE user community, maximising the scientific, technological and economical relevance of grid-based activities.

We would like to invite hands-on users of the EGEE Grid Infrastructure to Submit an Abstract for this event following the suggested template.

EGEE User Forum Web Page
Participants
  • Adrian Vataman
  • Alastair Duncan
  • Alberto Falzone
  • Alberto Ribon
  • Ales Krenek
  • Alessandro Comunian
  • Alexandru Tudose
  • Alexey Poyda
  • Algimantas Juozapavicius
  • Alistair Mills
  • Alvaro del Castillo San Felix
  • Andrea Barisani
  • Andrea Caltroni
  • Andrea Ferraro
  • Andrea Manzi
  • Andrea Rodolico
  • Andrea Sciabà
  • Andreas Gisel
  • Andreas-Joachim Peters
  • Andrew Maier
  • Andrey Kiryanov
  • Aneta Karaivanova
  • Antonio Almeida
  • Antonio De la Fuente
  • Antonio Laganà
  • Antony wilson
  • Arnaud PIERSON
  • Arnold Meijster
  • Benjamin Gaidioz
  • Beppe Ugolotti
  • Birger Koblitz
  • Bjorn Engsig
  • Bob Jones
  • Boon Low
  • Catalin Cirstoiu
  • Cecile Germain-Renaud
  • Charles Loomis
  • CHOLLET Frédérique
  • Christian Saguez
  • Christoph Langguth
  • Christophe Blanchet
  • Christophe Pera
  • Claudio Arlandini
  • Claudio Grandi
  • Claudio Vella
  • Claudio Vuerli
  • Claus Jacobs
  • Craig Munro
  • Cristian Dittamo
  • Cyril L'Orphelin
  • Daniel JOUVENOT
  • Daniel Lagrava
  • Daniel Rodrigues
  • David Colling
  • David Fergusson
  • David Horn
  • David Smith
  • David Weissenbach
  • Davide Bernardini
  • Dezso Horvath
  • Dieter Kranzlmüller
  • Dietrich Liko
  • Dmitry Mishin
  • Doina Banciu
  • Domenico Vicinanza
  • Dominique Hausser
  • Eike Jessen
  • Elena Slabospitskaya
  • Elena Tikhonenko
  • Elisabetta Ronchieri
  • Emanouil Atanassov
  • Eric Yen
  • Erwin Laure
  • Esther Acción García
  • Ezio Corso
  • Fabrice Bellet
  • Fabrizio Pacini
  • Federica Fanzago
  • Fernando Felix-Redondo
  • Flavia Donno
  • Florian Urmetzer
  • Florida Estrella
  • Fokke Dijkstra
  • Fotis Georgatos
  • Fotis Karayannis
  • Francesco Giacomini
  • Francisco Casatejón
  • Frank Harris
  • Frederic Hemmer
  • Gael youinou
  • Gaetano Maron
  • Gavin McCance
  • Gergely Sipos
  • Giorgio Maggi
  • Giorgio Pauletto
  • giovanna stancanelli
  • Giuliano Pelfer
  • Giuliano Taffoni
  • Giuseppe Andronico
  • Giuseppe Codispoti
  • Hannah Cumming
  • Hannelore Hammerle
  • Hans Gankema
  • Harald Kornmayer
  • Horst Schwichtenberg
  • Huard Helene
  • Hugues BENOIT-CATTIN
  • Hurng-Chun LEE
  • Ian Bird
  • Ignacio Blanquer
  • Ilyin Slava
  • Iosif Legrand
  • Isabel Campos Plasencia
  • Isabelle Magnin
  • Jacq Florence
  • Jakub Moscicki
  • Jan Kmunicek
  • Jan Svec
  • Jaouher KERROU
  • Jean Salzemann
  • Jean-Pierre Prost
  • Jeremy Coles
  • Jiri Kosina
  • Joachim Biercamp
  • Johan Montagnat
  • John Walk
  • John White
  • Jose Antonio Coarasa Perez
  • José Luis Vazquez
  • Juha Herrala
  • Julia Andreeva
  • Kerstin Ronneberger
  • Kiril Boyanov
  • Kiril Boyanov
  • Konstantin Skaburskas
  • Ladislav Hluchy
  • Laura Cristiana Voicu
  • Laura Perini
  • Leonardo Arteconi
  • Livia Torterolo
  • Losilla Guillermo Anadon
  • Luciano Milanesi
  • Ludek Matyska
  • Lukasz Skital
  • Luke Dickens
  • Malcolm Atkinson
  • Marc Rodriguez Espadamala
  • Marc-Elian Bégin
  • Marcel Kunze
  • Marcin Plociennik
  • Marco Cecchi
  • Mariusz Sterzel
  • Marko Krznaric
  • Markus Schulz
  • Martin Antony Walker
  • Massimo Lamanna
  • Massimo Marino
  • Miguel Cárdenas Montes
  • Mike Mineter
  • Mikhail Zhizhin
  • Mircea Nicolae Tugulea
  • Monique Petitdidier
  • Muriel Gougerot
  • Nadezda Fialko
  • Nadine Neyroud
  • Nick Brook
  • Nicolas Jacq
  • Nicolas Ray
  • Nils Buss
  • Nuno Santos
  • Osvaldo Gervasi
  • Othmane Bouhali
  • Owen Appleton
  • Pablo Saiz
  • Panagiotis Louridas
  • Pasquale Pagano
  • Patricia Mendez Lorenzo
  • Pawel Wolniewicz
  • Pedro Andrade
  • Peter Kacsuk
  • Peter Praxmarer
  • Philippa Strange
  • Philippe Renard
  • Pier Giovanni Pelfer
  • Pietro Lio
  • Pietro Liò
  • Rafael Leiva
  • Remi Mollon
  • Ricardo Brito da Rocha
  • Riccardo di Meo
  • Robert Cohen
  • Roberta Faggian Marque
  • Roberto Barbera
  • Roberto Santinelli
  • Rolandas Naujikas
  • Rolf Kubli
  • Rolf Rumler
  • Romier Genevieve
  • Rosanna Catania
  • Sabine ELLES
  • Sandor Suhai
  • Sergio Andreozzi
  • Sergio Fantinel
  • Shkelzen RUGOVAC
  • Silvano Paoli
  • Simon Lin
  • Simone Campana
  • Soha Maad
  • Stefano Beco
  • Stefano Cozzini
  • Stella Shen
  • Stephan Kindermann
  • Steve Fisher
  • tao-sheng CHEN
  • Texier Romain
  • Toan Nguyen
  • Todor Gurov
  • Tomasz Szepieniec
  • Tony Calanducci
  • Torsten Antoni
  • tristan glatard
  • Valentin Vidic
  • Valerio Venturi
  • Vangelis Floros
  • Vaso Kotroni
  • Venicio Duic
  • Vicente Hernandez
  • Victor Lakhno
  • Viet Tran
  • Vincent Breton
  • Vincent LEFORT
  • Vladimir Voznesensky
  • Wei-Long Ueng
  • Ying-Ta Wu
  • Yury Ryabov
  • Ákos Frohner
    • 1:00 PM 2:00 PM
      Lunch 1h
    • 2:00 PM 6:30 PM
      1b: Astrophysics/Astroparticle physics - Fusion - High-Energy physics 40/5-A01

      40/5-A01

      CERN

      45
      Show room on map

      Brings together 3 major scientific communities using EGEE for large scale computation and data sharing

      • 2:00 PM
        Benefits of the MAGIC Grid 30m
        Application context and scientific goals ======================================== The field of gamma-ray observations in the energy range between 10 GeV and 10 TeV developed fast over the last decade. From the first observation of TeV gamma rays from the Crab nebula using the atmospheric Cerenkov imaging technique in 1989 [1] to the discovery of new gamma ray sources with the new generation telescopes like the HESS observation of a high-energy particle acceleration in the shell of a supernova remnant [2], a new observation window to the universe was opened. In the future other ground based VHE $\gamma$-ray observatories (namely MAGIC [3], VERITAS [4] and KANGAROO [5]) will significantly contribute to the exploitation of this new observation window. With the new generation Cerenkov telescopes the requirements for the analysis and Monte Carlo production computing infrastructure will increase due to a higher number of camera pixels, faster FADC systems and a bigger mirror size. In the future the impact of VHE gamma-ray astronomy will increase by joined observations of different Cerenkov telescopes. In 2003 the national Grid centers in Italy (CNAF), Spain (PIC) and Germany (GridKA) started together with the MAGIC collaboration an effort to build a distributed computing system for Monte Carlo generation and analysis on top of existing Grid infrastructure. The MAGIC telescope was chosen due to the following reasons: o The MAGIC collaboration is international, with most partners from Europe o main partners of the MAGIC telescope are located close to the national Grid centers o The generation of Monte Carlo data is very compute intensive, specially to get enough statistics in the low energy range. o The analysis of the fast increasing real data samples will be done in different institutes. The collaborators need a seamless access to the data while reducing the number of replicas to a minimum. o The MAGIC collaboration will build a second telescope in 2007 resulting in a doubled data rate. The idea of the MAGIC Grid [6] was presented to the EGEE Generic Application Advisory Panel (EGAAP). In June 2004 EGEE accepted the generation of Monte Carlo data for the MAGIC telescope as one of the generic applications of the project. Grid added value ================ By implementing the MAGIC Grid over the last two years, the MAGIC collaboration benefit in many aspects. These aspects are described in this chapter. o Collaboration of different institutes By combining the resources of the MAGIC collaborators and the reliable resources from the national Grid centers the MAGIC collaborators will be empowered to use their computing infrastructure more efficiently. The time to analyse the big amount of data to solve specific scientific problems will be shortend. o Cost reduction By using the EGEE infrastructure and the EGEE services the effort for MAGIC collaboration to build a distributed computing system for the Monte Carlo simulations was significantly reduced. o Speedup of Monte Carlo production As the MAGIC Monte Carlo System was build on top of the EGEE middleware the integration of new computing resources is very easy. By getting support from many different EGEE resource providers the production rate for the Monte Carlos can be increased very easily. o Persistent storage of observation data The MAGIC telescope will produce a lot of data in the future. These data are currently stored on local resources including disk systems and tape libraries. The MAGIC collaboration recognized that this effort is not negligible especially concerning man power. Therefore the observation data will be stored by the spanish Grid center PIC. o Data availability improvements By importing the observation data to the Grid, the MAGIC collaboration expect that the availablitly of data will be increased with the help of Grid data management methods like data replication, etc. As the main data services will be provided in the future by the national Grid centers instead of research university groups at universities, the overall data availablitly is expected to increase. o Cost reduction By using the EGEE infrastructure and the EGEE services the effort for MAGIC collaboration to build a distributed computing system for the Monte Carlo simulations was significantly reduced. Experiences with the EGEE infrastructure ======================================== The experiences of the developers during the different phases of the realisation of the MAGIC Monte Carlo production system on the EGEE Grid infrastructure are described in this chapter. As the MAGIC virtual organisation was accepted as one of the first generic EGEE application, the development process was influenced by general developments within the EGEE project too like changed in the middleware versions, etc. o Prototype implementation -------------------------- The migration of the compute intensive MMCS program from a local batch system to the Grid was done by the definition of a template JDL form. This template sends all needed input data together with the executable to the Grid. The resources are chosen by the resource broker. The automatic registration of the output file as a logical file on the Grid was not very reliable at the beginning, but improved to production level within the EGEE project duration. o Production MAGIC Grid system ------------------------------ The submission of many production system needed the implementation of a graphical user interface and a database for metadata. The graphical user interface was realised with the JAVA programming language. The execution of the LCG/gLite commands is wrapped in JAVA shell commands. A MySQL database holds the schema for the metadata. As mentioned above the "copy and register" process for the output file was not realiable enough an additional job status "DONE (data available)" was invented. With the help of the database, jobs that did not reach this job status within two days are resubmitted. The job data are keeped in a seperate database table to analyse them later. o Reliability of EGEE services ------------------------------ The general services like resource brokers, VO management tools and Grid user support was provided by the EGEE resources providers. The MAGIC Grid is setup on top of this services. A short report of the experiences with this production services will be given. Key issues for the future of Grid technology ============================================ The MAGIC collaboration is currently evaluating the EGEE Grid infrastructure as the backbone for a distributed computing system in the future including the data storage on Grid data centers like PIC. Furthermore the discussion with other projects like the HESS collaboration has started to move towards "Virtual Very High energetic Gamma ray observatory" [7]. The problems and challenges that needs to be solved on the track to a sustainable Grid infrastructure will be discussed from the user perspective References: [1] T. Weekes et al., The Astrophysical Journal, volume 342 (1989), p. 379 [2] F. A. Aharonian et al., Nature 432, 75 - 77 (04 November 2004) [3] E. Lorenz, 1995, Fruehsjahrtagung Deutsche Physikalische Gesellschaft, March 9-10 [4] T. Weekes et al., Astropart. Phys., 17, 221-243 (2002) [5] Enomoto, R. et al., Astropart. Phys. 16, 235-244 (2002) [6] H. Kornmayer et al., "A distributed, Grid-based analysis system for the MAGIC telescope", Proceedings of the CHEP Conference , Interlaken, Switzerland, 2004 [7] H. Kornmayer et al., "Towards a virtual observatory for high energetic gamma rays", Cherenkov 2005, Paris, 2005
        Speaker: Dr Harald Kornmayer (FORSCHUNGSZENTRUM KARLSRUHE (FZK))
      • 2:30 PM
        Status of Planck simulations application 30m
        1. Application context and scientific goals An accurate measure of the whole sky emission in the frequencies of the microwave spectrum and in particular of the Cosmic Microwave Background (CMB) anisotropies can have crucial implications for the whole Astrophysical community as it permits to determine a number of fundamental quantities that characterize our Universe, its origin and evolution. The ESA Planck mission is aimed to map the microwave sky performing at least two complete sky surveys with an unprecedented combination of sky and frequency coverage, accuracy, stability and sensitivity. The satellite will be launched in 2007 carrying a payload composed of a number of microwave and sub-millimetre detectors which are grouped into a high frequency instrument (HFI) and a low frequency instrument (LFI) covering frequency channels ranging from 30 up to 900 GHz. The instruments are built by two international Consortia which are also in charge of the related Data Processing Centres (DPCs). The LFI DPC is located in Trieste, the HFI DPC is distributed between Paris and Cambridge. In both Consortia, participation in the development of the data processing software to be included in the DPCs is geographically distributed throughout the participating Institutions. The overall Planck community is composed of over 400 scientists and engineers working in about 50 institutes spread in 15 countries, mainly in Europe but including also Canada and the United States. A fraction of this community, the one possibly involved with Grid activities, can be defined as the Planck Virtual Organisation (VO). During the whole of the Planck mission (Design, Development, Operations and Post- operations), it is necessary to deal with aspects related to information management, which pertain to a variety of activities concerning the whole project, ranging from instrument information (technical characteristics, reports, configuration control documents, drawings, public communications, etc.), to the proper organisation of the processing tasks, to the analysis of the impact on science implied by specific technical choices. For this purpose, an Integrated Data and Information System (IDIS) is being developed to allow proper intra-Consortium and inter-Consortia information exchange. Within the Planck community the term "simulation" refers to the production of data resembling the output of the Planck instruments. There are two main purposes in developing simulation activities: - during ESA Phase A and instrument Phases A and B, simulations have been used to help finalising the design of the Planck satellite’s P/L and Instruments hardware; - on a longer time-scale (up to launch), simulated data will be used mainly to help develop the software of the data processing pipeline DPCs, by allowing the testing of algorithms needed to solve the critical reduction problems, and by evaluating the impact of systematic effects on the scientific results of the mission, before real data are obtained. The output of the simulation activity is Time-Ordered Information (TOI), i.e. a set of time series representing the measurements of the scientific detectors, or the value of specific house-keeping parameters, in one of the Planck instruments. TOI related to scientific measurements are often referred to as Time-Ordered Data (TOD). Common HFI-LFI tools have been built and integrated in order to build a pipeline system aimed at producing simulated data structures. These tools can be decomposed in several stages, including ingestion of astrophysical templates, mission simulator, S/C simulator, telescope simulator, electronics and on-board processing simulator. Other modules, such as the cooling system model, the instruments simulators and the TM packaging simulator, are instrument-dependent. It should be noted that the engine integrating all the tools has to be flexible enough in order to produce the different needed forms or formats of data. The Planck Consortia participate to this joint simulations effort to the best of their scientific and instrumental knowledge, providing specific modules for the simulations pipeline. For each Consortium the code allowing to produce maps and time- ordered sequences out of simulated microwave skies is the one jointly produced for both Consortia: data simulated by HFI and LFI are therefore coherent and can be properly merged. To the output data of the common code (timelines) an additional LFI- specific code is applied to simulate on-board quantisation and packetisation, in order to produce streams of LFI TM packets. The goal of this application is the porting of the whole simulation software of the Planck mission on the EGEE Grid infrastructure. 2. The grid added-value Planck simulations are highly computing demanding and produce a huge amount of data. Such resources cannot be usually afforded by a single research institute, both in terms of computing power and data storage space. Our application therefore represents the typical case where the federation of resources coming from different providers can play a crucial role to tackle the shortage of resources within single institutions. Planck simulations take great advantage from this as a remarkable number of resources are available at institutions collaborating in the Planck VO, so they can be profitably invested to get additional resources shared on the Grid. The first simulation tests have been carried out on the INFN production Grid in the framework of the GRID.IT project. A complete simulation for the Planck/LFI instrument has been run on a single, dual-CPU, workstation and on Grid involving 22 nodes, one for each detector of the LFI instrument. The gain obtained by using the Grid was of ~15 times. Another added value coming from the Grid is its authentication/authorization mechanism. Planck code as well as data are not public-domain; we need to protect the software copyright; data moreover are property of the Planck P.I. mission. The setup of a Planck VO makes possible to easily monitor and control accesses to both software and data without the need of arranging tools already available in Grid. Last but not least a federation of users within a VO fosters the scientific collaboration, an added value of key importance in Planck given that users who collaborates to the mission are spread all over Europe and United States. 3. Experiences and results achieved on EGEE Due to some initial issues in the start up process of the Planck VO, we were not able to fully exploit the big amount of potential resources available for our application so far. The Planck VO has proved to be quite difficult to manage; the start up process, in particular, has been slowed down by some difficulties in the interactions between the local Planck VO managers and the respective ROCs. To overcome these issues and make the Planck VO fully operative in a short time on-site visits to Planck VO sites are foreseen in order to train local managers in setting up and maintaining the Planck VO node and even local potential users to foster the usage of the Grid technology for the Planck application needs. 4. Key issues for the promotion of the GRID technology On the basis of our experience with the astrophysical community a special effort is requested to spread the Grid technology and make potential users fully aware of the advantages in using it. User tutorials can be extremely helpful to achieve this goal. Even the preparation of a suite of Grid oriented tools is of key importance like Grid portals and Grid Graphical User Interfaces to make users able to interact with the Grid in an easy and transparent way and to hide some complexities of the underlying technology.
        Speaker: Dr Claudio Vuerli (INAF-SI)
        Slides
      • 3:00 PM
        FUSION ACTIVITIES IN THE GRID 30m
        The future Magnetic confinement Fusion energy research will be mainly based upon large international facilities with the participation of a lot of scientist belonging to different institutes. For instance, the large device ITER (International Tokamak Experimental Reactor) that will be built in Cadarache (France) is participated by six partners: Europe, Japan, USA, Russia, China, and Korea. India is presently involved in negotiations to join the project and Brazil is also considering the possibility of joining the project. Besides ITER, the Fusion community has a strong collaboration structure devoted both to the tokamak and the stellarator research. As a result of this structure, there exists a network of groups and Institutes that are sharing facilities and/or results obtained on those facilities. Magnetic Fusion facilities are constituted by large devices devoted to study Plasma Physics that produce a large amount of data to be analysed (the typical rhythm of data production is about 1 GBy/s for a conventional device that can reach 10 times larger value in ITER). The analysis and availability of those data is a key point for the scientific exploitation of those devices. Also, large computations are needed for understanding plasma Physics and developing new calculation methods that are very CPU time consuming. A part of this computation effort can be performed in a distributed way and Grid technologies are very suitable to perform those calculations. Several Plasma Physics applications are being envisaged for adapting into the grid, those that can be distributed in different processors. The first kind of applications is In particular, Monte Carlo codes are suitable and powerful tools to perform transport calculations , especially in those cases like the TJ-II stellarator that present radially extended ion orbits, which has strong influence on confinement: The fact that orbits are wide makes that ions perform large radial excursions during a collision time, which will enhance outward heat flux. The usual transport calculations based on local plasma characteristics that give local transport coefficients are not suitable for this kind of geometry in the long mean free path regime. The suitable way to estimate transport is to follow millions of individual particles that move in a background plasma and magnetic configuration. The interaction with other particles is simulated by a collision operator, which depends on density and temperature, and by a steady state electric field, caused by the unbalanced electron and ion fluxes. This tool will be also useful to take into account other kinetic effects on electron transport, like those related to heating and current drive. This transport tool is now working in a Supercomputer and is being prepared to be ported to the grid, where will run soon. The capability of performing massive kinetic transport calculations will allow us to explore transport properties in different heating conditions and collisionalities, as well as with different electric field profiles. Another application that requires distributed calculations is the massive ray tracing. The properties of microwave propagation and absorption are estimated in the geometrical optics (or WKB) approximation by simulating the microwave beam by a bunch of rays. Those rays are launched and followed inside the plasma and all the necessary quantities are estimated along ray trajectories. Since all the rays are independent, they can be calculated separately . The number of rays needed in a normal case is typically 100 or 200, and the time needed for every ray estimate is about 10-20 minutes. This approximation works when the waist of the beam is far from any critical layer in the plasma. Critical layers are those where mode conversion, absorption, or reflection of microwaves happens. When the waist of the beam is closed to critical layers, a much higher number of rays is needed to simulate the beam. The typical number can be of the order of 10000, which is high enough to make it necessary to run the application in the grid. Massive ray tracing calculations could also be useful to determine the optimum microwave launching position in a complex 3D device like a real stellarator. These two former applications require that a common file with stellarator geometry data is distributed in all the processors as well as individual files with the initial data of every ray and trajectory. Stellarator devices present different magnetic configurations with different confinement properties. It is necessary to look for the magnetic configuration that present the best confinement properties, considering the experimental knowledge of confinement and transport in stellarators. Therefore, stellarator optimization is a very important topic to design the future stellarators that have to play a role in Magnetic confinement fusion. The optimization procedure has to take into account a lot of criteria that are based on the previous stellarator experience: neoclassical transport properties, viscosity, stability, etc. A possible way to develop this procedure is to parametrize the plasma by the Fourier coefficients that describe the magnetic field. Every set of coefficients is considered as a different stellarator with different properties. The optimization procedure has to take into account the desired characteristics for a magnetic configuration to be suitable for an optimised stellarator. The optimization criteria are set through functions that take into account the properties that favour plasma confinement . Every case can be run in a separate node of the grid in order to explore the hundreds of parameters that are involved in the optimization. Presently, other applications are being considered to be run in the grid in order to solve efficiently some problems on Plasma Physics that are needed for the future magnetic confinement devices. For instance, transport analysis is a key instrument in Plasma Physics that gives the transport coefficients that fit the experimental data. Transport analysis is performed using transport codes on the real plasma discharges. A plasma confinement device can perform tens of thousands of discharges along its life and only a few of them are analysed. It would be possible to install a transport code in the grid that performs automatic transport analysis on the experimental shots. In this way, the dependence of local transport coefficients on plasma parameters like magnetic configuration, density, temperature, electric field, etc. can be extracted. And, finally the tokamak equilibrium code EDGE2D can be installed in the grid to obtain equilibrium parameters in the edge, which is basic to estimate the exact plasma position and the equilibrium properties in the plasma edge.
        Speaker: Dr Francisco Castejon (CIEMAT)
        Slides
      • 3:30 PM
        Massive Ray Tracing in Fusion Plasmas on EGEE 30m
        Plasma heating in magnetic confinement fusion devices can be performed by launching a microwave beam with frequency in the range of the cyclotron frequency of either ions or electrons, or close to one of their harmonics. The Electron Cyclotron Resonance Heating (ECRH) is characterized by the small size of the wavelength that allows one to study the wave properties using the geometrical optics approximations. This means that the microwave beam can be simulated by a large amount of rays. If there is no critical plasma layer (like cut off or resonance) close to the beam waist, it is possible to use the far field approximation and the beam can be simulated by a bunch of one or two hundred rays, which can be performed in a cluster. However, if the beam waist is closed to the critical layer and the heating method uses Electron Bernstein Waves (EBW), the number of rays needed is much larger. Being all the ray computations independent, this problem is well suited to be solved in the grid relying on the EGEE infrastructure [1]. We have developed a MRT (Massive Ray Tracing) framework using the lcg2.1.69 User Interface C++ API. It sends over the grid the single ray tracing application (called Truba [2]) which performs the tracing of a single ray. This framework works in the following way: First of all, a launcher script generates the JDL files needed. Then, the MRT framework launches all the single ray tracing jobs simultaneously, periodically querying each job's state. And finally, it retrieves the job's output. We performed several experiments in the SWETEST VO with a development version of Truba, whose average execution time on a Pentium 4 3.20 GHz is 9 minutes. Truba's executable file size is 1.8 MB, input file size is 70 KB, and output file size is about 549 KB. In the SWETEST VO, there were resources from the following sites: LIP (16 nodes, Intel Xeon CPU 2.80 GHz), IFIC (117 nodes, AMD Athlon 1.2 Ghz), PIC (69 nodes, Intel Pentium 4 2.80 GHz), USC (100 nodes, Intel Pentium III 1133 MHz), IFAE (11 nodes, Intel Pentium 4 2.80 GHz) and UPV (24 nodes, Pentium III). All Spanish sites are connected by RedIRIS, the Spanish Research and Academic Network. The minimum link bandwidth is 622 Mbps and the maximum, 2.5 Gbps. The MRT framework traced 50 rays and it took an overall time of 88 minutes. In this case, we analyzed the following parameters: execution time (how much time took Truba to be executed in the remote resource not including queue time), transfer time, overhead (how much overhead is introduced by the Grid and the framework itself due to all the inner nodes and stages the job passes through) and productivity (number of jobs per time unit). The average execution time was 10.09 minutes and its standard deviation was 2.97 minutes (this is due to the resource heterogeneity). The average transfer time was 0.5 minutes and its standard deviation was 0.12 minutes (this is due to dynamic network bandwidth). The average overhead was 29.38 minutes. Finally, the productivity was 34.09 rays/hour. Nevertheless, we found the lack of opportunistic migration (some jobs remained “Scheduled” for too long) and fault tolerance mechanisms (specially during submission using Job Collections, retrieving output and some “Ready” status that were really “Failed” and took too long to be rescheduled) as limitations of the LCG-2 infrastructure (some of the nodes marked by the GOC as “OK” were not). Even, problems handling Job Collections and submitting more than 80 jobs were found. In order to bypass these problems, we used GridWay, a light-weight framework. It works on top of Globus services, performing job execution management and resource brokering, allowing unattended, reliable, and efficient execution of jobs, array jobs, or complex jobs on heterogeneous, dynamic and loosely-coupled Grids. GridWay performs all the job scheduling and submission steps transparently to the end user and adapts job execution to changing Grid conditions by providing fault recovery mechanisms, dynamic scheduling, migration on-request and opportunistic migration [3]. This scheduling is performed using the data gathered from the Information System (GLUE schema) that is part of the LCG-2 infrastructure. GridWay performs the job execution in three simple steps: Prolog, which prepares the remote system by creating an experiment directory and transferring the needed files. Wrapper, which executes the actual job and obtains its exit status code. And Epilog, which finalizes the remote system by transferring the output back and cleaning up the experiment directory. After performing different experiments in similar conditions, we obtained the following results. The overall time was 65.33 minutes. The average execution time was 10.06 minutes and its standard deviation was 4.32 minutes (this was almost the same with the pilot application). The average transfer time was 0.92 minutes and its standard deviation was 0.68 minutes (this was higher because of the submission of the Prolog and Epilog scripts). The average overhead was 22.32 minutes (this was lower as less elements were taking part in the scheduling process). And finally, the productivity was 45.92 rays/hour. The reason for this higher productivity is that GridWay reduces the number of nodes and stages the job passes through. Also, this productivity is the result of GridWay's opportunistic migration and fault tolerance mechanisms. As a key improvement needed to better exploit this technique on EGEE we can find that the data contained in the Information System should be updated more frequently and should represent the real situation of the remote resource when trying to submit a job to it. This is a commitment between the resource administrator and the rest of the EGEE community. The last aspect we would like to notice is the difference between the LCG-2 API and DRMAA. While the LCG-2 API relays on a specific middleware, DRMAA (which is a GGF standard) doesn't. The scope of this user API specification is all the high level functionality which is necessary for an application to consign a job to a DRM system, including common operations on jobs like synchronization, termination or suspension. In case this abstract is accepted, we would like to perform an on line demonstration. REFERENCES: [1] Massive Ray Tracing in Fusion Plasmas: Memorandum of Understanding. Francisco Castejón. CIEMAT. Spain. [2] Electron Bernstein Wave Heating Calculations for TJ-II Plasmas. Francisco Castejón, Maxim A. Tereshchenko, et al. American Nuclear Society. Volume 46, Number 2, Pages 327-334, September 2004. [3] A Framework for Adaptive Execution on Grids. E. Huedo, R. S. Montero and I. M. Llorente. Software - Practice & Experience 34 (7): 631-651, June 2004.
        Speaker: Mr Jose Luis Vazquez-Poletti (Universidad Complutense de Madrid (Spain))
        Slides
      • 4:00 PM
        break 30m

        COFFEE

      • 4:30 PM
        Genetic Stellarator Optimisation in Grid 30m
        Computational optimisations can be found in a wide area of natural, engineering and economical sciences. They may be carried out by different methods, that include classical gradient-based, genetic algorithms, etc. Stellarator facilities optimisation may be noted as an example of such task. Stellarators are the toroidal devices for magnetic confinement of plasma. In contrast to tokamak (ITER facility, for example), no toroidal current is required here, so that stellarators are principally stationary devices. As a payment for stationary working, stellarators are principally three-dimensional (non axisymmetric) configurations. This can lead to enhanced losses of fast particles - to an enhancement of losses of fast particles - the product of fusion reaction- and plasma. The plasma equilibrium in stellarator can be found if the shape of the boundary plasma surface and the radial profiles of plasma pressure and toroidal current are prescribed. During the last decades it was shown that the properties of the stellarators can be significantly improved by appropriate choice of the shape of the boundary magnetic surface. Because of the large variety of stellarators the optimisation is still under way. Boundary surface may be characterised by a set of Fourier harmonics that give the shape of the surface, the magnetic field, and the electric current. The Fourier coefficients compose a multidimensional space of optimisation (free) parameters and their number may exceed a hundred. The quality parameters are functions depending on optimisation parameters and describing the properties of the considered configuration. As soon as the stellarator plasma equilibrium is found, quality parameters such as stability of different modes, fast particle long time collision-less confinement, neoclassical transport coefficients, bootstrap current, etc. can be computed. In the optimisation task, the measure of optimum, so called a target function, is based on quality parameters and may be, for example, a weighted sum of such parameters. Computation of a stellarator quality parameters set and target function values for a given optimisation parameters vector takes about 20 minutes on conventional PC. Such computation may form a single grid job. The technique presented in this work may be useful for tasks having target function calculation large enough for a job. Splitting each gradient-based optimisation step into several independent grid jobs may be ineffective in case of numerical gradient computation due to hardly asynchronous jobs completion. For such reason, genetic algorithms have been chosen as optimisation methods. Such method treats parameter vector of a variant as a "genome" and imply three activities in each iteration. The activities are selection of "parents", their breeding and computation of target function values for each "child" genome. Initial pool of genomes can be generated randomly inside the optimisation parameters variation domain defined by a user. Genetic method iterations enrich genome pool with new better genomes. Genetic algorithms behave well for grid computations, because genome pool may be appended by grid jobs results sporadically, so aborting or delaying several jobs completion would not affect the overall optimisation process hardly. During the selection, genome with better target function value should have a preference among genomes pool. The following algorithm has been used for choosing "mothers" and "fathers" of a new stellarator generation. Genomes pool is arranged according to target function values, so the better genomes go first. Then, iterations over the pool are carried out until a "father" is chosen. On every iteration, a uniform random number is generated, so current genome is chosen with some user-predefined probability, say 2% or 3%. A "mother" is chosen in the same manner. Such selection algorithm have no direct influence from target function derivatives, so it suppresses fast appearing of "super genome" (i.e. "inbreeding") that may constrain other potentially fruitful genomes. Genetic algorithm breeding in case of continual optimisation domain should not change statistical mean and dispersion of genome pool, because there is no reason to shift, disperse or collect optimisation space points in the breeding activity. Only selection activity should put such changes. The following method preserving such statistical parameters have been used for stellarators. Two coefficients f and m for each Fourier harmonic from every parent vectors pair were bred separately. Every new coefficient was a random number of Gaussian distribution. The distribution had the mean (f+m)/2 and the standard deviation | f-m|/2. A set of scripts realising the technique in Python language have been developed. One of them generates an initial genome pool, another one spawns new jobs for quality parameters computation, the third gathers already computed results from the grid and the fourth generates new part of genome pool depending on the existing one. The number of concurrently spawned jobs is kept below a given threshold. New, running and complete jobs' genomes and quality parameters are stored in files of special directory hierarchy. The iteration is realised by a Bash script. The script implies spawning, gathering, genetic generation scripts and scheduling a new iteration using "at" command. The scripts are intended to run controlled by user commands on LCG-2 user interface host. A test example of stellarator optimisation task have been computed. About 7.500 variant jobs have been spawn, about 1.500 of them were discarded since no equilibria were found. In other 6.000, a set of quality parameters based on the fields and target function values were computed. Histograms representing distribution of target function values in first, second, third, fourth, fifth and sixth thousands of results in order of appearance show that the sets of best values converge to the believed optimum value with the linear order. This technique can be employed fruitfully in developing new stellarator concepts with different optimization criteria. Moreover, the proposed technique based on genetic algorithms and grid computing that works for the stellarator optimisation task can be employed in a wide spectrum of applications, both scientific and practical. REFERENCES 1. ESA Genetic Algorithms Tutorial by Robin Biesbroek, http://www.estec.esa.nl/outreach/gatutor/Default.htm 2. M.I.Mikhailov, V.D.Shafranov, A.A.Subbotin, et.al. Improved alpha-particle confinement in stellarators with poloidally closed contours of the magnetic field strength. // Nuclear Fusion 42 (2002) L23-L26
        Speaker: Mr Vladimir Voznesensky (Nuclear Fusion Inst., RRC "Kurchatov Inst.")
        Slides
      • 5:00 PM
        Experiences on Grid production for Geant4 30m
        Geant4 is a general purpose toolkit for simulating the tracking and interaction of particles through matter. It is currently used in production in several particle physics experiments (BaBar, HARP, ATLAS, CMS, LHCb), and it has also applications in other areas, as space science, medical applications, and radiation studies. The complexity of the Geant4 code requires careful testing of all of its components, especially before major releases (which happens twice a year, in June and December). In this talk, I will describe the recent development of an automatic suite for testing hadronic physics in high energy calorimetry applications. The idea is to use a simplified set of hadronic calorimeters, with different beam particle types, and various beam energies, and comparing relevant observables between a given reference version of Geant4 and the new candidate one. Only those distributions that are statistically incompatible are then printed out and finally inspected by a person to look for possible bugs. The suite is made of Python scripts, and utilizes the "Statistical Toolkit" for the statistical tests between pair of distributions, and runs on the Grid to cope with the large amount of CPU needed in a short period of time. In fact, the total CPU time required for each of these Geant4 release validation productions amounts to about 4 CPU-years, which have to be concentrated in a couple of weeks. Therefore, the Grid environment is the natural candidate to perform this validation production. We have already run three of them, starting in December 2004. In the last production, in December 2005, we run as Geant4 VO, for the first time, demonstrating the full involvement of Geant4 inside the EGEE communities. Several EGEE sites have provided us with the needed CPU, and this has guaranteed the success of the production, arriving to an overall efficiency rate of about 99%. In the talk, emphasis will be given on our experiences in using the Grid, the results we got from it and possible future improvements. Technical aspects of the Grid framework that have been deployed for the production will only be mentioned; for more details see the talks of P.Mendez and J.Moscicki.
        Speaker: Dr Alberto Ribon (CERN)
        Slides
      • 5:30 PM
        The ATLAS Rome Production Experience on the LHC Computing Grid 30m
        The Large Hadron Collider at CERN will start data acquisition in 2007. The ATLAS (A Toroidal LHC ApparatuS) experiment is preparing for the data handling and analysis via a series of Data Challenges and production exercises to validate its computing model and to provide useful samples of data for detector and physics studies. The last Data Challenge, begun in June 2004 and ended in early 2005, was the first performed completely in a Grid environment. Immediately afterwards, a new production activity was necessary in order to provide the event samples for the ATLAS physics workshop, taking place in June 2005 in Rome. This exercise offered a unique opportunity to estimate the reached improvements and to continue the validation of the computing model. In this contribution we discuss the experience of the “Rome production” on the LHC Computing Grid infrastructure, describing the achievements, the improvements with respect to the previous Data Challenge and the problems observed, together with the lessons learned and future plans.
        Speaker: Dr Simone Campana (CERN/IT/PSS)
        Slides
      • 6:00 PM
        CRAB: a tool for CMS distributed analysis in grid environment. 30m
        The CMS experiment will produce a large amount of data (few PBytes each year) that will be distributed and stored in many computing centres spread in the countries participating to the CMS collaboration and made available for analysis to world-wide distributed physicists. CMS will use a distributed architecture based on grid infrastructure to analyze data stored at remote sites, to assure data access only to authorized users and to ensure remote resources availability. Data analisys in a distributed environment is a complex computing task, that assume to know which data are available, where data are stored and how to access them. The CMS collaboration is developing a user friendly tool, CRAB (Cms Remote Analysis Builder), whose aim is to simplify the work of final users to create and to submit analysis jobs into the grid environment. Its purpose is to allow generic users, without specific knowledge of grid infrastructure, to access and analyze remote data as easily as in a local environment, hiding the complexity of distributed computational services. Users have to develop their analisys code in an interactive environment and decide which data to analyze, providing to CRAB data parameters (keywords to select data and total number of events) and how to manage produced output (return file to UI or store into remote storage). CRAB creates a wrapper of the analisys executable which will be run on remote resources, including CMS environment setup and output management. CRAB splits the analisys into a number of jobs according to user provided information about number of events. The job submission is done using grid workload management command. The user executable is sent to remote resource via inputsandbox, together with the job. Data discovery, resources availability, status monitoring and output retrieval of submitted jobs are fully handled by CRAB. The tool is written in python and have to be installed to the User Interface, the user access point to the grid. Up to now CRAB is installed in ~45 UI and about ~210 different kind of data are available in ~40 remote sites. The weekly rate of submitted jobs is ~10000 with a success rate about 75%, that means jobs arrive to remote sites and produce outputs, while the remnant 25% aborts due to site setup problem or grid services failure. In this report we will explain how CRAB is interfaced with other CMS/grid services and will report the daily user's experience with this tool analyzing simulated data needed to prepare the Physics Technical Design Report.
        Speaker: Federica Fanzago (INFN-PADOVA)
        Slides
    • 12:30 PM 2:00 PM
      Lunch 1h 30m
    • 1:00 PM 2:00 PM
      Lunch 1h