BEGIN:VCALENDAR VERSION:2.0 PRODID:-//CERN//INDICO//EN BEGIN:VEVENT SUMMARY:Discussion DTSTART;VALUE=DATE-TIME:20060302T170000Z DTEND;VALUE=DATE-TIME:20060302T171500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-133@cern.ch DESCRIPTION:Speakers: \nhttp://indico.cern.ch/contributionDisplay.py?contr ibId=133&sessionId=17&confId=286 LOCATION:CERN 40-S2-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=133&sessionId=1 7&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Use of Oracle software in the CERN Grid DTSTART;VALUE=DATE-TIME:20060302T140000Z DTEND;VALUE=DATE-TIME:20060302T142000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-132@cern.ch DESCRIPTION:Speakers: ENGSIG\, Bjorn (ORACLE)\nOracle is known as a databa se vendor\, but has much more to offer than data storage \nsolutions. \nS ome key Oracle products that are in use or are being currently full-scale tested \nat CERN will be discussed in this talk.\nIt will primarily be an open discussion and interactive feedback from the audience \nis more than welcome\n\nThe following topics will be discussed:\n\nOracle Client Softwa re distribution \n\nHow can a large to huge number of systems be given ea sy possibility to connect to \nOracle database servers\; what are the dist ribution rights and how is it actually \ndistributed and configured.\n\nOr acle Support for Linux\n\nOracle officially supports those Linux distribut ions that are in widespread use and \nstrongly recommends that servers are being run on supported distributions. This \ndoes however not imply\, th at other Linux distributions cannot at all be used. This \ntalk will elab orate on this.\n\nOracle Streams Replication\n\nThe various possibilities for using Oracle Streams to replication large amounts of \ndata will be di scussed.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=132&ses sionId=13&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=132&sessionId=1 3&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Benefits of the MAGIC Grid DTSTART;VALUE=DATE-TIME:20060301T130000Z DTEND;VALUE=DATE-TIME:20060301T133000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-41@cern.ch DESCRIPTION:Speakers: Dr. KORNMAYER\, Harald (FORSCHUNGSZENTRUM KARLSRUHE (FZK))\nApplication context and scientific goals \n======================= =================\n\nThe field of gamma-ray observations in the energy ran ge between 10 GeV\nand 10 TeV developed fast over the last decade. \nFrom the first observation of TeV gamma rays from the Crab nebula using the \na tmospheric Cerenkov imaging technique in 1989 [1] to the \ndiscovery of ne w gamma ray sources with the new generation telescopes \nlike the HESS obs ervation of a high-energy particle acceleration \nin the shell of a supern ova remnant [2]\, a\nnew observation window to the universe was opened. \n In the future other ground based VHE $\\gamma$-ray observatories \n(namely MAGIC [3]\, VERITAS [4] \nand KANGAROO [5]) will significantly \ncontribu te to the exploitation of this new observation window. \nWith the new gene ration Cerenkov telescopes the requirements for the \nanalysis and Monte C arlo production computing infrastructure \nwill increase due to a higher n umber of camera pixels\, \nfaster FADC systems and a bigger mirror size. \ nIn the future the impact of VHE gamma-ray astronomy\nwill increase by joi ned observations of different Cerenkov telescopes. \n\nIn 2003 the nationa l Grid centers in Italy (CNAF)\, Spain (PIC) and Germany (GridKA) \nstarte d together with the MAGIC collaboration an effort to build a \ndistributed computing system for Monte Carlo generation and analysis on top of existi ng \nGrid infrastructure. \nThe MAGIC telescope was chosen due to the foll owing reasons: \no The MAGIC collaboration is international\, with most pa rtners from Europe\no main partners of the MAGIC telescope are located clo se to the national Grid centers \no The generation of Monte Carlo data is very compute intensive\, specially to get\nenough statistics \nin the low energy range. \no The analysis of the fast increasing real data samples w ill be done in different \ninstitutes. The collaborators need a seamless a ccess to the data while reducing the\nnumber of \nreplicas to a minimum. \ no The MAGIC collaboration will build a second telescope in 2007 resulting in a\ndoubled data rate. \n\nThe idea of the MAGIC Grid [6] was presente d to the EGEE Generic \nApplication Advisory Panel (EGAAP). \nIn June 2004 EGEE accepted the generation of Monte Carlo data for the MAGIC \ntelescop e as one of the generic applications of the project.\n\nGrid added value \ n================\n\nBy implementing the MAGIC Grid over the last two year s\, the MAGIC collaboration\nbenefit in many aspects. These aspects are de scribed in this chapter. \n\no Collaboration of different institutes\nBy c ombining the resources of the MAGIC collaborators and the reliable\nresour ces from the national Grid centers the MAGIC collaborators \nwill be empow ered to use their computing infrastructure more efficiently. \nThe time to analyse the big amount of data to solve \nspecific scientific problems wi ll be shortend. \n\no Cost reduction\nBy using the EGEE infrastructure and the EGEE services the effort for \nMAGIC collaboration to build a distrib uted computing system for \nthe Monte Carlo simulations was significantly reduced.\n \no Speedup of Monte Carlo production \nAs the MAGIC Monte Car lo System was build on top of the EGEE middleware\nthe integration of new computing resources is very easy. By getting \nsupport from many different EGEE resource providers the production \nrate for the Monte Carlos can be increased very easily. \n \no Persistent storage of observation data \n The MAGIC telescope will produce a lot of data in the future. These\ndata are currently stored on local resources including disk systems\nand tape l ibraries. The MAGIC collaboration recognized that this\neffort is not negl igible especially concerning man power. Therefore \nthe observation data w ill be stored by the spanish Grid center PIC. \n \no Data availability imp rovements \nBy importing the observation data to the Grid\, the MAGIC\ncol laboration expect that the availablitly of data will be \nincreased with t he help of Grid data management methods like\ndata replication\, etc. As t he main data services will be provided\nin the future by the national Grid centers instead of research university\ngroups at universities\, the ove rall data availablitly is \nexpected to increase. \no Cost reduction\nBy using the EGEE infrastructure and the EGEE services the effort for \nMAGIC collaboration to build a distributed computing system for \nthe Monte Car lo simulations was significantly reduced.\n\nExperiences with the EGEE inf rastructure\n========================================\n\nThe experiences o f the developers during the different phases of the \nrealisation of the M AGIC Monte Carlo production system on the EGEE \nGrid infrastructure are d escribed in this chapter. As the MAGIC virtual \norganisation was accepted as one of the first generic EGEE application\, \nthe development process was influenced by general developments within the EGEE \nproject too like changed in the middleware versions\, etc. \n\no Prototype implementation\n --------------------------\nThe migration of the compute intensive MMCS pr ogram from a local batch \nsystem to the Grid was done by the definition o f a template JDL form. \nThis template sends all needed input data togethe r with the executable \nto the Grid. The resources are chosen by the resou rce broker. \nThe automatic registration of the output file as a logical f ile on the\nGrid was not very reliable at the beginning\, but improved to production \nlevel within the EGEE project duration. \n\no Production MAGI C Grid system\n------------------------------\nThe submission of many prod uction system needed the implementation of a \ngraphical user interface an d a database for metadata. The graphical \nuser interface was realised wit h the JAVA programming language. The\nexecution of the LCG/gLite commands is wrapped in JAVA shell commands. \nA MySQL database holds the schema for the metadata. \nAs mentioned above the "copy and register" process for th e output file was\nnot realiable enough an additional job status "DONE (da ta available)" was \ninvented. With the help of the database\, jobs that d id not reach this\njob status within two days are resubmitted. The job dat a are keeped in \na seperate database table to analyse them later. \n\no R eliability of EGEE services\n------------------------------\nThe general s ervices like resource brokers\, VO management tools and Grid\nuser support was provided by the EGEE resources providers. The MAGIC Grid\nis setup on top of this services. A short report of the experiences with\nthis produc tion services will be given. \n\n\nKey issues for the future of Grid techn ology\n============================================\nThe MAGIC collaborati on is currently evaluating the EGEE Grid infrastructure\nas the backbone f or a distributed computing system in the future including \nthe data stora ge on Grid data centers like PIC. Furthermore the discussion \nwith other projects like the HESS collaboration has started\nto move towards "Virtual Very High energetic Gamma ray observatory" [7]. \nThe problems and challe nges that needs to be solved on the track to a sustainable\nGrid infrastru cture will be discussed from the user perspective \n\nReferences:\n\n[1] T . Weekes et al.\, The Astrophysical Journal\, volume 342 (1989)\, p. 379\n [2] F. A. Aharonian et al.\, Nature 432\, 75 - 77 (04 November 2004)\n[3] E. Lorenz\, 1995\, Fruehsjahrtagung Deutsche Physikalische Gesellschaft\, March 9-10\n[4] T. Weekes et al.\, Astropart. Phys.\, 17\, 221-243 (2002)\ n[5] Enomoto\, R. et al.\, Astropart. Phys. 16\, 235-244 (2002)\n[6] H. Ko rnmayer et al.\, "A distributed\, Grid-based analysis system for the MAGIC \ntelescope"\, \nProceedings of the CHEP Conference \, Interlaken\, Switz erland\, 2004\n[7] H. Kornmayer et al.\, "Towards a virtual observatory fo r high energetic gamma\nrays"\, Cherenkov 2005\, \nParis\, 2005\n\nhttp:// indico.cern.ch/contributionDisplay.py?contribId=41&sessionId=10&confId=286 LOCATION:CERN 40-5-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=41&sessionId=10 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Construction of a Mathematical Model of a Cell as a Challenge for Science in the 21 Century and EGEE project DTSTART;VALUE=DATE-TIME:20060301T164500Z DTEND;VALUE=DATE-TIME:20060301T170000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-24@cern.ch DESCRIPTION:Speakers: Prof. LAKHNO\, Victor (IMPB RAS\, Russia)\nAs recent ly as a few years ago a possibility of constructing a mathematical model o f \na life seemed absolutely fantastic. However\, at the beginning of 21-t h century \nseveral research teams announced creation of a minimum model o f life. To be more \nspecific\, not life in general\, but an elementary br ick of life\, that is a living \ncell. The most well-known of them are: US A Virtual Cell Project (V-Cell)\, NIH \n(http: //www. nrcam.uchc.edu /vcel lR3 /login/login.jsp)\; Japanese E-cell project \n(http://ecell. sourcefor ge.net/)\; Dutch project ViC (Virtual Cell) \n(http://www.bio.vu.nl /hwcon f/Silicon /index.html). \nThe above projects deal mainly with kinetics of cell processes. New approaches to \nmodeling imply development of imitatio n models to simulate functioning of cell \nmechanisms and devising of soft ware to simulate a complex of interrelated and \ninterdependent processes (such as gene networks). With the emergence of an \nopportunity to use GRI D infrastructure for solving such problems new and bright \nprospects have opened up.\nTo develop an integrated model of more complex object than pr okaryotic cell such as \neukaryotic cell is the aim of the Mathematical Ce ll project \n(http://www.mathcell.ru) realized at the Joint Center for Co mputational Biology and \nBioinformatics (www.jcbi.ru) of the IMPB RAS. Fu nctioning of a cell is simulated \nbased on the belief that the cell life is mainly determined by the processes of \ncharge transfer in all its cons tituent elements.\nSince (like in physics where the universe is thought to have arisen as a result of a \nBig Bang) life originated from a DNA molec ule\, modeling should be started from the \nDNA. The MathCell model reposi tory includes software to calculate charge transfer in \nan arbitrary nucl eotide sequence of a DNA molecule. A sequence to be analyzed may be \nspec ified by a user or taken from databanks presented at the site of the Joint \nCenter for Computational Biology and Bioinformatics (http://www.jcbi.ru ).\n\nPresently\, the MathCell site demonstrates a simplest model of charg e transfer. In \nthe framework of the GRID EGEE project any user registere d and certified in EGEE \ninfrastructure can use both the program and the computational resources offered by \nEGEE.\nIn the near future IMPB RAS is planning to deploy in EGEE a software tool to \ncalculate a charge transf er on inner membranes of some compartments of eukaryotic \ncells (mitochon dria and chloroplasts) through direct simulation of charge transfer \nwith regard to the detailed structure of biomembranes containing various molec ular \ncomplexes. Next on the agenda is a software tool to calculate metab olic reaction \npathways in compartments of a cell as well as the dynamics of gene networks.\nFurther development of the MathCell project implies in tegration of individual \ncomponents of the model into an integrated progr am system which would enable \nmodeling of cell processes at all levels – from microscopic to macroscopic scales \nand from picoseconds to the s cales comparable with the cell lifetime. Such modeling \nwill naturally re quire combining of computational and commutation resources provided \nby E GEE project and their merging into an integrated computational medium.\n\n http://indico.cern.ch/contributionDisplay.py?contribId=24&sessionId=9&conf Id=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=24&sessionId=9& confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:The AMGA Metadata Service DTSTART;VALUE=DATE-TIME:20060302T134000Z DTEND;VALUE=DATE-TIME:20060302T140000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-25@cern.ch DESCRIPTION:Speakers: Dr. KOBLITZ\, Birger (CERN-IT)\nWe present the ARDA Metadata Grid Application (AMGA) which is part of\nthe gLite middleware. A MGA provides a lightweight service to manage\, store\nand retrieve simple relational data on the grid\, termed metadata.\n\nIn this presentation we will first give an overview of AMGA's design\,\nfunctionality\, implementa tion and security features. AMGA was designed\nin close collaborations wit h the different EGEE user communities and\ncombines high performance\, whi ch was very important to the high energy\nphysics community\, with fine-gr ained access restrictions required in\nparticular by the BioMedical commun ity. These access restrictions also\nmake full use of the EGEE VOMS servic es and are based on grid\ncertificates. To show to what extent the users' requirements have been\nmet\, we will present performance measurements as well as show\nuses-cases for the security features.\n\nSeveral application s are currently using AMGA to store their\nmetadata. Among them are the MD M (Medical Data Manager) application\nimplemented by the BioMedical commun ity\, the GANGA physics analysis\ntool from the Atlas and LHCb experimens and a Digital Library from the\ngeneric applications.\n\nThe MDM applicati on uses AMGA to store relational information on\nmedical images stored on the grid plus information on patients and\ndoctors in several tables. User applications can retrieve images baded\nno their metadata for further pro cessing. Access restrictions are of\nthe highest importance to the MDM app lication because the stored data\nis highly confidential. MDM therefore ma kes use of the fine-grained\naccess restrictions of AMGA.\n\nThe GANGA app lication uses AMGA to store the status information of\njobs running on the grid which can be controlled by GANGA. AMGA's\nsimple relational database features are mainly used to ensure\nconsistency when several GANGA client s of the same user are accessing\nthe stored information remotely.\n\nFina lly\, the Digital Library project makes similar use of AMGA as the\nMDM ap plication but provides many different schemas to store not only\nimages bu t information on texts\, movies or music. Another difference\nis that ther e is only a central librarian updating the library while\nfor MDM updates are triggered by the many image acquisition systems\nthemselves.\n\nThis p resenation will also discuss future developments of AMGA\, in\nparticular its features to replicate or federate metadata. They will\nmainly allow us ers to make use of a better scaling behaviour but could\nalso allow better security by using federation to physically seperate\nmetadata. The replic ation features will be compared to current\nproprietary solutions.\n\n AMG A provides a very lightweight metadata service\nas well as basic database access functionality on the Grid.\nAfter a brief overview of AMGA's design \, functionality\, implementation \nand security features we will show per formance comparisons of AMGA with \ndirect database access as well as othe r Grid catalogue services. Finally\nthe replication features of AMGA are p resented and a comparison done\nwith proprietary database replication solu tions.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=25&sessio nId=13&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=25&sessionId=13 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Requirements of Climate applications on Grid infrastructures\; C3- Grid and EGEE DTSTART;VALUE=DATE-TIME:20060301T164500Z DTEND;VALUE=DATE-TIME:20060301T170000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-26@cern.ch DESCRIPTION:Speakers: Dr. BIERCAMP\, Joachim (DKRZ)\nHuman made climate ch ange and its impact on the natural and socio-economic\nenvironment is one of todays most challenging problems of mankind. To understand and\nproject processes\, changes and impacts of the natural and socio-economic system a\ngrowing community of researchers from various disciplines investigates and analyses\nthe earthsystem by means of computer simulation and analysis models.\nThese models are usually computational demanding and data intens ive as they need to\ncompute and store high resolved 4-dimensional fields of various parameters. Moreover\,\nthe required close collaboration in int erdisciplinary and often also international\nresearch projects involves in tensive community interactions.\nTo support climate workflows the communit y established proprietary\, mostly national\nor regional solutions\, which are normally grouped around centralized high performance\ncomputing and s torage resources. Homogeneous discovery of and access to climate data\nset s residing in distributed petabyte climate archives as well as distributed \nprocessing and efficient exchange of climate data are the central compon ents of\nfuture international climate research. Thus\, the EGEE infrastruc ture potentially\noffers a highly suitable environment for such applicatio ns.\n\nHowever\, existing grid infrastructures - including EGEE - do not y et meet the\nrequirements of the climate community essential for prevalent workflows. Hence\, to\nport existing applications and workflows on the EG EE infrastructure\, a stepwise\nextension of the infrastructure to communi ty specific services is needed. Moreover\,\nthe identification and demonst ration of feasibility and added value is essential to\nconvince the commun ity to change their established habits. The Collaborative Climate\nCommuni ty Data and Processsing Grid (C3-Grid [1]) is an application driven approa ch\ntowards the deployment of GRID techniques for climate data analysis. S olutions\ncurrently developed in this project offer a potentially fruitful basis to improve the\nsuitability of the EGEE infrastructure as a platfor m for data analysis within climate\nresearch.\n\nWithin EGEE climate is pa rt of the Earth Science Research (ESR) VO. We evaluated and\ntested the us e of the EGEE infrastructure for climate applications [4]. As part of\nthi s prototypes of simulation as well as analysis software were tested on the EGEE\ninfrastructure. We identified 3 different accesspoints for pilot ap plications\, that\ncan demonstrate the potential benefit of the EGEE infra structure for climate\nresearch: Ensemble simulations with models of inter mediate complexity\, coupling\nexperiments on a common platform and data s haring and analysis.\n\nEnsembles of simulations performed with the same m odel but different future scenarios\nand different parameterisations are r equired to quantify the uncertainty and possible\nvariety of future climat e predictions. EGEE offers a good infrastructure for such\nensemble simula tions with models of intermediate complexity\, which do not need the\nperf ormance of a supercomputer. Ensembles can be submitted as DAG\, parametric or\ncollection job and results could be directly stored\, analysed and re duced to the\nrequired information on the grid.\n\nThe coupling of diverse models of different disciplines is essential to understand\nthe interacti on and feedback between the different climate and earth system\ncomponents \, as e.g. the human impact on future climate development. In correspondin g\nprojects partners from different institutes of different nations are co llaborating on\na common modeling framework. The EGEE infrastructure would be a valuable platform for\nsuch coupling approaches. Data\, models and o utput could be easily shared\, different\naccess and user rights can be es tablished via VOMS. Currently different coupling\ntools are explored to as sess their "grid-suitability".\n\nData sharing and analysis is a central a spect in climate research. The enormous\namounts of data\, produced by the model simulations need to be analysed\, visualised\nand validated against observations or other data sources to be correctly interpreted.\nThis inv olves a multiplicity of statistical calculations carried out on samples of \ndifferent large data files. Currently such data analysis is centred arou nd the\nheterogeneous database systems\, which are accessed via non-standa rdised metadata.\nThus\, the establishment of a common data exchange and m anagement infrastructure\nbridging the existing heterogeneous community da tamanagement solutions with the EGEE\ndata management system would add gre at value to such applications. \n\n\nEspecially for the realisation of cli mate data sharing and analysis workflows on EGEE\nthe following components need to be developed:\n\n1) a common agreed upon metadata schema for disc overy of climate data sets stored in\ngrid file space as well as in extern al community datacenters\n2) a common community metadata catalogue based o n this schema\n3) common interfaces to reference and access grid external data resources (mainly\ndatabases)\n\n\nAll of these aspects are addressed within the recently introduced national German\nC3Grid [1] project within the German e-science (D-Grid [2]) initiative which aims to\ndevelop a gri d middleware specific for the needs of the climate research community.\nWi thin this project a common metadata schema is defined. A community metadat a\ncatalogue and information system is established and a common data acces s interface\nwill be defined.\n\nTo promote EGEE as a climate data handlin g (and postprocessing) infrastructure based\non these developments we prop ose a stepwise approach: \n\n- establishment of an international standards based climate metadata catalog (e.g.\nbased on AMGA plus a common push/pu ll metadata exchange to grid external metadata\ncatalogues via established metadata harvesting protocols\n- establishment of data access to (initial ly free) climate datasets in climate data\ncenters: As intial starting poi nt we need an easy way to access data in climate data\ncenters and copy/re gister them on grid storage\,\n e.g. by using proprietary access clients o r OGSA-DAI. \n- adaptation of commonly used climate data processing toolki ts on EGEE such as e.g.\ncdo [3] \n\n\n[1] http://www.c3grid.de \n[2] http ://www.d-grid.de\n[3] http://www.mpimet.mpg.de/~cdo/\n[4] Stephan Kinderma nn\, EGEE infrastructure and Grids for Earth Sciences and Climate\nResearc h\, Technical report DKRZ (available under\nhttp://c3grid.dkrz.de/moin.cg i/PublicDocs)\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=26 &sessionId=11&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=26&sessionId=11 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Demonstration of the P-GRADE portal DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-27@cern.ch DESCRIPTION:Speakers: Prof. KACSUK\, Peter (MTA SZTAKI)\nThe P-GRADE porta l plays more and more important role in the EGEE community. After \nits su ccessful demos in the previous EGEE conferences (Athens and Pisa) the \nre presentatives of several EGEE VOs have approached us with the request to s upport \ntheir users by the P-GRADE portal that is already the official po rtal of two EGEE \nVOs: VOCE (Virtual Organization Central Europe) and Hun Grid (Hungarian VO of EGEE). \nBesides\, P-GRADE portal is the official po rtal of SEEGRID which is a 100% EGEE-\nbased Grid infrastructure serving a ll the countries of the South-East European \nregion (even those countries that were not members of EGEE-1). After the Pisa demo \nthe EGRID VO esta blished a P-GRADE portal to support their activity and the biomed \ncommun ity showed interest to connect the portal to their workflow management \ne ngine. Besides the EGEE community\, the portal is successfully used as ser vice for \nthe UK National Grid Service (NGS) and it was also successfully connected to the \nGridLab testbed as well as to the Hungarian ClusterGri d. After its successful \ndemonstration at the Supercomputing’05 exhibit ion representatives of the US Open \nScience Grid also expressed their int erest to connect the portal to their Grid.\n\nWhy is P-GRADE portal so suc cessful? The main reason is that it is a generic \nworkflow-oriented porta l that can support all the important features the typical \nend-users woul d like to have:\n\n1. Hidden low-level Grid details but at the same time e nabling the access of any \nimportant feature of the underlying Grid\n2. E asy porting of the applications to the Grid\n3. User-friendly\, graphical environment to control and observe the execution of the \nGrid application \n4. Enabling the usage of MPI programs in the Grid\n5. Enabling the usage of legacy codes in the Grid\n6. Developing and executing workflow applica tions in the Grid\n7. Combining MPI and legacy programs in workflows \n8. Developing and executing parametric study applications (both at job and wo rkflow \nlevel) in the Grid\n9. Providing parallel execution mechanisms fo r the workflows at various levels\n a. intra-job\n b. inter-jo b\n c. pipe-line\n d. multi-thread\n10. Supporting multi-Grid access mechanism and inter-Grid parallelism \n11. Providing a secure and r obust Grid application development and execution \nservice for end-users ( including certificate management\, quota management and \nresource managem ent)\n12. Providing user-centric error messages and workflow recovery mech anism in case \nof erroneous job and workflow execution.\n13. Providing au tonomous error correction facilities\n14. Supporting collaborative workflo w development and execution\n15. Tailoring the portal to specific user nee ds\n\nThe current version of P-GRADE portal (version 2.3) can provide feat ures 1-4\, 6\, \n9/a\, 9/b\,10-12\, 15. The UK NGS extension of the portal can provide features 5 and \n7. Feature 14 is already prototyped and demo nstrated at the Supercomputing’05 \nexhibition. This feature will be ava ilable as service by November 2006. Features 8\, \n9/c and 9/d are under d evelopment as a joint work with the bioscience EGEE \ncommunity and will b e available in version 3.0 by April 2006. Version 3.0 will also \nsupport feature 13.\n\nP-GRADE portal is based on the JSR168 compliant GridSphere 2 framework and hence it \nsupports the easy extension and tailoring of th e portal according to specific user \nneeds. There are two examples for su ch extension of the portal. For the UK NGS\, \nUniversity of Westminster d eveloped and added a new portlet that supports the \ndefinition and invoca tion of legacy code services. For the EGRID community\, \nresearchers of t he Abdus Salam International Centre for Theoretical Physics have \ndevelop ed and now add a new portlet that enables file transfer among Grid \ncompu tational and storage resources. In fact the further development of the por tal \nis going on as a joint activity of several universities and institut es in Europe. \nBesides the above mentioned two collaborating partners\, U niv. of Reading \ncontributes to the creation of the collaborative version of the portal while CNRS \ncollaborates with SZTAKI in creating the param etric study version of the portal. \nThe Boskovic research institute in Za grab developes specific application oriented \nportlets. \n\nThe goal of t he demonstration of the P-GRADE portal is to demonstrate the features \nme ntioned above. We shall use four portal installations during the demonstra tion. \nThe VOCE portal (version 2.3) that runs as a service for VOCE will be used to \ndemonstrate the robustness and scalability of the P-GRADE po rtal as a VO service. \nThis demo tries to convince the audience that the current version of P-GRADE portal \nis robust and scalable and hence it ca n be used for any VO of EGEE as a stable \nservice for end-users. This por tal will be used to demonstrate features 1-4\, 6\, \n9/a\, 9/b\,10-12.\n\n The UK NGS portal (version 2.2) that runs as a service for UK NGS will be used to \ndemonstrate how the portal can be extended with legacy code serv ices as well as \nwith application-specific portlets. Moreover we shall de monstrate the multi-Grid \naccess mechanism of the portal showing that bot h the UK NGS and the HunGrid (EGEE) \nsites can be accessed by the same po rtal within a workflow in a simultaneous way \nrealizing Grid interoperabi lity and multi-Grid parallelism. This portal will be \nused to demonstrate features 5\, 7\, 10. Two experimental portals (prototypes) will \nalso be demonstrated to show the future features of the portal (features 8\, 9/c\ , \n9/d and 14).\n\nWe hope that by continuing the successful series of po rtal demonstrations more and \nmore EGEE user community will recognize the obvious advantages of using the portal \ninstead of the low-level command -line user interface. The mass usage of Grid \ntechnology cannot be achiev ed by low-level commands\, only high-level\, graphical \nuser interfaces c an attract and convince the end-users that Grid is usable for \nthem. P-GR ADE portal is a step towards this direction.\n\nhttp://indico.cern.ch/cont ributionDisplay.py?contribId=27&sessionId=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=27&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:The EGEE infrastructure DTSTART;VALUE=DATE-TIME:20060302T080000Z DTEND;VALUE=DATE-TIME:20060302T093000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-20@cern.ch DESCRIPTION:Speakers: BIRD\, Ian (CERN)\n \n\nhttp://indico.cern.ch/contr ibutionDisplay.py?contribId=20&sessionId=18&confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=20&sessionId=18 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:gLite status and plans DTSTART;VALUE=DATE-TIME:20060302T100000Z DTEND;VALUE=DATE-TIME:20060302T113000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-21@cern.ch DESCRIPTION:Speakers: GRANDI\, Claudio (INFN Bologna)\nhttp://indico.cern. ch/contributionDisplay.py?contribId=21&sessionId=18&confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=21&sessionId=18 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:HGSM Web Application DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-22@cern.ch DESCRIPTION:Speakers: Mr. HOXHA\, Dashamir (Institute of Informatics and A pplied Informatics (INIMA)\, Tirana\, Albania)\nThis is a web application that serves as a front-end to the database\nthat keeps information about t he grid sites (clusters)\, their admins\,\nemail and phone contacts\, othe r contact people\, site nodes and\nresources\, downtimes etc. These sites are organized by country and\ncountries are organized by regions. The admi ns of each site can also\nupdate the information about the site.\n\nhttp:/ /indico.cern.ch/contributionDisplay.py?contribId=22&sessionId=22&confId=28 6 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=22&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Project gridification: the UNOSAT experience DTSTART;VALUE=DATE-TIME:20060301T140000Z DTEND;VALUE=DATE-TIME:20060301T141500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-23@cern.ch DESCRIPTION:Speakers: Dr. MENDEZ LORENZO\, Patricia (CERN IT/PSS)\nThe EGE E infrastructure is a key part of the computing environment for the \nsimu lation\, processing and analysis of the data of the Large Hadron Collider (LHC) \nexperiments (ALICE\, ATLAS\, CMS and LHCb). The example of the LHC experiments \nillustrates well the motivation behind Grid technology. The LHC accelerator will \nstart operation in 2007\, and the total data volum e per experiment is estimated to \nbe \na few PB/year at the beginning of the machine’s operations\, leading to a total \nyearly production of sev eral hundred PB for all four experiments around 2012. The \nprocessing of this data will require large computational\, storage and associated \nhuma n resources for operation and support. It was not considered feasible to f und \nall of the resources at one site\, and so it was agreed that the LCG computing \nservice would be implemented as a geographically distributed Computational Data \nGrid. This means\, the service will use computational and storage resources\, \ninstalled at a large number of computing sites in many different countries\, \ninterconnected by fast networks. At the mo ment\, the EGEE infrastructure counts 160 \nsites\, distributed over more than 30 countries. These sites hold 15000 CPUs and \nabout 9PB of storage capability. \nThe Grid middleware will hide much of the complexity of this environment from the \nuser\, organizing all the resources in a coherent virtual computer centre. \nThe computational and storage capability of the Grid is attracting other research \ncommunities and we would like to disc uss the general patterns observed in \nsupporting \nnew applications\, por ting their application onto the EGEE infrastructure. \nIn this talk we pre sent our experiences in the porting of three different \napplications insi de the Grid like Geant4\, UNOSAT and others. \nGeant4 is a toolkit for the Monte Carlo simulation of the interaction of particles \nwith matter. It is applied to a wide field of research including high energy \nphysics \na nd nuclear experiments\, medical\, accelerator and space physics studies. ATLAS\, \nCMS\, \nLHCb\, Babar\, and HARP are actively using Geant4 in pro duction. \nUNOSAT is a United Nations initiative to provide the humanitari an community with \naccess to satellite imaginary and Geographic System se rvices. UNOSAT is implemented \nby the UN Institute for Training and Resea rch (UNITAR) and manager by the UN Office \nfor Project Services (UNOPS). In addition\, partners from public and private \norganizations constitute the UNOSAT consortium. Among these partners\, CERN \nparticipates actively providing the computational and storage resources needed for \ntheir imag es analysis. \nDuring the gridification of the UNOSAT project\, the collab oration with the \ndevelopers of the ARDA group to adapt the AMGA software to the UNOSAT expectations \nwas extremely important. The satellite image s provided by UNOSAT have been stored \nin \nStorage Systems at CERN and r egistered inside the LCG Catalog (LFC). The files so \nregistered have bee n identified with an easy to remember Logical File Name (LFN). \nThe LFC C atalog is then able to map these LFN to the physical location of the \nfil es. \nDue to the UNOSAT infrastructure\, their users will provide as input information the \ncoordinates of each image. AMGA is able to map these co ordinates (considered \nmetadata information) to the corresponding LFN of the files registered inside the \nGrid. Then the LFC will find the physica l location of the images. \nA successful model to guarantee a smooth and efficient entrance in the Grid \nenvironment is to identify an expert supp ort to work with the new community. This \nperson will assist them during the implementation and execution of their \napplications inside the Grid. He will also be the Virtual Organization (VO) contact \nperson with the EG EE sites. This person will work together with the EGEE deployment \nteam a nd with the responsible of the sites to set the services needed by the \ne xperiment or community\, observing also the relevant security and access policies. \nOnce these new communities attain a good level of maturity and confidence\, a VO \nManager would be identified in the users community. \ nThis talk will report a number of concrete examples and it will try to su mmarize \nthe \nmain lessons. We believe that this should be extremely int eresting for new \ncommunities in order to early identify possible problem s and prepare the \nappropriate \nsolutions. In addition\, this support sc heme would also be very interesting as a \nmodel\, for example\, for local application support in EGEE II.\n\nhttp://indico.cern.ch/contributionDisp lay.py?contribId=23&sessionId=11&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=23&sessionId=11 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Application of the Grid to Pharmacokinetic Modelling of Contrast A gents in Abdominal Imaging DTSTART;VALUE=DATE-TIME:20060301T163000Z DTEND;VALUE=DATE-TIME:20060301T164500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-28@cern.ch DESCRIPTION:Speakers: Dr. BLANQUER\, Ignacio (Universidad Politécnica de Valencia)\nThe liver is the largest organ of the abdomen and there are a l arge number of lesions\naffecting it. Both benign and malignant tumours ar ise within it. The liver is also\nthe target organ for most solid tumours metastasis. Angiogenesis is quite an\nimportant marker of tumour aggressiv eness and response to therapy. The blood supply\nto the liver is derived j ointly from the hepatic arteries and the portal venous\nsystem. Dynamic Co ntrast Enhanced Magnetic Resonance Imaging (DCE-MRI) is extensively\nused for the detection of primary and metastatic hepatic tumours. However\, the \nassessment of early stages of the malignancy and other diseases like cir rhosis\nrequire the quantitative evaluation of the hepatic arterial supply . To achieve this\ngoal\, it is important to develop precise pharmacokinet ic approaches to the analysis\nof the hepatic perfusion. The influence of breathing\, the large number of\npharmacokinetic parameters and the fast v ariations in contrast concentration in the\nfirst moments after contrast i njection reduce the efficiency of traditional\napproaches. On the other ha nd\, the traditional radiological analysis requires the\nacquisition of im ages covering the whole liver\, which greatly reduces the time\nresolution for the pharmacokinetic curves. The combination of all these adverse\nfac tors makes very challenging the analytical study of liver DCE-MRI data. \n The final objective of the work we present here is to provide the users wi th a tool\nto optimally select the parameters that describe the farmacokin etic model of the\nliver. This tool will use the Grid as a source of compu ting power and will offer a\nsimply and user-friendly interface.\nThe tool enables the execution of large sets of co-registration actions varying th e\nvalues of the different parameters\, easing the process of transferring the source\ndata and the results. Since Grid concept is mainly batch (and the co-registration is\nnot an interactive process due to its long durati on)\, it must provide with a simply\nway to monitor the status of the proc essing. Finally the process must be achieved in\nthe shorter time possible \, considering the resources available.\n\nhttp://indico.cern.ch/contribut ionDisplay.py?contribId=28&sessionId=9&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=28&sessionId=9& confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Scientific data audification within GRID: from Etna volcano seismo grams to text sonification DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-29@cern.ch DESCRIPTION:Speakers: VICINANZA\, Domenico (Univ. of Salerno + INFN Catani a)\nData audification is the representation of data by sound signals\; it can be considered as the acoustic \ncounterpart of data graphic visualizat ion\, a mathematical mapping of information from data sets to sounds.\nDat a audification is currently used in several fields\, for different purpose s: science and engineering\, education \nand training\, in most of the cas es to provide a quick and effective data analysis and interpretation tool. \nAlthough most data analysis techniques are exclusively visual in nature (i.e. are based on the possibility of \nlooking at graphical representati ons)\, data presentation and exploration systems could benefit greatly fro m \nthe addition of sonification capacities. In addition to that\, sonic r epresentations are particularly useful when \ndealing with complex\, hig h-dimensional data\, or in data monitoring tasks where it is practically i mpossible \nto use the visual inspection. More interesting and intriguing aspects of data sonification concern the \npossibility of describing patte rns or trends\, through sound\, which were hardly perceivable otherwise. T wo \nexamples\, in particular\, will be discussed in this paper\, the firs t one coming from the world of geophysics and \nthe second one from lingui stics.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=29&sessio nId=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=29&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Welcome DTSTART;VALUE=DATE-TIME:20060301T090000Z DTEND;VALUE=DATE-TIME:20060301T090500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-4@cern.ch DESCRIPTION:Speakers: HEMMER\, Frederic ()\nhttp://indico.cern.ch/contribu tionDisplay.py?contribId=4&sessionId=8&confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=4&sessionId=8&c onfId=286 END:VEVENT BEGIN:VEVENT SUMMARY:EUchinagrid DTSTART;VALUE=DATE-TIME:20060303T143500Z DTEND;VALUE=DATE-TIME:20060303T145500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-120@cern.ch DESCRIPTION:Speakers: \nhttp://indico.cern.ch/contributionDisplay.py?contr ibId=120&sessionId=21&confId=286 LOCATION:CERN Council Chamber URL:http://indico.cern.ch/contributionDisplay.py?contribId=120&sessionId=2 1&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Bioinfogrid DTSTART;VALUE=DATE-TIME:20060303T145500Z DTEND;VALUE=DATE-TIME:20060303T151500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-121@cern.ch DESCRIPTION:Speakers: \nhttp://indico.cern.ch/contributionDisplay.py?contr ibId=121&sessionId=21&confId=286 LOCATION:CERN Council Chamber URL:http://indico.cern.ch/contributionDisplay.py?contribId=121&sessionId=2 1&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Discussion on EGAAP future in EGEE-II DTSTART;VALUE=DATE-TIME:20060303T151500Z DTEND;VALUE=DATE-TIME:20060303T153000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-122@cern.ch DESCRIPTION:Speakers: \nhttp://indico.cern.ch/contributionDisplay.py?contr ibId=122&sessionId=21&confId=286 LOCATION:CERN Council Chamber URL:http://indico.cern.ch/contributionDisplay.py?contribId=122&sessionId=2 1&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Grid Computing and Online Games DTSTART;VALUE=DATE-TIME:20060302T153000Z DTEND;VALUE=DATE-TIME:20060302T160000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-59@cern.ch DESCRIPTION:Speakers: Mr. GARCIA LEIVA\, Rafael (Adago Ingenieria)\nWith t he fast growth of the video games and entertainment industry - thanks to t he\nappearance of new games\, new technologies and innovative hardware dev ices - the\ncapacity to react becomes critical for competing in the market of services and\nentertainment. Therefore it is necessary to be able to c ount on advanced middleware\nsolutions and technological platforms that al low a fast unfolding of custom made\nservices.\n\nAndago has developed the online games platform Andago Games that provides the\ntechnological base necessary for the creation of online Games services around which\nthe main entertainment sites will be able to establish solid business models. The\ nplatform Andago Games allows to quickly create online multiplayer games c hannels with\nthe following services for the final user: \n\n* Pay per Pla y/ pay per subscription\n* Reserving of gaming rooms or servers and advanc e management of games\n* Advanced statistics\n* Automatic game launch\n* C lans\n* Championships\, downloads\, chat\, etc.\n\nHowever\, the platform requires important investments by operators and portals\,\nlimiting the nu mber of possible customers. Grid computing will reduce dramatically\nthe a mount of these investments by means of sharing resources among different\n operators and portals. Also\, Grid computing offers the possibility to cre ate virtual\norganizations\, where operators and portals could share games and contents\, and even\ntheir user’s base. Technically\, the goal is t o be able to share expensive resources\nbetween providers and to allow bil ling based on usage. From a business perspective\nour goal is to open new commercial opportunities in the domain of entertainment.\n\nA common probl em with online games is that operators\, portals and games providers\nwoul d like to share resources and aim at sharing the costs to optimize their\n businesses. Yet business entities are generally required to play all busin ess roles.\nThe European market is still too fragmented and it is hard to reach the critical mass\nof users needed to make online games businesses p rofitable and to ensure resource\nliquidity. Having a Grid infrastructure makes it possible to divide tasks among\ndifferent actors and in consequen ce each actor could concentrate on the business it\nknows best. Applicatio n developers provide the applications\, portal providers create\nthe porta ls to attract users\, and Telcos/ISP will provide the infrastructure\nrequ ired. Such Virtual Organisations allow for profitable alliances and resour ce\nintegration. The outcome of a grid enabled online games platform will be to provide\nthe middleware to make this collaboration happen. The Grid ensures not only\ndecreasing costs for businesses\, but allows for creatin g a global European market as\napplications\, infrastructure and users can be shared independently of political and\nsocial borders\, smoothly integ rated and better exploited.\n\nThere are also big advantages for users. Fo r example\, they will have a larger offer\,\nbetter quality of service and certainly cheaper services. Grid centralized portals\nwould provide thous ands of games and entertainment content from different providers.\nToday\, if one buys a new game and wants to play it online\, the user has to conn ect to\na server (possibly) in the USA\, unless a local server was set up. Having a Grid\ninfrastructure would largely ease that process. Users will simply connect to the\nGrid\, play and join the international community o f users.\n\nAn online games scenario implies strong requirements on QoS fo r the provision in\nreal-time of distributed multimedia content all over t he world. Also usage monitoring\nis quite important due to the user profil ing and its matching with the content\n(underage access to inadequate cont ents). Privacy\, billing and community building are\nother properties rele vant for online games and entertainment.\n\nhttp://indico.cern.ch/contribu tionDisplay.py?contribId=59&sessionId=16&confId=286 LOCATION:CERN 40-4-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=59&sessionId=16 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:VOCE - Central European Production Grid Service DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-58@cern.ch DESCRIPTION:Speakers: KMUNICEK\, Jan (CESNET)\nThis contribution describes a grid environment of the Virtual Organization for\nCentral Europe (VOCE) . VOCE infrastructure currently consists of computational\nresources and s torage capacities provided by Central European resource owners. Unlike\nma jority of other virtual organizations VOCE tends to be generic VO providin g\napplication neutral environment especially suitable for Grid newcomers allowing them\nto get quickly first experience with Grid computing and to test and evaluate Grid\nenvironment towards their specific application ne eds. VOCE facilities currently\nprovide base for Central European t-infras tructure. The main goal of VOCE is to\nassist in adapting a software for u se on a fully production Grid\, not within a closed\n"teaching" environmen t\, even for applications that do not have any Grid / cluster\n/remote com puting experience. The VOCE application neutrality can be seen as an\nimpo rtant feature that allows to provide an environment where different applic ation\nrequirements meet and expectations are to be fulfilled. All technic al aspects related\nto the supported middleware (LCG\, gLite)\, computing environments (MPI support)\,\nspecific user interface support (Charon and P-GRADE portal) will be discussed and\npreliminary users experiences evalu ated.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=58&session Id=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=58&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Data Grid Services for National Digital Archives Program in Taiwan DTSTART;VALUE=DATE-TIME:20060301T133000Z DTEND;VALUE=DATE-TIME:20060301T134500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-55@cern.ch DESCRIPTION:Speakers: Mr. YEN\, Eric (Academia SINICA Grid Computing Centr e\, Taiwan)\nDigital archives/libraries are widely recognized as a crucial component of the\nglobal information infrastructure for the new century. Research and development\nprojects in many parts of the world are concerne d about using advanced information\ntechnologies for managing and manipula ting digital information\, ranging from data\nstorage\, preservation\, ind exing\, searching\, presentation\, and dissemination\ncapabilities to orga nizing and sharing of information over networks.\n Digital Archive dema nds for reliable storage systems for persistent digital\nobjects\, well-or ganized information structure for effective content management\,\nefficien t and accurate information retrieval mechanism and flexible services for\n varying users needs. Hundreds of Petabyte of digital information has been created and\ndispersed all over the internet since computers had been used for information\nprocessing\, and the amount still grows in the rate of t ens of Petabyte per year. Grid\ntechnology offers a possible solution for aggregating and processing diversified\nheterogeneous Petabyte scale digit al archives. Metadata-based information\nrepresentation makes specific and relative information retrieval more accurately\,\nmakes information resou rces interoperable\, and paves the way for formal knowledge\ndiscovery. Ta king advantage of advancing IT\, semantic level information indexing\,\nca tegorizing\, analyzing\, tracking\, retrieving and correlating could be im plemented.\nData Grid aims to set up a computational and data-intensive gr id of resources for\ndata analysis. It requires coordinated resource shari ng\, collaborative processing and\nanalyzing on huge amounts of data produ ced and stored by many institutions.\n In Taiwan\, a National Digital A rchive Project (NDAP) was initiated in 2002 with\nits pilot phase started in 2001. According to the record in 2005\, more than 60\nTerabytes digital objects was generated and archived by 9 major content holders in\nTaiwan. Not only delicate and gracious Chinese cultural assets can be preserved a nd\nmade available via the Internet\, but this approach could be proposed as a new\nparadigm of academic researches based on digital and integrated information\nresources. The design and implementation phase is ongoing and we would like to\nillustrate in the EGEE User Forum. \n Academia SINIC A Grid Computing Centre (ASGC) is in charge of building a new\ngeneration of Grid-based research infrastructure in Academia SINICA and in Taiwan\nba sed on EGEE and OSG as the Grid middleware. This infrastructure is a major \ncomponent for the development and the deployment of the National Digital Archive\nProject (NDAP) providing long-term preservation of the digital c ontents and unified\ndata access. These services will be built upon the e- Science infrastructure of\nTaiwan. The Storage Resource Broker (SRB) devel oped at SDSC\, is a Middleware which\nenables scientists to create\, manag e and collaborate with flexible\, unified "virtual\ndata collections" that may be stored on heterogeneous data resources distributed\nacross a netwo rk. The SRB system is the first and the largest (in terms of the data\nvol ume) data store in Academia SINICA right now. The system was deployed by A SGC in\nearly 2004\, which consists of 7 sites in different institutes\, l inked by a dedicated\nfibre campus network\, and provided 60 TB capacities in total. In early 2006\, it will\nexpand to 120 TB. As of January 2006\, more than 30 TB and 1.4 million files have been\narchived in the distribu ted mass storage environment. All files are also preserved in\ntwo copies on different sites.\n In this presentation\, idea for utilizing Data Gr id infrastructure for NDAP will\nbe depicted and discussed. We will descri be the use of SRB in building a\ncollaborative environment for Data Grid S ervices of NDAP. In the environment\, many\ndata intensive applications ar e developed. We also describe our integration\nexperience in building appl ications of NDAP. For each application we characterize the\nessential data virtualization services provided by the SRB for distributed data\nmanagem ent.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=55&sessionI d=11&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=55&sessionId=11 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Applications integrated on the GILDA's testbed. DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-57@cern.ch DESCRIPTION:Speakers: Dr. CALANDUCCI\, Antonio (INFN Sez. Catania - Italy) \, Dr. LA ROCCA\, Giuseppe (INFN Sez. Catania - Italy)\nCreated with the g oal of providing an infrastructure for training and dissemination\,\nGILDA revealed itself also as a cute entry point for those communities\, often without\nany experience of distributed computing\, desired to test whether or not their\napplications would receive an added value from the grid. Th e wide range of\napplications supported\, shows also as a single testbed c an serve applications and\ncommunities with disparate purposes and final g oals. The intensive use of the GENIUS\nweb portal eased the approach to g rid for native users\, hiding the complexity of\nmiddleware\, providing al so an immediate interface when graphical input/output is\nrequired. Hereaf ter a list of the most significant applications supported in these\ntwo ye ars is reported. A list of the most relevant applications that have been\n integrated on the GILDA’s testbed is reported. During the on-line demo s ession will\nbe presented one or two of these applications focusing on the main EGEE services used.\n\nGA4tS\nThe acronym GA4tS stands for “Geneti c Algorithm for thresholds Searching”. It\nrepresents a medical applicat ion on a grid infrastructure connection\, designed in the\nframework of th e INFN MAGIC-5 project\, which aims at developing interactive tools to\nhe lp radiologists with mass detection in mammography image analysis. Given a database\nof mammography images and extracted from each image a certain n umber of suspicious\nregions or regions of interest (ROI)\, GA4tS is a gen etic algorithm able to\ndiscriminate among two possible ROI populations (t he positive ROI population and the\nnegative ROI population)\, performing a ROI-based classification. A positive ROI is a\npathological ROI\, contai ning a neoplastic lesion or a cluster of micro\ncalcifications. Instead\, a negative ROI has no kind of pathology and means healthy\ntissue. The hug e amount of computing power exploitable by the genetic algorithm\nduring i ts computation represents the grid added value. GA4tS interacts with the\n LFC’s catalog in order to transfer on the worker node the MATLAB Math an d Graphics\nRun-Time Library needed by the genetic algorithm.\n\nComputati onal Chemistry\nThe GEMS (gGrid Enabled Molecular Simulator) prototype has been initially implemented\non the GILDA test bed infrastructure for the specific case of the study of the\nproperties of gas phase atom-diatom rea ctions. Recently the prototype has been ported\non the production grid. Th e specific theoretical approach adopted requires massive\nintegrations of trajectories and parallel runs on the largest number of nodes\navailable. Here the advantages of the grid are in the large availability of nodes\nw here the parallel software can run on. \n\ngMOD\ngMOD (grid Movie on Deman d) is a new application developed to show up how the Grid\ncan give its co ntribution to make businesses in the world of Entertainment. Plugged\ninto GENIUS\, the goal of gMOD is providing a Video-On-Demand service. They ar e\npresented a list of movies (movie trailers in our case due to license i ssues) to\nchoose from and once they have made a choice\, the video file i s streamed in real time\nto the video client in the user’s workstation. gMOD is built on top of the new EGEE\ngLite middleware and makes use of ma ny gLite services (FiReMan and AMGA Catalog\, WMS\n and VOMS). It is worth nothing that gMOD has been realized having in mind the\ncommercial issues and technical problems of a Video On Demand service but can also be\nused to retrieve any kind of digital multimedia contents from the network with many\npossible interesting applications such as\, for example\, e-Learnin g Systems and\nDigital Libraries. The grid added value in this case is rep resented from the large\ncapability of storage\, and the absolute safety p rovided from the use of digital\ncertificates\, which gives the faculty t o the provider of revoking them in any moment\,\nand setting a predefined and unchangeable time for the provided services.\n\nhadronTherapy \nhadro nTherapy is a simulation program based on the CERN toolkit GEANT4\, develo ped at\nINFN LNS. hadronTherapy simulates the beam line and particles reve lators used in the\nproton-therapy facility for the cure of eye cancer at CATANA (Centro AdroTerapia e\nApplicazioni Nucleari avanzate)\, active eve n at INFN-LNS. The typical advantages of\nporting a Montecarlo code on th e grid\, the linear factor gained with the simulation\nsplitting\, are imp roved with the recombination of outputs produced by the sub jobs\nand anal yzed. A graphical output is finally obtained exploiting the ROOT’s featu res.\n\nPatsearch\nPATSEARCH is a flexible and fast pattern matcher able t o search specific combinations\nof oligonucletide consensi and secondary s tructure elements. It is able to find\, in a\ngiven sequence(s)\, kinds of loop structures that characterize tRNAs\, rRNAs and/or any\nkind of patte rn in DNA and protein sequences. Thanks to the grid\, PatSearch's\napplica tion is able to split the search of the given sequence(s) submitting up to ten\nindependent jobs and collects\, at the end\, the partial results and produce a final\noutput. PatSearch interacts with the LFC’s catalog in order to transfer on the worker\nnode’s working directory the input file needed by the pattern matcher. PatSearch is\none of the candidate applica tions of the recently approved EU BioInfoGrid Project.\n\nNEMO and ANTARES \nThe NEMO collaboration has undertaken a R&D program for the construction of an\nunderwater km3 wide telescope for high energy neutrino astronomy i n the Mediterranean\nsea\, while ANTARES is constructing a smaller (0.1 km 2) underwater neutrino telescope\nnear the Toulon coast. The CORSIKA Monte carlo simulation code is used by NEMO to\nsimulate the interaction of prim ary cosmic ions with the atmosphere up to the sea\nlevel with particular r eference to the atmospheric muons generated. In fact\, muons\nrepresent on e of the main sources of background for underwater telescopes for high\nen ergy neutrino astronomy. Mass production of muons at the sea level has bee n\nsimulated first on GILDA and then on the INFN Grid production grid both for the NEMO\nand ANTARES set-ups. The NEMO collaboration from the grid t akes the advantages of the\nthousands of CPU\, which allows to split their simulation in n sub jobs\, gaining a\nfactor of n in execution time. Also CORSIKA simulations uses large input files\, which\ncould have been handl ed with much more difficulty without the grid capacity of storage.\n\nhttp ://indico.cern.ch/contributionDisplay.py?contribId=57&sessionId=22&confId= 286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=57&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Expandig GEOsciences on DEmand DTSTART;VALUE=DATE-TIME:20060301T163000Z DTEND;VALUE=DATE-TIME:20060301T164500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-56@cern.ch DESCRIPTION:Speakers: Mr. YOUINOU\, Gael ()\nWorldwide population faces di fficult challenges for the coming years to produce \nenough energy to sust ain global growth and predict main evolutions of the Earth such \nas earth quakes. Seismic data processing and reservoir simulation are key \ntechnol ogies to help researchers in geosciences to tackle these challenges.\n\nMo dern seismic data processing and geophysical simulations require greater a mounts \nof computing power\, data storage and sophisticated software. The research community \nhardly keeps pace with this evolution\, resulting in difficulties for small or medium \nresearch centres to exploit their inno vative algorithms.\n\nGrid Computing is an opportunity to foster sharing o f computer resources and give \naccess to large computing power for a limi ted period of time at an affordable cost\, \nas well as sharing data and s ophisticated software.\nThe capability to solve new complex problems and v alidate innovative algorithms on \nreal scale problems is also a way to at tract and keep the brightest researchers for \nthe benefit of both the aca demic and industrial R&D geosciences communities.\n\nUnder the “umbrella ” of the EGEE Infrastructure project was created \nEGEODE\, “Expanding Geosciences On Demand” Open Virtual Organization.\n\nEGEODE is dedicate d to research in geosciences for both public and private \nindustrial rese arch & development and academic laboratories. \nThe Geocluster software\, which includes several tools for signal processing\, \nsimulation and inve rsion\, enables researchers to process seismic data and to explore \nthe c omposition of the Earth's layers. In addition to Geocluster\, which is use d only \nfor R&D\, CGG (http://www.cgg.com ) develops\, markets and suppor ts a broad range of \ngeosciences software systems covering seismic data a cquisition and processing\, as \nwell as geosciences interpretation and da ta management.\n\nMany typical Grid Computing projects aim pure Research d omains in infrastructure\, \nmiddleware and usage such as High Energy Phys ics\, Bio informatics\, Earth \nObservation. EGEODE moves the focus toward s collaboration between Industry and \nAcademia.\n\nThere are two main pot ential impacts:\n1 - The transfer of know-how and services to industry. \n 2 - The consolidation and extension of EGEODE community\, which includes b oth \nindustrial and academic research centres.\n\nThe general benefits of grid computing are:\n- Access to computing resources without investing in large IT infrastructure.\n- Optimise IT infrastructure\n o Load balan cing between Processing Centres\n o Smoothing peaks of production\n o Service continuity\; Business Continuity Plan\n o Better fault tol erant system and applications\n o Leverage Processing Centres capacity \n- Lower the total cost of IT by sharing available resources with other m embers of the\ncommunity.\n\nAnd the specific benefits for the Research co mmunity:\n- Easy access to academic software and comprehensive\, industria l software.\n- Free the researcher from the additional burden of managing IT hardware and software\ncomplexity and limitations.\n- Create a framewor k to share data and project resources with other teams across \nEurope and worldwide.\n- Share best practices\, support\, and expertises.\n- Enable cross-organizational teamwork and partnership.\n\nSome of these benefits h ave been demonstrated through other Grid Projects and need \nto be validat ed in our Geosciences community. Sharing IT resources and Data is \ntypica lly the primary goal of a Grid Project. Early indicators in our V.O. show that \nfacilitating access to software and simplifying management of hardw are and software \ncomplexity are also extremely important.\n\nhttp://indi co.cern.ch/contributionDisplay.py?contribId=56&sessionId=11&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=56&sessionId=11 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:GDSE: A new data source oriented computing element for Grid DTSTART;VALUE=DATE-TIME:20060302T130000Z DTEND;VALUE=DATE-TIME:20060302T132000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-51@cern.ch DESCRIPTION:Speakers: Dr. TAFFONI\, Giuliano (INAF - SI)\n1. The technique addressed in connection with concrete use cases\nIn a GRID environment th e main components that manages the jobs life are the Grid Resource Framewo rk \nLayer\, the Grid Information System Framework and the Grid Informatio n Data Model. Since the job life is \nstrongly coupled with its computatio nal environment then the Grid middleware must be aware of the specific \nc omputing resources managing the job. Until now\, only two types of computa tional resources\, the hardware \nmachines and some batch queueing systems \, have been taken into account as a valid Resource Framework \nLayer inst ances. However different types of virtual computing machines exist such as the Java Virtual Machine\, \nthe Parallel Virtual Machine and the Data So urce Engine (DSE). Moreover the Grid Information System and Data \nModel h ave been used for representing hardware computing machines\, never conside ring that a software \ncomputational machine is even a resource that can be well represented. This work addresses the \nextension of the Grid Resou rce Framework Layer\, of the Information System and of the Data Model so t hat a \nsoftware virtual machine as a Data Source Engine is a valid instan ce for a Grid computing model\, namely the \nso called Grid-Data Source En gine (G-DSE). Once the G-DSE has been defined\, a new Grid element\, namel y the \nQuery Element (QE) can be in turn defined\; it enables the access to a Data Source Engine and Data Source\, \ntotally integrated with the G rid Monitoring and Discovery System and with the Resource Broker.\nThe G-D SE has been designed and set up in the framework of the GRID.IT project\, a multidisciplinary Italian \nproject funded by the Ministry of Education\ , University and Research\; the Italian astrophysical community \nparticip ates to this project by porting on Grid three applications\, one of them a ddressed to the extraction of \ndata from astrophysical databases and thei r reduction by exploiting resources and services shared on the \navailable INFN Grid infrastructure whose middleware is LCG based. The use case we e nvisaged and sketched \nout for this application reflects the typical way astronomers work with. Astronomers typically require to 1) \ndiscover astr onomical data that reside on astronomical databases spread worldwide\; thi s discovery process is \ndriven through a set of metadata fully describing the data the user looks for\; 2) if data are found in some \narchive on t he network they are retrieved and processed through a suite of appropriate reduction software \ntools\; data can also be cross-correlated with simil ar data residing elsewhere or just acquired by the \nastronomer\; 3) if da ta the user looks for are not found\, the astronomer can decide to acquire them through a \nset of astronomical instrumentation or generate them on the fly through proper simulation software tools\; 4) \nat the end of the data processing phase the user typically saves the results in some databas e reachable on the \nnetwork.\nIn the framework of our participation to GR ID.IT project we realized that the LCG Grid infrastructure based on \nGlob us 2.4 is strongly computing centric and does not offer any mechanism to a ccess databases in a \ntransparent way for final users. For this reason\, after having evaluated a number of possible solutions like \nSpitfire and OGSA-DAI\, it was decided to undertake a development phase on the Grid mid dleware to make it \nable to fully satisfy our application demands. It is worth to note here that a use case like that described above \nis not pecu liar of the astrophysical community only\, rather it is applicable to othe r disciplines where access to \ndata stored in complex structures like dat abase represent a factor of key importance.\nWithin the GRID.IT project th e extended LCG Grid middleware has been extensively tested proving that th e \nsolution under development makes the Grid technology able to fully mee t the requirements of typical \nastrophysical application.\nThe G-DSE is c urrently in a prototypal state\; further work is needed to refine it and b ring it in a production \nstate. Once the Grid middleware has been enhance d through the inclusion of the G-DSE\, the new QE can be \nset up. The QE is a specialized CE able to interact\, making use of G-DSE capabilities\, with databases looking \nthem as embedded resources within the Grid\, like a computing resource or a disk resident file. The QE is able \nto process and handle complex workflows that foresee both the usage of traditional G rid resources as well as \nthe new ones\; database resources in particular may be seen and used as data repository structures and even \nas virtual computing machines to process data stored within them.\n\n2. Best practice s and application level tools to exploit the technique on EGEE\nA suite of tools are currently in the process of being designed and set up to make e asy for applications to use \nthe functionalities and capabilities of a G- DSE enabled Grid infrastructure. Such tools are mainly thought to \nhelp u sers in preparing the JDL scripts able to exploit the G-DSE capabilities a nd\, ultimately\, the \nfunctionalities offered by the new Grid QE. The fi nal goal however is to offer to final users graphical tools to \ndesign an d sketch out their workflows to be passed on to the QE for their analysis and processing. A \nprecondition\, obviously\, to achieve these results is to have the G-DSE\, and then the QE fully integrated in the \nGrid middle ware used by EGEE.\n\n3. Key improvements needed to better exploit this te chnique on EGEE\nThe current prototype of the G-DSE is not included yet in the Grid middleware flavours the EGEE infrastructure \nis based on. The t est phase carried out on the G-DSE prototype so far has made use of a para llel test bed Grid \ninfrastructure set up thanks to the collaboration bet ween INFN and INAF. Such parallel infrastructure is made \nof a BDII and o f a RB on which the modified Grid components constituting the G-DSE have b een mounted. The \nmandatory precondition to make use of the G-DSE\, there fore is its inclusion (i.e. the modified components of \nthe Grid middlewa re) in the Grid infrastructure used by EGEE. \n\n4. Industrial relevance\n The G-DSE has been originally thought to solve a specific problem of a sci entific community and the analysis \nof new application fields has been fo cussed so far in the scientific research area.\nBecause G-DSE however repr esents a general solution to make of any database an embedded resource of the \nGrid\, quite apart from the nature and kind of data contained within it\, it is natural for the G-DSE to extend its \napplicability even in th e field of industrial applications whenever the access to complex data str uctures is a \ncrucial aspect.\n\nhttp://indico.cern.ch/contributionDispla y.py?contribId=51&sessionId=13&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=51&sessionId=13 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Using Grid Computation to Accelerate Structure-based Design Agains t Influenza A Neuraminidases DTSTART;VALUE=DATE-TIME:20060301T153000Z DTEND;VALUE=DATE-TIME:20060301T154500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-53@cern.ch DESCRIPTION:Speakers: Dr. WU\, Ying-Ta (Academia Sinica Genomic Research C enter)\nThe potential for re-emergence of influenza pandemics has been a g reat threat since\nthe report of that the avian influenza A virus (H5N1) h aving acquired the ability to\nbe transmitted to humans. An increase of tr ansmission incidents suggests the risk of\nhuman-to-human transmission\, a nd the report of development of drug resistance\nvariants is another poten tial concern. At present\, there are two effective antiviral\ndrugs availa ble\, oseltamivir (Tamiflu) and zanamivir (Relenza). Both drugs were\ndisc overed through structure-based drug design targeting influenza neuraminida se\n(NA)\, a viral enzyme that cleaves terminal sialic acid residue from g lycoconjugates.\nThe action of NA is essential for virus proliferation and infectivity\; therefore\,\nblocking the actives would generate antivirus effects. To minimize non-productive\ntrial-and-error approaches and to acc elerate the discovery of novel potent\ninhibitors\, medicinal chemists can take advantage of using modeled NA variant\nstructures and doing structur e-based design.\n\nA key work in structure-based design is to model comple xes of candidate compounds to\nstructures of receptor binding sites. The c omputational tools for the work are based\non docking tools\, such as Auto Dock\, to carry out quick conformation search of small\ncompounds in the b inding sites\, fast calculation of binding energies of possible\nbinding p oses\, prompt selection for the probable binding modes\, and precise ranki ng\nand filtering for good binders. Although docking tools can be run auto matically\, one\nshould control the dynamic conformation of the macromolec ular binding site (rigid or\nflexible) and the spectrum of the screening s mall organics (building blocks and/or\nscaffolds\; natural and/or syntheti c compounds\, diversified and/or “drug-like”\nfiltered libraries). Thi s process is characterized by computational and storage load\nwhich pose a great challenge to resources that a single institute can afford (For\nexa mple\, using AutoDock to evaluate one compound structure for 10 poses with in the\ntarget enzyme would take 200 Kilobyte storage and 15 minutes on an average PC). The\ntask to evaluate 1 million compound structures 100 pose s each would cost 2 Terabyte\nand more than hundred years). To support suc h kind of computing demands\, this project\nwas initiated to develop a ser vice prototype for distributing huge amount of\ncomputational docking requ ests by taking the advantages of the LCG/EGEE Grid\ninfrastructure.\n\nAcc ording to what we have learned from both the High-Energy Physics experimen ts and\nthe Biomedical community\, an effective use of large scale computi ng offered by the\nGrid is very promising but calls for a robust infrastru cture and careful preparation.\nImportant points are the distributed job h andling\, data collection and error\ntracking: in many cases this might be a limitation due to the need of grid-expert\npersonnel effort. Our final goal is to deliver an effective service to academic\nresearchers who for t he most part are not Grid experts\, therefore we adopted a\nlight-weight a nd easy-to-use framework for distributing docking jobs on the Grid. We\nex pect that this decision will benefit future deployment efforts and improve \napplication usability.\n\nIntroducing the DIANE framework in building th e service is aimed at handling the Grid\napplications in master-worker mod el\, a native computing model of distributing docking\njobs on the Grid. W ith the skeletal parallelism\, applications plugged into the\nframework in herit the intrinsic DIANE features of distributed job handling such as\nau tomatic load balancing\, and failure recovery. The python-based implementa tion also\nlowers the development effort of controlling application jobs o n the Grid. With the\nhiding of composing JDL and of submitting jobs\, use rs can even easily distribute\ntheir application jobs on the Grid without having Grid knowledge. In addition\, this\nsystem can be used to seamlessl y merge local guaranteed resources (like a dedicated\ncluster) with on-dem and power provided by the Grid\, allowing researches to\nconcentrate on se tting up of their application without facing a heavy entry barrier\nto mov e in production mode where more resources are needed.\n\nIn a preliminary study\, we arranged the work into six tasks: (1) target 3D structure\nprep aration\; (2) compound 3D structure preparation and refinement\, (3) compo und\nproperties and filter\, (4) Autodock run (5) probable hits analysis a nd selection\, and\n(6) complex optimization and affinity re-calculation. The DIANE framework has been\napplied to distribute about 75000 time-consu ming AutoDock processes on LCG for\nscreening possible inhibitor candidate s against neuraminidases. In addition to show\nthe distribution efficiency \, advantages of adopting DIANE framework in the AutoDock\napplication are also discussed in terms of usability\, stability and scalability.\n\nhttp ://indico.cern.ch/contributionDisplay.py?contribId=53&sessionId=9&confId=2 86 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=53&sessionId=9& confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Status of Planck simulations application DTSTART;VALUE=DATE-TIME:20060301T133000Z DTEND;VALUE=DATE-TIME:20060301T140000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-52@cern.ch DESCRIPTION:Speakers: Dr. VUERLI\, Claudio (INAF-SI)\n1. Application conte xt and scientific goals\nAn accurate measure of the whole sky emission in the frequencies of the microwave \nspectrum and in particular of the Cosmi c Microwave Background (CMB) anisotropies can \nhave crucial implications for the whole Astrophysical community as it permits to \ndetermine a numbe r of fundamental quantities that characterize our Universe\, its \norigin and evolution.\nThe ESA Planck mission is aimed to map the microwave sky p erforming at least two \ncomplete sky surveys with an unprecedented combin ation of sky and frequency \ncoverage\, accuracy\, stability and sensitivi ty. \nThe satellite will be launched in 2007 carrying a payload composed o f a number of\nmicrowave and sub-millimetre detectors which are grouped in to a high frequency \ninstrument (HFI) and a low frequency instrument (LFI ) covering frequency channels \nranging from 30 up to 900 GHz.\nThe instru ments are built by two international Consortia which are also in charge of \nthe related Data Processing Centres (DPCs). The LFI DPC is located in T rieste\, the \nHFI DPC is distributed between Paris and Cambridge. In both Consortia\, participation \nin the development of the data processing sof tware to be included in the DPCs is \ngeographically distributed throughou t the participating Institutions. The overall \nPlanck community is compos ed of over 400 scientists and engineers working in about \n50 institutes s pread in 15 countries\, mainly in Europe but including also Canada\nand th e United States. A fraction of this community\, the one possibly involved with \nGrid activities\, can be defined as the Planck Virtual Organisation (VO).\nDuring the whole of the Planck mission (Design\, Development\, Ope rations and Post-\noperations)\, it is necessary to deal with aspects rela ted to information management\, \nwhich pertain to a variety of activities concerning the whole project\, ranging from \ninstrument information (tec hnical characteristics\, reports\, configuration control \ndocuments\, dra wings\, public communications\, etc.)\, to the proper organisation of the \nprocessing tasks\, to the analysis of the impact on science implied by s pecific \ntechnical choices. For this purpose\, an Integrated Data and Inf ormation System \n(IDIS) is being developed to allow proper intra-Consorti um and inter-Consortia \ninformation exchange.\nWithin the Planck communit y the term "simulation" refers to the production of data \nresembling the output of the Planck instruments. There are two main purposes in \ndevelop ing simulation activities:\n- during ESA Phase A and instrument Phases A a nd B\, simulations have been used to \nhelp finalising the design of the P lanck satellite’s P/L and Instruments hardware\;\n- on a longer time-sca le (up to launch)\, simulated data will be used mainly to help \ndevelop t he software of the data processing pipeline DPCs\, by allowing the testing \nof algorithms needed to solve the critical reduction problems\, and by evaluating the \nimpact of systematic effects on the scientific results of the mission\, before real \ndata are obtained.\nThe output of the simulat ion activity is Time-Ordered Information (TOI)\, i.e. a set \nof time seri es representing the measurements of the scientific detectors\, or the \nva lue of specific house-keeping parameters\, in one of the Planck instrument s. TOI \nrelated to scientific measurements are often referred to as Time- Ordered Data (TOD).\nCommon HFI-LFI tools have been built and integrated i n order to build a pipeline \nsystem aimed at producing simulated data str uctures. These tools can be decomposed \nin several stages\, including ing estion of astrophysical templates\, mission \nsimulator\, S/C simulator\, telescope simulator\, electronics and on-board processing \nsimulator. Oth er modules\, such as the cooling system model\, the instruments \nsimulato rs and the TM packaging simulator\, are instrument-dependent. It should be \nnoted that the engine integrating all the tools has to be flexible enoug h in order \nto produce the different needed forms or formats of data.\nTh e Planck Consortia participate to this joint simulations effort to the bes t of \ntheir scientific and instrumental knowledge\, providing specific mo dules for the \nsimulations pipeline. For each Consortium the code allowin g to produce maps and time-\nordered sequences out of simulated microwave skies is the one jointly produced for \nboth Consortia: data simulated by HFI and LFI are therefore coherent and can be \nproperly merged. To the ou tput data of the common code (timelines) an additional LFI-\nspecific code is applied to simulate on-board quantisation and packetisation\, in\norde r to produce streams of LFI TM packets.\nThe goal of this application is t he porting of the whole simulation software of the \nPlanck mission on the EGEE Grid infrastructure.\n\n2. The grid added-value\nPlanck simulations are highly computing demanding and produce a huge amount of data. \nSuch r esources cannot be usually afforded by a single research institute\, both in \nterms of computing power and data storage space. Our application ther efore \nrepresents the typical case where the federation of resources comi ng from different \nproviders can play a crucial role to tackle the shorta ge of resources within single \ninstitutions. Planck simulations take grea t advantage from this as a remarkable \nnumber of resources are available at institutions collaborating in the Planck VO\, so \nthey can be profitab ly invested to get additional resources shared on the Grid. The \nfirst si mulation tests have been carried out on the INFN production Grid in the \n framework of the GRID.IT project. A complete simulation for the Planck/LFI \ninstrument has been run on a single\, dual-CPU\, workstation and on Gri d involving 22 \nnodes\, one for each detector of the LFI instrument. The gain obtained by using the \nGrid was of ~15 times.\nAnother added value c oming from the Grid is its authentication/authorization \nmechanism. Planc k code as well as data are not public-domain\; we need to protect the \nso ftware copyright\; data moreover are property of the Planck P.I. mission. The setup \nof a Planck VO makes possible to easily monitor and control ac cesses to both \nsoftware and data without the need of arranging tools alr eady available in Grid.\nLast but not least a federation of users within a VO fosters the scientific \ncollaboration\, an added value of key importa nce in Planck given that users who \ncollaborates to the mission are sprea d all over Europe and United States.\n\n3. Experiences and results achieve d on EGEE\nDue to some initial issues in the start up process of the Planc k VO\, we were not \nable to fully exploit the big amount of potential res ources available for our \napplication so far. The Planck VO has proved to be quite difficult to manage\; the \nstart up process\, in particular\, h as been slowed down by some difficulties in the \ninteractions between the local Planck VO managers and the respective ROCs. To \novercome these iss ues and make the Planck VO fully operative in a short time on-site \nvisit s to Planck VO sites are foreseen in order to train local managers in sett ing \nup and maintaining the Planck VO node and even local potential users to foster the \nusage of the Grid technology for the Planck application n eeds.\n\n4. Key issues for the promotion of the GRID technology\nOn the ba sis of our experience with the astrophysical community a special effort is \nrequested to spread the Grid technology and make potential users fully aware of the \nadvantages in using it. User tutorials can be extremely hel pful to achieve this \ngoal. Even the preparation of a suite of Grid orien ted tools is of key importance \nlike Grid portals and Grid Graphical User Interfaces to make users able to interact \nwith the Grid in an easy and transparent way and to hide some complexities of the \nunderlying technolo gy.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=52&sessionId =10&confId=286 LOCATION:CERN 40-5-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=52&sessionId=10 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Introduction DTSTART;VALUE=DATE-TIME:20060303T130000Z DTEND;VALUE=DATE-TIME:20060303T131500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-115@cern.ch DESCRIPTION:Speakers: \nhttp://indico.cern.ch/contributionDisplay.py?contr ibId=115&sessionId=21&confId=286 LOCATION:CERN Council Chamber URL:http://indico.cern.ch/contributionDisplay.py?contribId=115&sessionId=2 1&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Application Identification and Support in BalticGRID DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-88@cern.ch DESCRIPTION:Speakers: Dr. JUOZAPAVICIUS\, Algimantas (associate professor) \nIntroduction\n\nThe Baltic Grid project\, a FP6 program\, involving 10 l eading institutions in six \ncountries\, started in November 2005. Its aim s to i) develop and integrate the \nresearch and education computing and c ommunication infrastructure in the Baltic \nStates into the emerging Europ ean Grid infrastructure\, ii) bring the knowledge in \nGrid technologies a nd use of Grids in the Baltic States to a level comparable to \nthat in EU members states\, and iii) further engage the Baltic States in policy and \nstandards setting activities. The integration of Baltic States into the European \nGrid infrastructure is primarily focusing on extending the EGEE (with which four \npartners are already engaged) to the Baltic States. Th e Baltic Grid takes advantage \nof the local existing e-infrastructures in the region.\nThe Baltic Grid project is of high strategic importance for the Baltic States and it \nis designed to give a rapid build-up of a Grid infrastructure\, contributing to the \nenabling of the new member states p articipation in the European Research Area.\nOne of the most important ste ps in Baltic Grid development is application \nidentification and support. This activity will be carried out through three tasks.\n\nPilot Applicati ons\n\nBaltic Grid intends to initiate three pilot applications for valida tion and for \ndemonstration of successful scientific use.\n\nHigh-energy physics application includes statistical data analysis\, production of \nM onte Carlo samples and distributed data analysis\, nuclear and sub-nuclear physics\, \ncondensed matter physics and many-body problems. It will be i mplemented because of \nthe critical importance of Grids to this community and its relative maturity.\n\nMaterial sciences application presents rese arch areas\, having substantial number of \npotential Grid users among sci entists in Baltic states. It includes tools for \nestablishing the geometr ical structure of various organic\, metal-organic and \ninorganic material s\; understanding optical and magnetic properties of molecular \nderivativ es\; predicting new technology and creation of new materials with specifie d \ncharacteristics. Modelling and simulation of heterogeneous processes i n chemistry\, \nbiochemistry\, geochemistry\, electrochemistry\, biology\, engineering will be \nimplemented because of MS strategic importance to t he Baltic States and substantial \ncomputing needs.\n\nA bioinformatics ap plication will be implemented to give tools and computing \nprocedures for sequence pattern discovery and the gene regulatory network \nreconstructi on\, inference of haplotype structure and pharmacogenetics related \nassoc iation\, studies\, modelling and exploration of mechanism of enzymatic cat alysis\, \nde novo design of proteins\, quantum-mechanical investigations of organic molecules \nand their applications\, for the refinement of 3D b iological macromolecule models \nagainst X-ray diffraction or NMR data\, f or modeling of biosensors and other reaction-\ndiffusion processes. This a pplication intends also to support the collaborative \nefforts of scientis ts in the Baltic States in this highly distributed community with \nneeds to share data from many sources and a diverse set of tools.\n\nSpecial Int erest Groups\n\nThe task of special interest groups (SIG) aims to improve communication among many \nseparate research groups\, having similar or re lated R&D interests. The development \nand implementation of SIGs is a rel atively new idea in grid computing infrastructure \nbased on semantics rep resentation methods and tools and leading to enhancement of \nservices and applications with knowledge and semantics. Research areas under \nconside ration for SIG development and implementation are: modelling of the Baltic \nSea eco-system (together with BOOS – a future operational oceanograph ic service to \nthe marine industry in the Baltic region)\, hydrodynamic e nvironmental models for \nsustainable development of the Baltic Sea coasta l zone\, environmental impact \nassessment and environmental processes mod eling\, life sciences and medicine.\n\nApplication Adaptation Support\n\nT his is a specific activity aiming to organize and initiate communication b etween \napplication experts and Grid experts facilitating rapid Grid adap tation and \ndeployment of applications through formation of an Applicatio n Expert Group. This \ngroup will analyze applications and identify requir ed Grid technologies and provide \nconsulting services to application deve lopers. The services will include assistance \nwith integration with the M igrating Desktop to enable GUI-based access to the BG \ninfrastructure and services\, ensuring interoperability with the BG middleware. \nPerformanc e studies to find bottle necks of the deployed applications may be carried \nout if needed using tools for performance evaluation\, like G-PM and OC M-G\, developed \nin CrossGrid Project.\n\nhttp://indico.cern.ch/contribut ionDisplay.py?contribId=88&sessionId=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=88&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Scheduling Interactive Jobs DTSTART;VALUE=DATE-TIME:20060302T130000Z DTEND;VALUE=DATE-TIME:20060302T133000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-89@cern.ch DESCRIPTION:Speakers: GERMAIN-RENAUD\, Cecile (LRI and LAL)\n1.Introductio n\n\nIn the 70s\, the transition from batch systems to interactive computi ng has been the \nenabling tool for the widespread diffusion of advances i n IC technology. Grids are \nfacing the same challenge. The exponential co efficients in network performance \nenable the virtualization and pooling of processors and storage\; large-\nscale user involvement might require s eamless integration of the grid power into \neveryday use. \n\nIn this pap er\,interaction is a short name for all situations of display-action \nloo p\, ranging from a code-test-debug process in plain ascii\, to computation al \nsteering through virtual/augmented reality interfaces\, as well as po rtal access to \ngrid resources\, or complex and partially local workflows . At various levels\, EGEE \nHEP and biomedical communities provide exampl es of the requirements of a turnaround \ntime at the human scale. Section 2 will provide experimental evidence on this fact.\n \nVirtual machines pr ovide a powerful new layer of abstraction in distributed \ncomputing envir onments. The freedom of scheduling and even migrating an entire OS \nand a ssociated computations considerably eases the coexistence of deadline boun d \nshort jobs and long running batch jobs. The EGEE execution model is no t based on \nsuch virtual machines\, thus the scheduling issues must be ad dressed through the \nstandard middleware components\, broker and local sc hedulers. Section 3 and 4 will \ndemonstrate that QoS and fast turnaround time are indeed feasible within these \nconstraints.\n \n2. EGEE usage\nTh e current use of EGEE makes a strong case for a specific support for short jobs. \nThrough the analysis of the LB log of a broker\, we can propose q uantitative data to \nsupport this affirmation. The broker logged is grid0 9.lal.in2p3.fr\, running \nsuccessive versions of LCG\; the trace covers o ne year (October 2004 to October \n2005)\, with 66 distinct users and more than 90000 successful jobs\, all production. \nThis trace provides both t he job intrinsic execution time $t$ (evaluated as the \ntimestamp of event 10/LRMS minus the timestamp of event 8/LRMS)\, and the makespan \n$m$\, that is the time from submission to completion (evaluated as the timestamp of \nevent 10/LogMonitor minus the timestamp of event 17/UI). The intrins ic execution \ntime might be overestimated if the sites where the job is r un accept concurrent \nexecution. \n\nThe striking fact is the very large number of extremely short jobs. We call Short \nDeadline Jobs (SDJ) those where t \n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=89&sess ionId=16&confId=286 LOCATION:CERN 40-4-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=89&sessionId=16 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Discussion DTSTART;VALUE=DATE-TIME:20060302T172000Z DTEND;VALUE=DATE-TIME:20060302T173000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-110@cern.ch DESCRIPTION:Speakers: \nDiscussion on application data management\n\nhttp: //indico.cern.ch/contributionDisplay.py?contribId=110&sessionId=13&confId= 286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=110&sessionId=1 3&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Title: "IBM strategic directions in workload virtualization" DTSTART;VALUE=DATE-TIME:20060302T163000Z DTEND;VALUE=DATE-TIME:20060302T170000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-112@cern.ch DESCRIPTION:Speakers: Dr. PROST\, Jean-Pierre (IBM Montpellier)\n"Workload virtualization is made of several disciplines: job/workflow scheduling\, \nworkload management\, and provisioning. Much work has been spent so far on these \nvarious components in isolation. A better synergistic integrat ion of these \ncomponents allowing their interoperability towards an optim ized resource allocation \nin order to satisfy user specified service leve l objectives is necessary. Other \nchallenges in the grid space deal with being able to allow meta-scheduling and \nadaptive/dynamic workflow schedu ling. In this talk\, we present IBM strategic \ndirections in the workload virtualization area. We also \nbriefly introduce our current product port folio in that space and describe how it \nmay evolve over time\, based on customer requirements and additional business value \ntheir satisfaction c ould provide them."\n\nhttp://indico.cern.ch/contributionDisplay.py?contri bId=112&sessionId=15&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=112&sessionId=1 5&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:An Attempt at Applying EGEE Grid to Quantum Chemistry DTSTART;VALUE=DATE-TIME:20060301T153000Z DTEND;VALUE=DATE-TIME:20060301T154500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-82@cern.ch DESCRIPTION:Speakers: Dr. STERZEL\, Mariusz (Academic Computer Centre "Cyf ronet")\nThe EGEE Grid Project enables access to huge computing and storag e resources. Taking\nthis oportunity we have tried to identyfie chemical problems that could be computed\nin this environment. Some of the results considered within this work are presented\nwith description focused on re quirements for the computational enviroment as well as\ntechniques of Grid -enabling computations based on packages like GAMESS and GAUSIAN. \n Recen tly lots of work has been done in the area of parallelizing the existing c odes\nand discovering new ones used in quantum chemistry. That allows calc ulations to run\nmuch faster now than even ten years ago. However\, there still exist tasks where\nwithout a large number of processors it is not po ssible to obtain satisfactory\nresults. The two main challenges are harmon ic frequency calculations and ab-initio\n(AI) molecular dynamics (MD) simu lations. The former ones are mainly used to analyze\nmolecular vibrations. Despite the fact that the algorithm for analytic harmonic\nfrequency calc ulations has been known for over 20 years\, only few quantum chemical\ncod es have it implemented. The other still use numerical scheme where for a g iven\nnumber of atoms (N) in a molecule\, \, and for more accurate calcul ations \nindependent steps (energy + gradients) have to be done to get ha rmonic frequencies.\nTo achieve this as many processors as possible is nee ded to fit that huge number of\ncalculations. This makes grids technology an ideal solution for that kind of\napplication. The second challenge\, MD simulations are mainly used in a case where\n’static’ calculation lik e for example determination of Nuclear Magnetic Resonance\n(NMR) chemical shifts gives wrong results. MD consists usually of two steps. In the\nfirs t one the nuclear gradients are calculated\, in the second one\, based on obtained\ngradients\, the actual classical forces acting on an atom are ca lculated. Knowing\nthese forces one can estimate accelerations\, velocitie s and guess new position of the\natom after a given short period of time ( so called time step). Finally the whole\nprocess is repeated for every new position of each atom. In case of mentioned NMR\nexperiment we are intere sted in the average value of chemical shift over simulation.\nOf course NM R calculations are also very time consuming themselves and have to be\ndon e for many different geometries which again makes grid technology an ideal \nsolution to final NMR chemical shift calculations.\n We present here tw o kinds of calculations. First we show results for geometry\noptimization and frequency calculations for a few carotenoids. These molecules are of\n almost constant interest since they cooperate with chlorophyll in photosyn thesis\nprocess. All the calculations have been done within EGEE Grid (VOC E VO). We also\npresent an example of MD calculations and share our knowle dge about what kind of\nproblems can be found during such studies.\n\nhttp ://indico.cern.ch/contributionDisplay.py?contribId=82&sessionId=12&confId= 286 LOCATION:CERN 40-4-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=82&sessionId=12 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Logging and Bookkeeping and Job Provenance services DTSTART;VALUE=DATE-TIME:20060302T130000Z DTEND;VALUE=DATE-TIME:20060302T133000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-83@cern.ch DESCRIPTION:Speakers: Prof. MATYSKA\, Ludek (CESNET\, z.s.p.o.)\nLogging a nd Bookkeeping (LB) service is responsible for keeping track of jobs\nwith in a complex Grid environment. Without such a service\, users are\nunable to find out what happened with their lost jobs and Grid administrators\nar e not able to improve the infrastructure. The LB service developed\nwithin the EGEE project provides a distributed scalable solution able to\ndeal w ith hundreds thousands of jobs on large Grids. However\, to provide\nthe n ecessary scalability and not to slow down the processing of jobs\nwithin a middleware\, it is based on a non-blocking asynchronous model.\nThis mean s that the order of events sent to LB by individual parts of\nthe middlewa re (user interface\, scheduler\, computing element\, ...) is not\nguarante ed. While dealing with such out of order events\, the LB may\nprovide info rmation that looks inconsistent with the knowledge user has\nfrom some oth er source (e.g. he got independent notification about the\njob state). The lecture will reveal LB internal design and we will\ndiscuss how the LB re sults (i.e. the job state) should be interpreted.\nWhile LB is dealing wit h active jobs only\, Job Provenance (JP) is\ndesigned to store indefinitel y information about all jobs that run on a\nGrid. All the relevant informa tion needed to re-submit the job in the\nsame environment is stored\, incl uding computing environment\nspecification. Users can annotate stored reco rds\, providing yet another\nmetadata layer useful e.g. for job grouping a nd data mining over the JP.\nWe will provide basic information about the J P and its use\, looking for a\nfeedback for its improvement.\n\nhttp://ind ico.cern.ch/contributionDisplay.py?contribId=83&sessionId=15&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=83&sessionId=15 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:EnginFrame as FrameWork for Grid Enabled Web Portals on industrial and research contexts. DTSTART;VALUE=DATE-TIME:20060302T140500Z DTEND;VALUE=DATE-TIME:20060302T142000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-80@cern.ch DESCRIPTION:Speakers: FALZONE\, Alberto (NICE srl)\, RODOLICO\, Andrea (NI CE srl)\nEnginFrame is a Web-based innovative technology\, by the Italian company Nice S.r.l.\,\nthat enables access and exploitation of Grid-enabl ed applications and infrastructures.\nIt allows organizations to provide a pplication oriented computing and data services\nto both users (via Web br owsers) and in-house or ISV applications (via SOAP/WSDL\nbased Web service s)\, hiding all the complexity of the underlying Grid infrastructure. \n\n In particular\, EnginFrame greatly simplifies the development of Web porta ls exposing\ncomputing services that can run on a broad range of different computational Grid\nsystems (including Platform LSF\, Sun Grid Engine\, A ltair PBS\, Globus\, LCG-2 and gLite\ngrid middlewares by European project EGEE).\nEnginFrame supports several open and vendor neutral standards and seamlessly\nintegrates with JSR168 compliant enterprise portals\, distrib uted file systems\, GUI\nvirtualization tools and different kinds of authe ntication systems (including Globus\nGSI\, MyProxy and a wide range of ent erprise solutions).\nBecause EnginFrame greatly simplifies the use of Grid -enabled applications and\nservices\, it has already been adopted by numer ous important industrial companies all\nover the world\, besides many lead ing research & educational institutes.\n\nService publishing is achieved b y developing simple XML-based descriptions of the\ninterface and business logic representing the actual services implementation.\nEnginFrame receive s incoming requests via standard Web protocols over HTTP\,\nauthenticates and authorizes the requests and then executes the required actions into\nt he underlying Grid computational environment.\nThen\, EnginFrame gathers t he results and transforms them into a suitable format\nbefore sending the response to the client. Transformation of results is performed\naccording to the nature of the client: HTML for Web browsers and XML for Web service s\nclient applications or RSS clients.\nFor each submitted service\, a dat a staging area (the "spooler") for the service input\nand output files is created on the file system. \n\nMost of the information managed by EnginFr ame are described by dynamically generated\nXML documents.\nThe source of such information is typically the service execution environment: an XML\na bstraction layer aims to submit service actions and translate raw results coming\nfrom the computational environment into XML structures.\nThe XML abstraction layer is designed to decouple EnginFrame from the actual Grid\ nworking environment\, hiding the specific Grid technology solution. This\ ncharacteristic makes possible to easily extend EnginFrame functionalities by\ndeveloping ad-hoc plugins for specific computational and data Grid mi ddlewares.\nTo support the integration of data Grid middleware solutions\, EnginFrame introduces\nthe concept of Virtual Spoolers that represent di stributed data areas that reside\noutside the EnginFrame spoolers file sys tem\, but that can be remotely accessed by\nEnginFrame itself through the targeted data Grid technology. The structure and the\ncontent of a Virtual Spooler is described by a dynamically generated XML document.\nThus\, the access to data catalogs and storage technologies is provided in a very ea sy\nway and their contents can be inspected like a "browse a file".\n\nCon cerning technical aspects\, there are some key issues that must be address ed\nproperly in Grid Portal development in industrial contexts:\ngrid secu rity and authentication aspects are critical both at Grid middleware-level \nand at access-level\;\nthe authorization system should be built into the Grid system\, enabling a\nfine-grained access control to resources (datas ets\, licenses\, computing resources)\; \nthe accounting system\, suitable to collect the resource usage and supporting\nreporting and billing servi ces\, should be able to collect the records from the\nvarious Grid nodes a nd merge them according to the business needs\; \napplication integration and deployment to the Grid context\, as well as administration\nshould be standardized and simplified\;\nthe access and the exploitation of Grid ena bled applications by the end users should\nbe simplified to the level of a web browsing experience\; \nthe users shouldn't need to be aware of the G rid infrastructure running the\napplication\, to perform their tasks. \n\n For the industrial/engineering companies\, the long and complex process th at goes from\nthe design of an industrial product to manufacturing\, invol ves the cooperation of\ndozens or hundreds of people\, departments or comp anies\, often SMEs\, ranging from\nengineering service providers to compon ent suppliers. This can be regarded as a\n“virtual organization”\, mad e of individual members or groups of people from the\nvarious companies th at share\, with a well defined role and profile\, the overall\nproject goa l\, often composed of geographically distant members\, which would benefit \nfrom increased\, real-time sharing of information and IT infrastructures \, while\npreserving the intellectual properties of each of the project me mbers. There are a\nnumber of factors\, ranging from human\, to organizati onal\, to technical and to\nbusiness aspects that are only partially addre ssed by current GRID technologies\, that\npratically limit the adoption of this approach. \n\nThe Web-centric approach lets users access any service virtually from anywhere\, at\nany time\, over any network and platform\, including Personal Digital Assistant and\nCellular Phones\, thus supportin g the ubiquitous access to the Grid.\nBuilt on the experience of Industria l and Engineering requirements\, the EnginFrame\nsystem has been designed to enable addressing effectively the above mentioned values\,\nwhile minim izing the efforts to build and maintain a successful Grid Portal solution. \n\nGENIUS Portal [1]\, based and powered by EnginFrame\, jointly develop ed by INFN and\nNICE srl within the INFNGrid Project\, allows in a very ea sy way the integration of\napplications ported to be executed on LCG-2 and gLite Middlewares\, and many\napplications have been implemented on GILDA dissemination testbed [2] from the\nbeginning and shown within dozens of tutorials\, giving to the user an easy way to run\njobs on the grid and to manage own data using the virtualizations offered by exposed\nservices at different levels\, locally\, remotely\, on catalogs. On the other hand\,\ nusing the EnginFrame Framework\, GENIUS Portal has inherited all the feat ures\,\nderiving from years of development and experience into industrial contexts\, like\nscalability\, flexibility\, easy maintenance\, security\, fault tolerance\, connectivity\,\ndata management\, authorization\, usabi lity.\n\nConclusions.\nThe adoption of this innovative technology has give n industries and engineering\ncompanies very important benefits in improve ments in productivity running on\nGrid-enabled infrastructures. GENIUS\, b y staying aligned with the middleware\ndevelopment\, can be an instrument to facilitate a dialog between research and\nindustrial contexts based on a high-level services approach. This dialog can give\nalso a very high add ed-value for both worlds\, to spread the use of Grid\ninfrastructures and generate a critical mass of awareness and trust.\n\nReferences.\n[1] "GENI US: a simple and easy way to access computational and data grids" G.\nAndr onico\, R. Barbera\, A. Falzone\, P. Kunszt\, G. Lo Rè\, A. Pulvirenti\, A. Rodolico -\nFuture Generation of Computer Systems\, vol. 19\, no. 6 (20 03)\, 805-813.\n[2] "GILDA: The Grid INFN Virtual Laboratory for Dissemina tion Activities" G.\nAndronico\, V. Ardizzone\, R. Barbera\, R. Catania\, A. Carrieri\, A. Falzone\, E. Giorgio\,\nG. La Rocca\, S. Monforte\, M. Pa ppalardo\, G. Passaro\, G. Platania - TRIDENTCOM 2005:\n304-305.\n\nhttp:/ /indico.cern.ch/contributionDisplay.py?contribId=80&sessionId=17&confId=28 6 LOCATION:CERN 40-S2-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=80&sessionId=17 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Parametric study workflow support by P-GRADE portal and MOTEUR wor kflow enactor DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-81@cern.ch DESCRIPTION:Speakers: Mr. SIPOS\, Gergely (MTA SZTAKI)\n1. Composing and e xecuting data-intensive workflows on the EGEE infrastructure\n\nGrid compu ting is naturally very well suited for handling data-intensive \napplicati ons involving the analysis of huge amounts of data. In many scientific \na reas the need for composing complex applications on grids from basic proce ssing \ncomponents has emerged. The classical task-based job description a pproach is \nproviding a mean of depicting such applications but it become s very tedious when \ntrying to express complex application logics and lar ge input data sets. Indeed\, a \ndifferent task needs to be described for each component and each input to consider. \nHigher level interfaces for e asing the migration of applications to grid \ninfrastructures are drastica lly needed. To ease the migration to grids of such \ncomplex and data inte nsive applications we are proposing a powerful tool which:\n\n• Simplifi es the application logic description through a graphical and \nintuitive e ditor.\n• Enables the seamless integration of data intensive application running on \ndifferent grid infrastructures.\n• Permit try-and-retry ex periments design and tuning through a flexible \ndescription and execution environment.\n• Eases legacy code migration.\n• Provides high level m onitoring and trace analysis capabilities.\n\nThis tool is based on the in tegration of the PGRADE grid portal [1] and the MOTEUR \nworkflow executio n engine [2].\n\n2. MOTEUR workflow execution engine\n\nThe service-based paradigm\, plebiscited in the grid community\, is elegantly enabling \nthe composition of different application components through a common invocati on \ninterface. In addition\, the service-based approach nicely decouples the description \nof processing logic (represented by services) and data t o be processed (given as \ninput parameters to these services). This is pa rticularly important for describing \nthe application logic independently from the experimental setting (the data to \nprocess).\nMOTEUR is a servic e-based workflow enactor developed to efficiently process \napplication wo rkflows by exploiting the parallelism inherent to grid \ninfrastructures. It is taking as input the application workflow description \n(expressed in Scufl language from the MyGrid project [3]) and the data sets to \nproces s. MOTEUR is orchestrating the execution of the application workflow by \n invoking asynchronously applications services. It takes care of processing \ndependencies and preserves the causality of computation on a highly dis tributed and \nheterogeneous environment.\nVery complex data processing pa tterns may be described in a very compact way. In \nparticular\, the dot p roduct (pairwise data composition) and cross product (all-to-\nall data co mposition) patterns from the Scufl language are very efficiently reducing \ncomplex data-intensive application graphs into much simpler ones. They s ignificantly \nenlarge the expressiveness of the workflow language. \nIn a ddition\, MOTEUR enables all level of parallelism that can be exploited in a data-\nintensive workflow: workflow parallelism (inherent to the workfl ow topology)\, data \nparallelism (different input data can be processed i ndependently in parallel)\, and \nservices parallelism (different services processing different data are independent \nand can be executed in parall el). To our knowledge\, MOTEUR is the first service-\nbased workflow enact or implementing all these optimizations.\n\n3. The PGRADE portal GUI\n\nDu ring the last few years the P-GRADE portal has been chosen as the official portal \nby several Globus and LCG-2 middleware based Grid projects aroun d Europe. In its \noriginal concept the P-GRADE Portal supported the devel opment and execution of job-\noriented workflows by the Condor DAGMan work flow manager. While DAGMan is a robust \nscheduler to submit jobs and to t ransfer input-output files among grid resources\, it \nuses a quite simple scheduling algorithm\, it is not able to invoke Web/Grid services \nand i t cannot exploit every possible level of application parallelism (e.g. \np ipelining). \nTo overcome these difficulties the P-GRADE portal has been i ntegrated with the \nMOTEUR workflow manager. On top of that the P-GRADE P ortal has been equipped with a \nuniversal interface by which it can be ea sily connected to other types of workflow \nengines. As a result every EGE E user community with its own application-specific \nscheduler can use the P-GRADE Portal to manage the execution of domain-specific \nprograms on t he connected Grids or VOs. \nBased on the DAGMan and MOTEUR workflow manag ers the P-GRADE Portal supports the \ndevelopment and execution of stand-a lone applications\, parameter study applications \nand workflows composed from normal and/or parameter study components. These \napplications can be executed in LCG-2\, Web services or Globus-based grids. During \nthe exec ution the portal automatically selects the most appropriate plugged-in \nw orkflow manager to perform the scheduled submission of jobs\, service invo cation \nrequests or data transfer processes. \nThe presentation introduce s the capabilities of the MOTEUR-enabled P-GRADE Portal \nand the way in w hich the EGEE bioscience community is using it to solve a medical \nimage processing problem. The community is going to develop a workflow of parame ter \nstudy components that is capable to perform large number of operatio ns on a huge set \nof medical images. The different components of the work flow represent Web services \nand are described by graphical notations. Th e MOTEUR workflow manager is responsible \nfor the pipelined invocation of these Web services driven by the medical images and \nthe different contr ol input parameters.\n\n[1] PGRADE portal\, http://www.lpds.sztaki.hu/pgpo rtal\n[2] MOTEUR\, http://www.i3s.unice.fr/_glatard/software.html\n[3] UK eScience MyGrid project\, http://www.mygrid.org\n\nhttp://indico.cern.ch/c ontributionDisplay.py?contribId=81&sessionId=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=81&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:EELA Status Report DTSTART;VALUE=DATE-TIME:20060303T141500Z DTEND;VALUE=DATE-TIME:20060303T143500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-119@cern.ch DESCRIPTION:Speakers: \nhttp://indico.cern.ch/contributionDisplay.py?contr ibId=119&sessionId=21&confId=286 LOCATION:CERN Council Chamber URL:http://indico.cern.ch/contributionDisplay.py?contribId=119&sessionId=2 1&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:EUMEDGrid Status Report DTSTART;VALUE=DATE-TIME:20060303T135500Z DTEND;VALUE=DATE-TIME:20060303T141500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-118@cern.ch DESCRIPTION:Speakers: \nhttp://indico.cern.ch/contributionDisplay.py?contr ibId=118&sessionId=21&confId=286 LOCATION:CERN Council Chamber URL:http://indico.cern.ch/contributionDisplay.py?contribId=118&sessionId=2 1&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:VirtualGILDA: a virtual t-infrastructure for system administrator tutorials DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-84@cern.ch DESCRIPTION:Speakers: BARBERA\, Roberto (INFN Catania)\nIn the Grid dissem ination activity\, teaching of Grid elements installation covers a\nvery i mportant role. While in tutorials for users availability of accounts and\n certificates is enough\, in those ones for administrators a certain number of free\nmachines is needed\, and the requirements for a Grid-middleware compliant operating\nsystem also occurs.\n\nThe VirtualGILDA infrastructur e for training aims at offering a set of Virtual\nMachine (VM)\, hosted in Catania and based on VMWare technology\, with a pre-installed\nOS and net connectivity: in this way tutors have all the needed machines ready to\nu se. They only need a reliable access to the Internet.\n\nThe presence of p re-installed Grid element is also possible\, in order to provide\ntutors w ith a set of preconfigured machines ready to interact with elements that w ill\nbe installed during the tutorial. \n\nThe use of VMWare technology is also suitable for on site tutorials\, to avoid\nproblems deriving from th e wide range of machine and OS type available on each\ntraining site. Usin g VMs the only requirement is the presence of machines that can\nrun VMPla yer \, i.e. Linux or Windows hosts.\n\nhttp://indico.cern.ch/contributionD isplay.py?contribId=84&sessionId=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=84&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Universal Acessibility to the Grid via Metagrid Infrastructure DTSTART;VALUE=DATE-TIME:20060302T163000Z DTEND;VALUE=DATE-TIME:20060302T164500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-85@cern.ch DESCRIPTION:Speakers: Dr. MAAD\, Soha (Trinity College Dublin)\nThis paper discusses the concept of universal accessibility [1\, 2] to the grid with in\nthe context of selected application domains involving social interacti on such as\ne-hospital\, collaborative engineering\, enterprise\, e-govern ment\, and the media. Based\non this discussion the paper proposes a metag rid infrastructure [3] as an approach to\nprovide universal accessibility to the grid.\n\nUniversal accessibility is rooted in the concept of Design for All in Human Computer\nInteraction[1\, 2]. It aims at efficiently and effectively addressing the numerous and\ndiverse accessibility problems i n human interaction with software applications and\ntelematic services. So far\, the key concept of universal accessibility has been\nsupported by v arious development methodologies and platforms [4\, 5]. Various\napplicati on domains benefited from research and development in this area\, includin g\namong others interactive television and media [6\, 7]. Porting the conc ept of\nuniversal accessibility to the grid is faced by major obstacles at tributed to the\nfollowing: (a) the lack of an underlying functionality si milar to that of a desktop\noperating system allowing the plug and play of resources and the direct user\ninteraction with these resources\; (b) the dilemma between hiding the grid versus\nmaking it more transparent\; and (c) the software engineering practice adopted in grid\nmiddleware developm ent\, where the bottom up approach that is predominant [8]\nconflicts with the ethos of universal accessibility that considers accessibility at\ndes ign time.\n\nThese obstacles and their impacts on universal accessibility to the grid are\ndiscussed with reference to four application domains incl uding collaborative\napplications such as e-hospital\, collaborative engin eering\, enterprise applications\,\nthe media\, and e-government. In colla borative applications the key obstacle for\nuniversal accessibility to the grid is provision of interactivity while respecting\nvarious Service Leve l Agreements (SLAs). Several efforts are underway to resolve this\nissue [ 9\, 21]\, but no versatile solutions have emerged so far. In the enterpris e the\nmajor concern is the management of an integrated data centre [10]\; the key obstacle\nconfronted is that while already offering data-intensiv e computational power the grid\nis quite immature in its provision of perm anent storage of data. This is very much a\nlive issue in grid middleware development. In the media the major challenge is the\ndirect access to rem ote external devices at the grid boundaries. For e-government\naccommodati ng various forms of interaction [11]\, such as government-to-government\n( G2G)\, government-to-citizen (G2C)\, and government-to-business (G2B)\, is paramount\,\nwhilst devoting a major focus on data semantics\, not just s tructure.\n\nSo far universal accessibility to the grid was addressed from various perspectives.\nEfforts undertaken involved: (a) the development o f grid middleware supporting\ninteraction with heterogeneous mobile device s [12\, 13]\; (b) the use of operating\nsystem mobility for configuring gr id application on a PC and then migrating the\nentire application together with the operating system instance onto the grid [14]\;\n(c) the developm ent of a shopping cart system based on the Web Service Resource\nFramework WSRF [15]\; (d) the design of an approach for middleware development\, ba sed\non wrapping the computational and resource intensive tasks\, to allow the\naccessibility to the grid via hand held devices [16\, 22]\; (e) the development of\ncommon web-based grid application portals allowing the app lications' users to\ncustomize their interfaces to the grid [17\, 23\, 24] \; (f) the development of\napplication models for the grid [18]\; and (g) addressing security issues raised by\ngranting grid accessibility via vari ous media delivery channels (such as wireless\ndevices) [19].\n\nWhile eac h of these efforts towards universal accessibility to the grid does addres s\nthe problem to some extent\, none of them enables a complete solution. This paper\nproposes an approach\, based on a metagrid infrastructure\, th at can potentially host\nsolutions to all issues related to universal acce ssibility to the grid. This metagrid\ninfrastructure was used thus far in the context of grid interoperability [3]. Our\nproposed approach extends t he notion of interoperability to embrace grid application\ninteroperabilit y (interactivity and universal accessibility). While heavily based on\nexi sting grid middleware services and architecture such as EGEE\, Globus\, Cr ossGrid\,\nGridPP and GGF [25\, 26\, 23\, 27\, 28]\, the metagrid infrastr ucture hosts one or more\ntarget grid techologies (e.g. it has been demons trated simultaneously hosting WebCom\,\nLCG2 and GT4) while also supportin g its own services that provide things like\nuniversal accessibility that the target grid technologies do not. By doing so it\nfirmly places the use r within the metagrid environment rather than in any one target\ngrid envi ronment. The user obtains universal accessibility via the metagrid service s\,\nand the target grid technologies are relieved of the need to support direct user and\ndevice interactions. \n\nBy way of example\, services cur rently offered by the metagrid infrastructure include\na transparent grid filesystem [26] that supplies a vital missing component beneath\nexisting middleware. The grid filesystem can support universal accessibility by\nsu pporting all forms of data access (r/w/x) in the course of collaborative\n interaction (collaborative engineering and e-hospital)\, by providing a lo gical user\nview of grid data (to support integration of the data centre i n the enterprise)\, and\nby helping locate (discover) data in the course o f interaction in media applications.\nIn so doing it can improve the utili ty of\, for example\, the EGEE middleware. As\nfurther examples\, proposed future services include special purpose discovery services\nto support va rious forms of interaction especially in media applications\; and\nintelli gent interpreters to support e-Government data semantics.\n\nThe paper is divided in five sections. The first section introduces the concept of\nuni versal accessibility and its relevance to the grid. The second section dis cusses\nexisting obstacles facing universal accessibility to the grid in a pplication domains\ninvolving social interaction. The third section overvi ews existing efforts towards\nuniversal accessibility to the grid. The fou rth section propose an approach for\nuniversal accessibility to the grid b ased on a metagrid infrastructure and prototype\nservices offered by this infrastructure. The paper concludes with a summary and a\nfuture research agenda.\n\n= REFERENCES =\n\n [1]:: Stephanidis\, D. Akoumianakis\, M. Sfy rakis\, and A. Paramythis\, Universal\naccessibility in HCI: Process-orien ted design guidelines and tool requirements\,\nProceedings of the 4th ERCI M Workshop on User Interfaces for All\, Edited by\nConstantine Stephanidis \, ICS-FORTH\, and Annika Waern\, SICS\, Stockholm\, Sweden\, 19-21\nOctob er 1998\n\n [2]:: Stephandis\, C.\, From User interfaces for all to an inf ormation society for\nall: Recent achievements and future challenges\, Pro ceedings of the 6th ERCIM Workshop\nUser Interfaces for All\, October 2000 \, Italy\n\n [3]:: Pierantoni\, G. and Lyttleton\, O. and O'Callaghan\, D. and Quigley\, G. and\nKenny\, E. and Coghlan\, B.\, Multi-Grid and Multi- VO Job Submission based on a Unified\nComputational Model\, Cracow Grid Wo rkshop (CGW'05)Cracow\, Poland\, November 2005\n\n [4]:: Stephanidis\, C.\ , Savidis\, A.\, and Akoumianakis\, D.\, Tutorial on Unified\nInterface De velopment: Tools for Constructing Accessible and Usable User Interfaces.\n Tutorial no. 13 in the 17th International Conference on Human Computer Int eraction\n(HCI International'97)\, San Fransico\, USA\, 24-29 August. [Onl ine] Available:\nhttp://www.ics.forth.gr/proj/at_hci/html/tutorials.htm \n \n [5]:: Akoumianakis\, D.\, Stephanidis\, C.\, USE-IT : A Tool for Lexica l Design\nAssistance. In C. Stephanidis (ed.) User Interfaces for All Conc epts\, Methods and\nTools. Mahwah\, NJ: 9. Beynon\, \n\n [6]:: Soha Maad\, Universal Access For Multimodal ITV Content: Challenges and\nProspects\, Universal Access. Theoretical Perspectives\, Practice\, and Experience: 7t h\nERCIM International Workshop on User Interfaces for All\, Paris\, Franc e\, October\n24-25\, 2002. Revised Papers\, N. Carbonell\, C. Stephanidis (Eds.)\, Lecture Notes in\nComputer Science\, Springer-Verlag Heidelberg\, ISSN: 0302-9743\, Volume 2615 / 2003\,\nJanuary 2003\, pp.195-208. \n\n [ 7]:: Soha Maad\, Samir Garbaya\, Saida Bouakaz \, From Virtual to Augmente d Reality in\nFinance: A CYBERII Application\, to appear in the Journal of Enterprise Information\nManagement \n\n [8]:: S. Maad\, B. Coghlan\, G. P ierantoni\, E. Kenny\, J. Ryan\, R. Watson\, Adapting the\nDevelopment Mod el of the Grid Anatomy to meet the needs of various Application\nDomains\, Cracow Grid Workshop (CGW'05)\, Cracow\, Poland\, November\, 2005.\n\n [9 ]:: Herbert Rosmanith\, Dieter Kranzlmuller\, glogin - A Multifunctional\, \nInteractive Tunnel into the Grid\, pp.266-272\, Fifth IEEE/ACM Internati onal Workshop\non Grid Computing (GRID'04)\, 2004.\n\n [10]:: Soha Maad\, Brian Coghlan\, Eamonn Kenny\, Gabriel Pierantoni\, The Grid For the\nEnte rprise: Bridging Theory and Practice\, paper in progress\, Computer Archit ecture\nGroup\, Trinity College Dublin.\n\n [11]:: Maad S.\, Coghlan B.\, John R.\, Eamonn K.\, Watson R.\, and Pierantoni G. 2005\,\nThe Horizon of the Grid For E-Government\, Proceeding eGovernment'05 Workshop\, Brunel\, \nUnited Kingdom\, September 2005.\n\n [12]:: Hassan Jameel\, Umar Kalim\, Ali Sajjad\, Sungyoung Lee\, Taewoong Jeon\,\nMobile-to-Grid Middleware: Bridging the Gap Between Mobile and Grid Environments\,\nAdvances in Grid Computing - EGC 2005\, European Grid Conference\, Amsterdam\, The\nNetherl ands\, February 14-16\, 2005\, Editors: Peter M. A. Sloot\, Alfons G. Hoek stra\,\nThierry Priol\, Alexander Reinefeld\, Marian Bubak\, ISBN: 3-540-2 6918-5\, Lecture Notes\nin Computer Science\, Springer-Verlag GmbH\, Volum e 3470 / 2005\, page 932.\n\n [13]:: Ali Sajjad\, Hassan Jameel\, Umar Kal im\, Young-Koo Lee\, Sungyoung Lee\, A\nComponent-based Architecture for a n Autonomic Middleware Enabling Mobile Access to\nGrid Infrastructure\, Le cture Notes in Computer Science\, Springer-Verlag GmbH\, Volume\n3823/2005 \, pages 1225 - 1234.\n\n [14]:: Jacob Gorm Hansen\, Eric Jul\, Optimizing Grid Application Setup Using\nOperating System Mobility\, Advances in Gri d Computing - EGC 2005\, European Grid\nConference\, Amsterdam\, The Nethe rlands\, February 14-16\, 2005\, Editors: Peter M. A.\nSloot\, Alfons G. H oekstra\, Thierry Priol\, Alexander Reinefeld\, Marian Bubak\, ISBN:\n3-54 0-26918-5\, Lecture Notes in Computer Science\, Springer-Verlag GmbH\, Vol ume 3470 /\n2005\, page 952.\n\n [15]:: Maozhen Li\,Man Qi\, Masoud Rozati \, and Bin Yu\, A WSRF Based Shopping Cart\nSystem\, Advances in Grid Comp uting - EGC 2005\, European Grid Conference\, Amsterdam\,\nThe Netherlands \, February 14-16\, 2005\, Editors: Peter M. A. Sloot\, Alfons G.\nHoekstr a\, Thierry Priol\, Alexander Reinefeld\, Marian Bubak\, ISBN: 3-540-26918 -5\,\nLecture Notes in Computer Science\, Springer-Verlag GmbH\, Volume 34 70 / 2005\, page 993.\n\n [16]:: Saad Liaquat Kiani\, Maria Riaz\, Sungyou ng Lee\, Taewoong Jeon\, Hagbae Kim\,\nGrid Access Middleware for Handheld Devices\, Advances in Grid Computing - EGC 2005\,\nEuropean Grid Conferen ce\, Amsterdam\, The Netherlands\, February 14-16\, 2005\, Editors:\nPeter M. A. Sloot\, Alfons G. Hoekstra\, Thierry Priol\, Alexander Reinefeld\, Marian\nBubak\, ISBN: 3-540-26918-5\, Lecture Notes in Computer Science\, Springer-Verlag GmbH\,\nVolume 3470 / 2005\, page 1002.\n\n [17]:: Jonas L indemann\, Goran Sandberg\, An Extendable GRID Application Portal\,\nAdvan ces in Grid Computing - EGC 2005\, European Grid Conference\, Amsterdam\, The\nNetherlands\, February 14-16\, 2005\, Editors: Peter M. A. Sloot\, Al fons G. Hoekstra\,\nThierry Priol\, Alexander Reinefeld\, Marian Bubak\, I SBN: 3-540-26918-5\, Lecture Notes\nin Computer Science\, Springer-Verlag GmbH\, Volume 3470 / 2005\, page 1012.\n\n [18}:: Fei Wu\, K.W. Ng\, A Loo sely Coupled Application Model for Grids\, Advances in\nGrid Computing - E GC 2005\, European Grid Conference\, Amsterdam\, The Netherlands\,\nFebrua ry 14-16\, 2005\, Editors: Peter M. A. Sloot\, Alfons G. Hoekstra\, Thierr y Priol\,\nAlexander Reinefeld\, Marian Bubak \, ISBN: 3-540-26918-5\, Lec ture Notes in Computer\nScience\, Springer-Verlag GmbH\, Volume 3470 / 200 5\, page 1056\n\n [19]:: Syed Naqvi\, Michel Riguidel\, Threat Model for G rid Security Services\,\nAdvances in Grid Computing - EGC 2005\, European Grid Conference\, Amsterdam\, The\nNetherlands\, February 14-16\, 2005\, E ditors: Peter M. A. Sloot\, Alfons G. Hoekstra\,\nThierry Priol\, Alexande r Reinefeld\, Marian Bubak \, ISBN: 3-540-26918-5\, Lecture Notes\nin Comp uter Science\, Springer-Verlag GmbH\, Volume 3470 / 2005\, page 1048\n\n [ 20]:: Soha Maad\, Brian Coghlan\, Geoff Quigley\, John Ryan\, Eamonn Kenny \, David\nO'Callaghan\, Towards a Complete Grid Filesystem Functionality\, submitted to special\nissue on Data Analysis\, Access and Management on G rids\, CALL FOR PAPERS \, Future\nGeneration Computer Systems\, The Intern ational Journal of Grid Computing: Theory\,\nMethods and Applications\, El sevier.\n\n [21]:: EU FP6 Project 031857: int.eu.grid\, to start May\, 200 6.\n\n [22]:: Genius Portal\, https://genius.ct.infn.it/\n\n [23]:: Marian Bubak\, Michal Turala\, CrossGrid and Its Relatives in Europe\, Proc.9th\ nEuropean PVM/MPI Users Group Meeting\, LNCS\, pp.14-15\, Vol.2474\, ISBN: 3-540-44296-0\,\nSpringer-Verlag\, 2002.\n\n [24]:: M.Kupczyk\, R.Lichwal a\, N.Meyer\, B.Palak\, M.Plociennik\, P.Wolniewicz\,\nApplications on Dem and as the exploitation of the Migrating Desktop\, Future\nGeneration Comp uter Systems\, pp.37-44\, Vol.21\, Issue 1\, ISSN: 0167-739X\, January 200 5.\n\n [25]:: EU FP6 Project: Enabling Grids For E-sciencE\, http://www.eu -egee.org/ \n\n [26]:: Globus Project\, http://globus.org\n\n [27]:: GridP P Project\, http://www.gridpp.ac.uk/\n\n [28]:: Global Grid Forum (GGF)\, http://www.ggf.org/\n\nhttp://indico.cern.ch/contributionDisplay.py?contri bId=85&sessionId=17&confId=286 LOCATION:CERN 40-S2-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=85&sessionId=17 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Experience integrating new applications in EGEE DTSTART;VALUE=DATE-TIME:20060301T110500Z DTEND;VALUE=DATE-TIME:20060301T115000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-3@cern.ch DESCRIPTION:Speakers: BARBERA\, Roberto (University of Catania and INFN)\n  \n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=3&sessionId=8 &confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=3&sessionId=8&c onfId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Discussion DTSTART;VALUE=DATE-TIME:20060302T142000Z DTEND;VALUE=DATE-TIME:20060302T150000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-108@cern.ch DESCRIPTION:Speakers: \nDiscussion on metadata catalogues\n\nhttp://indico .cern.ch/contributionDisplay.py?contribId=108&sessionId=13&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=108&sessionId=1 3&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Discussion DTSTART;VALUE=DATE-TIME:20060302T162500Z DTEND;VALUE=DATE-TIME:20060302T164000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-109@cern.ch DESCRIPTION:Speakers: \nDiscussion on grid data management\n\nhttp://indic o.cern.ch/contributionDisplay.py?contribId=109&sessionId=13&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=109&sessionId=1 3&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:CMS Dashboard of Grid Activity DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-102@cern.ch DESCRIPTION:Speakers: Mr. HERRALA\, Juha (CERN)\nThe CMS Dashboard project aims to provide a single entry point to the monitoring data\ncollected fr om the CMS distributed computing system. The monitoring information\ncolle cted in the CMS dashboard allows to follow the processing of the CMS jobs on the\nLCG\, EGEE and OSG grid infrastructures. The Dashboard supports tr acing of the job\nexecution failures on the Grid and erros due to problems with the experiment-specific\napplications. In addition the Dashboard is able to present an estimation of the I/O\nrates between the worker nodes a nd data storage and helps keeping record of the\nsharing of the resources between production and analysis groups and different users.\n One of the f inal goals is to discover inefficiencies in the data distribution and\npro blems in the data publishing.\n\nThe Dashboard data base combines the Grid -specific data from the Logging and\nBook-keeping system via RGMA and the CMS-specific data via Monalisa monitoring\nsystem. Web interface to the da shboard data base provides access to the monitoring\ndata in the interacti ve mode and through the set of the predefined views. The\ninteractive mode enables the possibility to get information in a detailed level\,\nwhich i s very important for tracking of various problems.\n\nhttp://indico.cern.c h/contributionDisplay.py?contribId=102&sessionId=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=102&sessionId=2 2&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:ETICS: eInfrastructure for Testing\, Integration and Configuration of Software DTSTART;VALUE=DATE-TIME:20060302T155000Z DTEND;VALUE=DATE-TIME:20060302T160500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-103@cern.ch DESCRIPTION:Speakers: \nA broad range of projects from a spectrum of disci plines involve the development of \nsoftware born from the collaborative e fforts of partners from geographically spread \nlocations. Such software i s often the product of large-scale initiatives as new \ntechnological mode ls like the Grid are developed and new e-Infrastructures are \ndeployed to help solve complex\, computational-intensive problems. \n\nRecent experie nce in such projects has shown that the software products often risk \nsuf fering from lack of coherence and quality. Among the causes of this proble m we \nfind the large variety of tools\, languages\, platforms\, processes and working habits \nemployed by the partners of the projects. In additio n\, the issue of available \nfunding for maintenance and support of softwa re after the initial development phase \nin typical research projects ofte n prevents the developed software tools from \nreaching production-level q uality. Establishing a dedicated build and test \ninfrastructure for each new project is inefficient\, costly and time-consuming and \nrequires spec ialized resources\, both human and material\, that are not easily found. \ n\nThe ETICS effort aims to support such research and development initiati ves by \nintegrating existing procedures\, tools and resources in a cohere nt infrastructure\, \nadditionally providing an intuitive access point thr ough a web portal and a \nprofessionally managed\, multiplatform capabilit y based on Grid technologies. The \noutcome of the project will be a facil ity operated by experts that will enabled \ndistributed research projects to integrate their code\, libraries and application\, \nvalidate the code against standard guidelines\, run extensive automated tests and \nbenchmar ks\, produce reports and improve the overall quality and interoperability of \nthe software. \n\nETICS objectives are not to develop new software bu t to adapt and integrate already \nexisting capabilities\, mainly open sou rce\, providing other research project with \nthe possibility to focus the ir effort in their specific research field and to avoid \nwasting time and resources in such\, required\, but expensive\, activity. \n\nThroughout t he duration of the project the ETICS partners will investigate the \nadvan tages of making use of the ETICS services\, the technical challenges relat es to \nrunning such a facility and its sustainability for the future.\n\n The vision and mission of ETICS will be accomplished through the following \nobjectives:\n\n• Establish an international and well managed capabili ty for software \nconfiguration\, integration\, testing and benchmarking f or the scientific community. \nSoftware development projects will use the capabilities provided by ETICS to build \nand integrate their software and perform complex distributed test and validation \ntasks\n• Deploy and i f necessary adapt best-of-breed software engineering tools and \nsupport i nfrastructures developed by other projects (EGEE\, LCG\, NMI) and other op en-\nsource or industrial entities and organize them in a coherent\, easy- to-use set of \non-line tools\n• Create a repository of libraries that p roject can readily link against to \nvalidate their software in different configurations conditions\n• Leverage a distributed infrastructure of co mpute and storage resource to \nsupport the software integration and testi ng activities of a broad range of \nsoftware development efforts. \n• Co llect\, organize and publish middleware and applications configuration \ni nformation to facilitate interoperability analysis at the early stages of \ndevelopment and implementation\n• Collect from the scientific communit y sets of test suites that users can \napply to validate deployed middlewa re and applications and conversely software \nproviders can use to validat e their products for specific uses\n• Raise awareness of the need for hi gh-quality standards in the production of \nsoftware and promote the ident ification of common quality guidelines and principles \nand their applicat ion to software production in open-source academic and research \norganiza tion. Study the feasibility of a “Quality Certification” for software \nproduced by research projects\n• Promote the international collaborati on between research projects and \nestablish a virtual community in the fi eld of software engineering contributing to \nthe development of standards and advancement in the art\n\nFrom the perspective of Grid application de velopers\, the ETICS service should \nprovide them with the means to autom ate their build and test procedures. In the \nlonger term\, via the ETICS service\, users will be able to explore meaningful \nmetrics pertaining t o the quality of their software. Further\, as Grid application \nlevel se rvices (most concerned by providers of Grid turn key solutions)\, the ETIC S \nservice will also offer a repository or already built components\, ser vices and plug-\nins\, with a published quality level. Furthermore\, the quality metrics provided by \nthe ETICS services and available for each ar tifact in the repository will help \nguiding the user in selecting reliabl e software dependencies. Finally\, the \nrepository will also contain pre -build artifacts for specific hardware platforms \nand operating systems\, which will help the developers to assess the platform \nindependence of t heir entire service\, including each and every dependency the \nservice is relying on.\n\nIn conclusion\, most Grid and distributed software project invest in a build and \ntest system in order to automatically build and t est their software and monitor key \nquality indicators. ETICS takes requ irements from many Grid and distributed \nprojects and with the help of Gr id middleware\, offers a generic yet powerful \nsolution for building and testing software. Finally\, building software via such a \nsystematic can provide a rich pool of published quality components\, services and \nplug -ins\, on which the next generation of Grid and distributed applications c ould \nbe based on and composed of.\n\nhttp://indico.cern.ch/contributionD isplay.py?contribId=103&sessionId=17&confId=286 LOCATION:CERN 40-S2-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=103&sessionId=1 7&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Efficient job handling in the GRID: short deadline\, interactivity \, fault tolerance and parallelism DTSTART;VALUE=DATE-TIME:20060302T143000Z DTEND;VALUE=DATE-TIME:20060302T150000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-100@cern.ch DESCRIPTION:Speakers: Mr. MOSCICKI\, Jakub (CERN)\nThe major GRID infastru ctures are designed mainly for batch-oriented\ncomputing with coarse-grain ed jobs and relatively high job turnaround\ntime. However many practical a pplications in natural and physical\nsciences may be easily parallelized a nd run as a set of smaller tasks\nwhich require little or no synchronizati on and which may be scheduled in\na more efficient way. The Distributed An alysis Environment Framework\n(DIANE)\, is a Master-Worker execution skele ton for applications\, which\ncomplements the GRID middleware stack. Autom atic failure recovery and\ntask dispatching policies enable an easy custom ization of the behaviour\nof the framework in a dynamic and non-reliable c omputing environment. We\ndemonstrate the experience of using the framewor k with several diverse\nreal-life applications\, including Monte Carlo Sim ulation\, Physics\nData Analysis and Biotechnology. \n\nThe interfacing of existing sequential applications from the point of\nview of non-expert us er is made easy\, also for legacy applications. We\nanalyze the runtime ef ficiency and load balancing of the parallel tasks\nin various configuratio ns and diverse computing environments: GRIDs (LCG\, Crossgrid)\,\nbatch fa rms and dedicated clusters. In practice\, the usage of ther\nMaster/Worker layer allows to dramatically reduce the job turnaround\ntime\, a scenario suitable for short deadline jobs and interactive data\nanalysis.\n\nFinal ly it is also possible to easily introduce more complex\nsynchronization p atterns\, beyond trivial parallelism\, such as arbitrary\ndependency graph s (including cycles\, in contrast to DAGs) which may be\nsuitable for bio- informatics applications.\n\nhttp://indico.cern.ch/contributionDisplay.py? contribId=100&sessionId=16&confId=286 LOCATION:CERN 40-4-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=100&sessionId=1 6&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:User and virtual organisation support in EGEE DTSTART;VALUE=DATE-TIME:20060302T132500Z DTEND;VALUE=DATE-TIME:20060302T134500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-101@cern.ch DESCRIPTION:Speakers: DONNO\, Flavia (CERN)\nUser and virtual organisation support in EGEE\nProviding adequate user support in a grid environment is a very challenging task \ndue to the distributed nature of the grid. The variety of users and the variety of \nVirtual Organizations (VO) with a w ide range of applications in use add further to \nthe challenge.\nThe peop le asking for support are of various kinds. They can be generic grid \nbe ginners\, users belonging to a given Virtual Organization and dealing with a \nspecific set of applications\, site administrators operating grid ser vices and local \ncomputing infrastructures\, grid monitoring operators wh o check the status of the \ngrid and need to contact the specific site to report problems\; to this list can be \nadded network specialists and othe rs.\nWherever a user is located and whatever the problem experienced is\, a user expects \nfrom a support infrastructure a given set of services. A non-exhaustive list is \nthe following:\na) a single access point for sup port\;\nb) a portal with a well structured sources of information and upda ted \ndocumentation concerning the VO or the set of services involved\;\nc ) experts knowledgeable of the particular application in use and who can e ven \ndiscuss with the user to better understand what he/she is trying to achieve (hot-\nline)\; help integrating user applications with the grid mi ddleware\;\nd) correct\, complete and responsive support\;\ne) tools to he lp resolve problems (search engines\, monitoring applications\, \nresource s status\, etc.)\;\nf) examples\, templates\, specific distributions for s oftware of interest\;\ng) integrated interface with other Grid infrastruct ure support systems\;\nh) connection with the grid developers and the depl oyment and operation teams\;\ni) assistance during production use of the g rid infrastructure.\nWith the Global Grid User Support (GGUS) infrastructu re\, EGEE attempts to meet all \nof these expectations. The current use o f the system and the user satisfaction \nratings have shown that the goal has been achieved with a certain success for the \nmoment.\nAs of today GG US has shown to be able to process up to 200 requests per day and \nprovid es all above listed services. In what follows we discuss the organization of \nthe GGUS system\, how it meets the users’ needs\, and the current open issues.\nThe model of the existing EGEE Global Grid User Support (GGU S) is as follows. The \nsupport model in EGEE can be captioned "regional support with central \ncoordination". Users can submit a support request to the central GGUS service\, or \nto their Regional Operations' Center (R OC) or to their Virtual Organisation (VO) \nhelpdesks.\nWithin GGUS there is an internal support structure for all support requests. The \nROCs and VOs and the other project wide groups such as middleware groups (JRA)\, \ nnetwork groups (NA)\, service groups (SA) and other grid infrastructures (OSG\, \nNorduGrid\, etc.) are connected via a central integration platfor m provided by GGUS.\nGGUS central helpdesk also acts as a portal for all u sers who do not know where to \nsend their requests. They can enter them directly into the GGUS system via a web \nform or e-mail.\nThis central he lpdesk keeps track of all service requests and assigns them to the \nappro priate support groups. In this way\, formal communication between all sup port \ngroups is possible. To enable this\, each group has built an inter face (e-mail and \nweb front-end\, or interface between ticketing systems) between its internal support \nstructure and the central GGUS application .\nIn the central GGUS system\, first line support experts from the ROCs a nd the \nVirtual Organizations will do the initial problem analysis. Supp ort is widely \ndistributed. These experts are called Ticket Processing M anagers (TPM) for generic \nfirst line support (generic TPM) and for VO sp ecific first line support (VO TPM). \nThese experts can either provide th e solution to the problem reported or escalate \nit to more specialized su pport unit that provide network\, middleware and grid \nservice support. They may also refer it to specific ROCs or VO experts.\nBehind the special ized VO TPM support units\, people belonging to EGEE/NA4 groups \nsuch as the Experiment Integration Support group (EIS) help VO users with on-line \nsupport and the integration of the VO specific applications with the gri d \nmiddleware. Such people can also recognize if a problem is applicatio n specific \nand forward the problem to more VO specific support units con nected to GGUS.\nTPM and VO TPMs have also the duty of following tickets\, making sure that users \nreceive an adequate answer\, coordinating the ef fort of understanding the real \nnature of the problem and involving more than one second level support unit if \nneeded. The following figure depi cts the ticket flow.\nTo provide appropriate user support\, the distribute d structure of EGEE and the VOs \nhas to be taken into account. The commu nity of supporters is therefore \ndistributed. Their effort is coordinate d centrally by GGUS and locally by the \nlocal ROC support infrastructures .\nThe ROC provides adequate support to classify the problems and to resol ve them if \npossible. Each ROC has named user support contacts who manag e the support inside \nthe ROC and who coordinate with the other ROCs’ s upport contacts. The \nclassification at this level distinguishes between operational problems\, \nconfiguration problems\, violations of service a greements\, problems that originate \nfrom the resource centres and proble ms that originate from global services or from \ninternal problems in the software. Problems that are positively linked to a \nresource centre are then transferred to the responsibility of the ROC with which \nthe RC is a ssociated.\nMEETING USER NEEDS\nAs explained above\, GGUS provides therefo re a single entry point for reporting \nproblems and dealing with the grid . In collaboration with the EGEE EIS team\, the \nEGEE User Information G roup\, NA3\, and the entire EGEE infrastructure\, GGUS offers a \nportal w here users can find up-to-date documentation\, and powerful search engines \nto find answers to resolved problems and examples. Common solutions ar e stored in \nthe GGUS knowledge database and Wiki pages are compiled for frequent or \nundocumented problems/features.\nGGUS offers hot lines for u sers and supporters and a VRVS chat room to make the \nentire support infr astructure available on-line to users.\nSpecial tools and grid middleware distributions are made available by the NA4/EIS \nteam for GGUS users.\nGG US is interfaced with other grids’ support infrastructures such as in th e case of \nOSG and NorduGrid. Also\, GGUS is used for daily operations t o monitor the grid and \nkeep it healthy. Therefore\, specific user probl ems can be directly communicated to \nthe Grid Operation Centers and broad casted to the entire grid community.\nGGUS is used also to follow and trac k down problems during stress testing \nactivities such as the HEP experim ents production data challenges and the service \nchallenges.\nOPEN ISSUES \nEven-though GGUS has proven to provide useful services\, there are still many things \nthat need improvement. Concerning users and VOs\, in parti cular\, we have identified \nthe following:\nSmall VOs do not have the res ources to implement their part of the model\nThe large VOs such as the LHC experiments have people who provide support for the \napplications which the VO has to run as part of its work. These people are \ncontacted by GG US when tickets are assigned to the VO or then the problem needs \nimmedia te or on-line attention. It has proven difficult for some of the small VO s \nto provide such a service. In this case\, GGUS still provides support for the VO\, \nbut if the problem is application related and cannot be re solved\, then it has to be \nput into the state ‘unsolvable’.\nSupport ers have other jobs to do\nIn EGEE\, almost everyone providing support doe s so as part of their job. It is not \nusually a major part of their job. Some times it is difficult to ensure \nresponsiveness. There is a small team which maintains and develops the GGUS system.\nSupporters are concen trated in a few locations\nThe resources of the grid are widely distribute d over 180 locations\, and there are \npeople in all of these locations lo oking after the basic operation of the \ncomputers. However this is not t he case for higher level support such as support \nfor a VO application. This tends to exist in only a small number of locations\, \nwith a small n umber of supporters.\nScalability is constrained by the availability of su pporters\nThe number of people who can provide support for basic operation s is large\, but the \nnumber of people who can provide support for higher level services is small. As \nthe VOs become larger this will become a c onstraint to growth unless more \nsupporters are found.\nLimited experienc e in handling a large number of tickets\nAs part of the development of the GGUS system\, it has been exercised by generating \ntickets. As the syst em is built from industry standard software parts using Remedy \nand Oracl e\, it has been found to be reliable. We believe however that if large \n numbers of tickets are submitted that it will show the limitations in the system.\nLimited engagement of existing VOs in the implementation of GGUS\ nThere is an organisation within EGEE called Executive Support Committee ( ESC). The \nESC has representatives from all of the ROCs of EGEE. This o rganisation meets once \nper month by telephone to discuss the operations and development of the support \nsystem and to decide on actions and prior ities for the work. The present VOs have \nfound it difficult to provide people for involvement with this work.\nCONCLUSION\nThe GGUS system is now ready for duty. During 2006\, it is expected that there will \nbe a larg e number of tickets passing through the system as the LHC VOs move from \n preparing for service to being in production. It is also expected that th e number \nof Virtual Organisations will grow as the work of EGEE-II proce eds. There will \nalso be an increase in the number of support units invo lved with GGUS\, and an \nincrease in the number of ROCs and RCs.\nAcronym s\nEGEE Enabling Grids for E-sciencE\nEIS Experiment Integration Su pport\nGGUS Global Grid User Support\nHEP High Energy Physics\nJRA Joint Research Activity of EGEE\nLHC Large Hadron Collider\nNA Network Activity\nOSG Open Science Grid\nRC Resource Centre\nRO C Regional Operations' Centre\nSA Service Activity\nTPM Ticke t Process Management\nVO Virtual Organisation\nVRVS Virtual Rooms Videoconferencing System\nWiki Web technology for collaborative working \n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=101&sessionId=1 7&confId=286 LOCATION:CERN 40-S2-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=101&sessionId=1 7&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:An efficient method for fine-grained access authorization in dis tributed (Grid) storage systems DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-106@cern.ch DESCRIPTION:Speakers: PETERS\, Andreas (CERN)\n  The ARDA group has devel oped an efficient method for fine-grained access \nauthorization in dist ributed (Grid) storage systems. Client applications \nobtain "access toke ns" from an organization's file catalogue upon execution of a \nfile name resolution request. Whenever a client application tries to access the \n requested files\, the token is transparently passed to the target storage system. \nThus the storage service can decide on the authorization of a request without \nitself having to contact the authorization service. \n T he token is protected from access and modification by external parties us ing \npublic key infrastructure. We use GSI authentication for identifica tion to the \ncatalogue service and to storage I/O daemons. The authoriza tion system is as \nsecure as GSI authentication and public key infrastru cture can be. To improve the \nperformance for the catalogue interaction\, we use GSI authenticated sessions \nbetween client and server: after an initial full GSI authentication we encrypt \nevery interaction between cl ient and server with a dynamic symmetric key and \nachieve a 20 times fas ter performance.\n\n The main information inside an authorization envelop e are the TURL to be used by \nI/O daemons\, the permissions on that TUR L\, which are 'read'\,'write'\,'write-once' \nand 'delete'\, the lifetime of that token\, the certificate subject and the storage \nsystem name fo r which this token was issued. One token can contain the \nauthorization for a group of files. \n\n Traditional approaches use proxy->uid mapping s ervices to apply local filesystem \npermissions. In a direct comparison a n access token is equivalent to a VOMS proxy \ncertificate who's proxy ex tensions authorize access to only one file or a group of \nfiles. However VOMS is not the appropriate system to perform authorization on file \nle vel since the issue time for such an envelope is very critical (in our \n implementation only few ms per access) and the VOMS integration\, a VOMS server \nwould need to be directly connected to the used file catalogues .\n\n Our method is well applicable in situations\, where every GRID user needs to have \nthe possibility to declare a file as private to him. \n T he same would require in the traditional approach already one worldwide \ nconfigured UID per VO member\, which is very difficult to maintain if not \nimpossible. In our implementation user roles and groups are completely virtualized \nthrough definitions in a file catalogue and do not need t he one to one \ncorrespondence of roles and groups in storage systems.\n I n the future virtual machines might be the solution for a virtual user co ncept\, \nbut they are still far from deployment in the present Grid infr astructure. \nPermissions in the catalogue must be attached to file GUIDs and the catalogue must \nmake sure\, that every GUID can be registered o nly once!\n \n A well performing prototype using the AliEn Grid file catal ogue and xrootd as a \ndata server has been implemented. The integration of other catalogue or I/O \ndaemons would be simple. The catalogue servic e itself can run different file \ncatalogue plug-ins. The token is moved as part of a file URL\, i.e. no I/O protocol \nchanges are needed. I/O da emons need one modification in the 'open' command to \ndecrypt the author ization envelope\, reject access or replace the initial TURL \npassed to the open command with the TURL quoted in the envelope. This \nfunctionali ty is encapsulated in a C++ shared library\, which allows to define \nad ditional authorization rules for certain VOs\, certificates or TURL paths .\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=106&sessionId= 22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=106&sessionId=2 2&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Grid-Enabled Remote Instrumentation with Distributed Control and C omputation DTSTART;VALUE=DATE-TIME:20060302T140000Z DTEND;VALUE=DATE-TIME:20060302T143000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-107@cern.ch DESCRIPTION:Speakers: DICKENS\, Luke (Imperial College)\n1 GRIDCC Applicat ions and Requirements\n\nThe GRIDCC project [1]\, sponsored by the Europea n Union under contract number \n511381\, and launched in September 2004\, endeavors to integrate scientific and \ngeneral-purpose instruments within the Grid. The motivation is to exploit the Grid \nopportunities for secur e\, collaborative work of distributed teams and to utilize \nthe Grid’s massive memory and computing resources for the storage and processing of \ ndata generated by scientific equipment. The GRIDCC project focuses its at tention on \neight applications\, four of which will be fully integrated\, tested and deployed on \nthe Grid.\nThe PowerGrid will support the remote monitoring and control of thousands of small \npower generators\; while t he Control and Monitoring of HEP experimentsaims to enable \nremote contro l and monitoring of the CMS detector at CERN. The (Far) Remote \nOperation of Accelerator Facility is an application for the full operation of a \n remote accelerator in Trieste\, Italy\; and the Grid-based Intrusion Detec tion System \naims to provide detection and trace-back of flow-based DoS a ttacks using aggregated \ndata collected from multiple routers. The other set of relevant applications \nincludes: meteorology\, neurophysiology\, h andling of device farms for measurements \nin telecommunications laborator ies\, and geophysiology [2][5]. \nThe project\, by nature\, requires the a vailability of software components that allow \nfor time-bounded and secur e interactions\, while operating instrumentation in a \ncollaborative envi ronment. In addition to the classical request/response Grid \nservice inte raction model\, a considerable amount of information needs to be \nstreame d from the instrument back to the user. The time-bounded interactions\, \n dictated either by the instrument sensitivity and the accompanying require ment for \ncareful handling and fast response to extreme conditions\, or b y the applications \nthemselves\, lead to the need for the establishment o f SLAs for QoS or other \nguarantees\, with support for compensation and r ollback. The idea of collaboration \nand resource sharing\, inherent in th e Grid\, is also extended and adapted to allow \nthe share of unique instr uments among users who are geographically dispersed\, and \nwho normally w ould not have access to such – usually rare and/or expensive – \nequip ment.\n\n2 GRIDCC and gLite\n\nTo cater for the diversity of instruments a nd the critical nature of the equipment \nbeing handled\, the GRIDCC middl eware platform relies on Web Service (WS) \ntechnologies\, and sustains a Service Level Agreement (SLA) infrastructure\, \nalongside enforcement of Quality of Service (QoS) guarantees. The GRIDCC middleware \narchitecture is fully described in [2].\nA number of gLite software components are extr emely relevant to the GRIDCC \nmiddleware architecture\, which is designed to comprise various novel middleware \ncomponents to complement them. Fir stly\, we plan to perform job scheduling and \nbookkeping via the WMS and specifically the WMProxy\, and the LBProxy [2]. We also \nplan to rely on the Agreement Service for SLA signalling and for triggering \nresource-lev el reservations [2]– this is essential to enforce SLA guarantees. In \na ddition\, we plan to test and possibly extend CREAM\, as explained in the following \nSection. \nThe WSDL interface\, exposed by the gLite WMS\, str eamlines job submission in a \nnumber of different scenarios: direct invoc ation by the Virtual Control Room (VCR) -\n the GRIDCC portal\; direct sub mission onto preselected CEs via the GRIDCC Workflow \nManagement System ( WfMS)\; and indirectly\, utilising the WMS’s builtin scheduling \ncapabi lities\, either as a single submission or part of a workflow [2]. The WfMS and \nVCR are described in more detail in Section 3.\nData gathered from IEs need to be stored\, in MSS sevices. Consequently\, data \nstorage will be delegated to gLite SEs exposing SRM-compliant interfaces.\nVOMS and pr oxy-renewal services will be used. For authentication and authorization\, \nit is foreseen to support both X.509 certificates and the Kerberos frame work. The \nlatter will be used when low response times are required. \nFi nally\, for QoS performance monitoring\, as it is experienced by GRIDCC us ers and \nservices\, we require the integration of service monitoring tool s and services \nproviding information about network performance\, such as the gLite Network \nperformance Monitoring framework.\n\n3 GRIDCC Middlew are\n\nThe gap between GRIDCC’s requirements and gLite’s existing serv ice support\, will be \nfilled by a number of GRIDCC solutions\, which lev erage the existing gLite \nfunctionality.\nThe need for instrument support \, necessitated the development of a new grid \ncomponent\, the Instrument Element (IE). The IE’s naming and design reflect its \nsimilarity to gL ite’s SE and CE. The IE provides a Grid interface to a physical \ninstru ment or set of instruments\, and should allow the user to control and acce ss \ninstrument data [2]. To cater for the varied needs of instrumentation \, the IE also \nhas local automated management and storage capacity [2].\ nThe desire for QoS and SLA support is provided for by the following Execu tion \nService components. The gLite AS will be extended to establish SLAs with the IE\, \nand the IE will need to enforce such SLAs. To achieve thi s\, the IE conceptual model \nand schema need to be defined in order to pu blish information about the instrument-\nspecific properties. \nThe GRIDCC Workflow Management System (WfMS) provides an interface for users to \nsu bmit workflows\, which can orchestrate WS calls to underlying services [3] . The \nWfMS may also need to choreograph further steps into workflows\, s uch as the SLA \nnegotiation and logging steps\, to facilitate the satisfa ction of\, possibly complex\, \nQoS demands from the user [3]. It is also responsible for monitoring running \nworkflows and responding to workflow events - such as contacting a user if QoS \ndemands can no longer be satis fied [2]. \nThe Virtual Control Room (VCR)\, supports a user Grid portal f or the underlying \nservices\, in particular to: request SLAs from the AS\ ; steer and monitor an IE\; and \nsubmit workflows to the WfMS [2][3][4]. Additionally\, the VCR provides a multi-user \ncollaborative online enviro nment\, wherein remote users and support staff\, share \ncontrol of and tr oubleshoot IEs [2][4].\n\n4 Extending gLite\n\nTo fulfill the GRIDCC appli cation requirements\, a number of gLite functionality \nextensions would b e useful for successful middleware integration. Firstly\, \ninformation ab out IEs needs to be made available by the information services. \nSecondly \, in order to enforce upper-bounded execution times\, the reservation of CEs \nand IEs needs to be supported. To this end\, we will extend the AS\, by adding CE and \nIE-specific SLA templates. Reservation needs to be tri ggered and enforced by \nelements at the fabric-layer. For this reason\, w e envisage the addition of a new \noperation to the WSDL interface exposed by CREAM\, allowing the invocation of \nreservation operations. As mentio ned above\, GRIDCC\, needs for QoS to be enforced \nat both the single-ta sk and workflow level. The WMS already supports some workflow \nfunctional ity\; however\, the WMS can only process workflows involving job execution \ntasks. We foresee the need to merge the functionality of the GRIDCC WfM S with the \ngLite WMS\, to benefit from the existing WMS capabilities and avoid duplication of \nwork.\n\nReferences\n[1] The GRIDCC Project home p age: http://www.gridcc.org.\n[2] The GRIDCC Architecture – Architecture of Services for a Grid Enabled \nRemote Instrument Infrastructure (http:// www.gridcc.org/getfile.php?id=1382).\n[3] D4.1 Basic Release R1\, GRIDCC P roject Deliverable GRIDCC-D4.1\, May 2005 \n(https://ulisse.elettra.triest e.it/tutos_gridcc/php/file/file_show.php?id=1418)\n[4] Multipurpose Colla borative Environment\, GRIDCC Project Deliverable GRIDCC-\nD5_2\, Sept 20 05 \n(https://ulisse.elettra.trieste.it/tutos_gridcc/php/file/file_show.ph p?id=1408)\n[5] SPECIFIC TARGETED RESEARCH OR INNOVATION PROJECT – Annex I - “Description \nof Work”\, May 2004 (http://www.gridcc.org)\n[6] EGEE Middleware Architecture and planning\, EGEE Project\, Deliverable EG EE-\nDJRA1.1-594698-v1.0\, Jul 2005 (https://edms.cern.ch/document/594698/ ).\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=107&sessionId =16&confId=286 LOCATION:CERN 40-4-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=107&sessionId=1 6&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:On the development of a grid enabled a priori molecular simulator DTSTART;VALUE=DATE-TIME:20060301T144500Z DTEND;VALUE=DATE-TIME:20060301T150000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-104@cern.ch DESCRIPTION:Speakers: LAGANA`\, Antonio (1Department of Chemistry\, Univer sity of Perugia)\nWe have implemented on the production grid of EGEE GEMS. 0\, a demo version\nof our Molecular processes simulator that deals with g as phase atom diatom \nbimolecular\nreactions. GEMS.0 takes the parameters of the potential from a data bank\nand carries out the dynamical calculat ions by running quasiclassical trajectories \n[1].\nA generalization of GE MS.0 to include the calculation of ab initio potentials and\nthe use of qu antum dynamics is under way with the collaboration of the members\nof COMP CHEM [2]. In this communication we report on the implementation of\nquantu m dynamics procedures.\nQuantum approaches require the integration of the Schroedinger equation to calculate\nthe scattering matrix SJ (E). The inte gration of the Schroedinger equation\ncan be carried out using either time dependent or time independent techniques.\nThe structure of the computer code performing the propagation in time of the\nwavepacket (TIDEP)[3] for the Ncond sets of initial conditions is sketched in Fig. \n1.\n\n \n Read input data: tfin\, tstep\, system data ...\n Do icond = 1\,Ncond\n Read initial conditions: v\, j\, Etr\, J ...\n Perform preliminary and first step calculations\n Do t = to\, tf in\, tstep\n Perform the time step propagation\n Perfo rm the asymptotic analysis to update S\n Check for convergence o f the results\n EndDo t\n EndDo icond\n\n Fig. 1. Pse udocode of the TIDEP wavepacket program kernel.\n\n\nThe TIDEP kernel show s strict similarities with that of the trajectory one \n(ABCtraj) \nalread y implemented in GEMS.0. In fact\, for a given set of initial conditions\, \nthe inner loop of TIDEP propagates recursively over time the wavepacket. The most\nnoticeable difference between this and the trajectory integrati on is the fact that \nat\neach time step TIDEP performs a large number of matrix operations which increase\nmemory and computing time requests of so me orders of magnitude.\nThe structure of the time independent suite of co des [4] is\, instead\, articulated in\na different way. It is in fact made of a first block (ABM) [4] that generates the \nlocal\nbasis set and buil ds the coupling matrix (the integration bed) using also the basis\nset of the previous sector. This calculation has been decoupled by repeating for \neach\nsector the calculation of the basis set of the previous one (see F ig. 2). This \nallows\nto distribute the calculations on the grid. The sec ond block is concerned with the\npropagation of the solution R matrix from small to large values of the hyperradius\nperformed by the program LOGDER [4]. For this block\, again\, the same scheme\nof ABCtraj can be adopted to distribute the propagation of the R matrix at given\nvalues of E and J as shown in Fig. 3.\n\n\n Read input data: in\, fin\, step\, J\, E max\, ...\n Perform preliminary calculations\n Do (rho) = (rho)in + (rho)step\, (rho)fin\, (rho)step\n Calculate eigenv alues and surface functions for present and previous \n(rho) \n Build intersector mapping and intrasector coupling matrices\n\n EndDo (rho)\n\n Fig. 2. Pseudocode of the ABM program kernel .\n\n\n\n Read input data: in\, fin\, step\, ...\n Tra nsfer the coupling matrices generated by ABM from disk\n Do icon d = 1\,Ncond\n Read input data: J\, E ...\n Perf orm preliminary calculations\n Do (rho) = (rho)in\, (rho)f in\, (rho)step\n Perform the single sector propagation of the R matrix\n EndDo (rho) \n EndDo icond\n\n Fig. 3. Pseudocode of the LOGDER program kernel.\n\n\nReferenc es\n\n1. Gervasi\, O.\, Dittamo\, C.\, Lagana'\, A.: Lecture Notes in Comp uter Science 3470\, \n16-22 (2005).\n2. EGEE-COMPCHEM Memorandum of unders tanding\, March 2005\n3. Gregori\, S.\, Tasso\, S.\, Lagana'\, A: Lecture Notes in Computer Science 3044\, 437-\n444 (2004).\n4. Bolloni\, A.\, Croc chianti\, S.\, Lagana'\, A.: Lecture Notes in Computer Science \n1908\, 33 8-345 (2000).\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=10 4&sessionId=12&confId=286 LOCATION:CERN 40-4-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=104&sessionId=1 2&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:The Molecular Science challenges in EGEE DTSTART;VALUE=DATE-TIME:20060301T143000Z DTEND;VALUE=DATE-TIME:20060301T144500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-105@cern.ch DESCRIPTION:Speakers: GERVASI\, Osvaldo (Department of Mathematics and Com puter Science\, University of Perugia)\nThe understanding of the behavior of molecular systems is important for the\nprogress of life sciences and i ndustrial applications. In both cases is increasingly\nnecessary to perfor m a study of the relevant molecular systems by using simulations\nand comp utational procedures which heavily demand computational resources. In\nsom e of these studies it is mandatory to put together the resource and comple mentary\ncompetencies of various laboratories. The Grid is indeed the infr astructure\nthat allows such a cooperative modality of work. In particular for scientific \npurposes\nthe EGEE Grid is the proper environment. For t his reason a Virtual Organization\n(VO) called CompChem has been created w ithin EGEE. Its goal is to support the\ncomputational needs of the Chemist ry and Molecular Science community and pivot\nthe user access to the EGEE Grid facilities.\nUsing the simulator being implemented in CompChem the st udy of molecular\nsystems is carried out by adopting various computational approaches bearing \napproximations of different levels. \nThese computat ional approaches can be grouped into three categories:\n 1. Classical an d Quasiclassical: these are the less rigorous approaches. \n They are \, however\, the most popular. The main characteristic of these \n co mputational procedures is that the related computer codes are naturally \n parallel. They consist in fact of a set of independent tasks\, with few \n communications at the beginning and at the end of each task. \ n Related computational codes are suitable to exploit the power of th e Grid \n in terms of the high number of computing elements (CEs) ava ilable.\n 2. Semi-classical: these approaches introduce appropriate corr ections the \n deviations of quasiclassical estimates from quantum on es. The Grid \n infrastructure is exploited for massive calculations by varying the initial \n conditions of the simulation and performing the statistical analysis of the \n results.\n 3. Quantum: this is the most accurate computational approach heavily demanding\n in terms of computational and storage resources. Grid facilities and \nservices will be only seldomly able to support them in a proper way using \npres ent \n hardware and middleware utilities. Therefore they will represe nt a real \n challenge for Grid service development.\n\nThe computati onal codes presently used are mainly produced by the laboratories\nmember of the VO. However some popular commercial programs (DL POLY\, Venus\,\nMo lPro\, GAMESS\, Columbus\, etc) are also being implemented. These packages are\nat present executed only on the computing element (CE) owning the li cense. We are\nplanning to implement in the Resource Broker (RB) the mappi ng of the licensed\nsites via the Job Description Language (JDL). In this way the RB will be able to\nschedule properly the jobs requiring licensed software. The VO is implementing[1]\nan algorithm to reward each participa ting laboratory for contributions given to the\nVO providing hardware reso urces\, licensed software and specific competences.\nOne of the most advan ced activities we are carrying out in EGEE is the simulation\non the Grid of the ionic permeability of some cellular micropores. To this\nend we use molecular dynamics simulations to mimic the behavior of a solvated\nion w hen driven by an electronic field through a simple model of the channel. A s a\nmodel channel a carbon nanotube (CNT) was used as done in a recent mo lecular\ndynamics simulation of water filling and emptying of the interior of an open-end\ncarbon nanotube[3-6]. In this way we have been able to ca lculate the ionic \npermeability\nof several solvated ions (Na+\, Mg++\, K +\, Ca++\, Cs+) by counting the\nions forced to flow into the nanotube by the applied potential diffence along \nz-axis.\n\n\nReferences\n\n1. Lagan a'\, A.\, Riganelli\, A.\, and Gervasi\, O.: Towards Structuring Research \nLaboratories\nas Grid Services\; submitted (2006).\n\n2. Kalra\, A.\, Ga rde\, S.\, Hummer\, G.: Osmotic water transport through carbon nanotube\nm embranes. Proc Natl Acad Sci USA 100 (2003) 10175-10180.\n\n3. Berezhkovsk ii\, A.\, Hummer\, G.: Single-file transport of water molecules through a\ ncarbon nanotube. Phys Rev Lett 89 (2002) 064503.\n\n4. Mann\, D.J.\, Hall s\, M.D.: Water alignment and proton conduction inside carbon \nnanotubes. \nPhys Rev Lett 90 (2003) 195503.\n\n5. Zhu\, F.\, Schulten\, K.: Water an d proton conduction through carbon nanotubes as a\nmodels for biological c hannels. Biophys J 85 (2003) 236-244.\n\nhttp://indico.cern.ch/contributio nDisplay.py?contribId=105&sessionId=12&confId=286 LOCATION:CERN 40-4-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=105&sessionId=1 2&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Application of GRID resource for modeling charge transfer in DNA DTSTART;VALUE=DATE-TIME:20060301T140000Z DTEND;VALUE=DATE-TIME:20060301T141500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-39@cern.ch DESCRIPTION:Speakers: Ms. FIALKO\, Nadezhda (research fellow)\nRecently\, at the interface of physics\, chemistry and biology\, a new and rapidly \n developing research trend has emerged concerned with charge transfer in \n biomacromolecules. Of special interest to researchers is the electron and hole \ntransfer along a chain of base pairs\, since the migration of radic als over a DNA \nmolecule plays a crucial role in the processes of mutagen esis and carcinogenesis. \nMoreover\, understanding the mechanism of charg e transfer is necessary for the \ndevelopment of a new field\, concerned w ith charge transfer in organic conductors and \ntheir possible application in computing technology.\nTo use biomolecules as conductors\, one should know the rate of charge mobility.\nWe calculate theoretical values of char ge mobility on the basis of a quantum-\nclassical model of charge transfer in various synthesized polynucleotides at varying \ntemperature T of the environment. To take into account temperature fluctuations\, a \nrandom fo rce with specified statistical characteristics was added in the classical \nequations of site motion (Langevin force). (See e.g.: V.D.Lakhno\, N.S.F ialko. Hole \nmobility in a homogeneous nucleotide chain // JETP Letters\, 2003\, v.78 (5)\, pp.336-\n338\; V.D.Lakhno\, N.S.Fialko. Bloch oscillati ons in a homogeneous nucleotide chain // \nPisma v ZhETF\, 2004\, v.79 (10 )\, pp.575-578).\nAs is known\, the results of most biophysical experiment s are averaged (for example\, \nin our case\, over a great many DNA fragme nts in a solution) values of macroscopic \nphysical parameters. When model ing charge transfer in a DNA at finite temperature\, \ncalculations should be carried out for a great many realizations so that to find \naverage va lues of macroscopic physical parameters. This formulation of the problem \ nenables paralleling of the program by realizations such as “one process or – one \nrealization”. \nA sequential algorithm is used for individu al realizations. Initial values of site \nvelocities and displacements are preset randomly from the requirement of equilibrium \ndistribution at a g iven temperature. In calculating individual realizations\, at each \nstep a random number with specified characteristics is generated for the Langev in \nterm.\nTo make the problem of modeling of the charge transfer in a gi ven DNA sequence at a \nprescribed temperature suitable to be calculated u sing GRID resource\, the original \nprogram was divided into 2 parts.\nThe first program calculates one realization for given parameters. At the inp ut it \nreceives files with parameters and initial data. The peculiarity o f the task is that \nwe are interested in dynamics of charge transfer\, so at the program output we get \nseveral dozens Mb results.\nUsing a specia l script\, 100-150 copies of the program run with the same parameters \nan d random initial data. Upon completion of the computations\, the files of results \nare compressed and transmitted to a predefined SE. \nWhen an app ropriate number of realizations is calculated\, the second program runs \n once. It must calculate average values for charge probabilities\, for site \ndisplacements from the equilibrium\, etc.\nA special script is sent to calculate this program on WN. This WN takes from SE \nfiles with results o f realizations in series of 10 items. For each series the \naveraging prog ram runs (at the output one gets the data averaged over 10 \nrealizations) . If the output file of a current realization is absent or defective\, \ni t is ignored\, and the next output file is taken. The files obtained are p rocessed \nby this averaging program again. This makes our results indepen dent of chance \nfailures in calculations of individual realizations.\nUsi ng GRID resource by this method\, we have carried out calculations of the hole \nmobility at different temperatures in the range from 10 to 300 K fo r (GG) and (GC) \npolynucleotide sequences (several thousands realizations ).\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=39&sessionId= 9&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=39&sessionId=9& confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Demo: LHCb data analysis using Ganga DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-38@cern.ch DESCRIPTION:Speakers: MAIER\, Andrew (CERN)\nThe ARDA-LHCb prototype activ ity is focusing on the GANGA system (a joint ATLAS-LHCb\nproject). The mai n idea behind GANGA is that the physicists should have a simple\ninterface to their analysis programs. GANGA allows preparing the application\, to\n organize the submission and gather results via a clean Python API. The de tails\nneeded to submit a job on the Grid (like special configuration file s) are factorised\nout and applied transparently by the system. In other w ords\, it is possible to set up\nan application on a portable PC\, then ru n some higher-statistics tests on a local\nfacility (like LSF at CERN) and finally analyse all the available statistics on the\nGrid just changing t he parameter which identifies the execution back-end.\n\nhttp://indico.cer n.ch/contributionDisplay.py?contribId=38&sessionId=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=38&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:MOTEUR: a data intensive service-based workflow engine enactor DTSTART;VALUE=DATE-TIME:20060302T143000Z DTEND;VALUE=DATE-TIME:20060302T150000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-33@cern.ch DESCRIPTION:Speakers: GLATARD\, Tristan (CNRS)\n** Managing data-intensive application workflows\n\nMany data analysis procedures implemented on gri ds are not only\nbased on a single processing algorithm but rather assembl ed from a set\nof basic tools dedicated to process the data\, model it\, e xtract\nquantitative information\, analyze results\, etc. Given that\ninte roperable algorithms packed in software components with a\nstandardized in terface enabling data exchanges are provided\, it is\npossible to build co mplex workflows to represent such procedures for\ndata analysis. High leve l tools for expressing and handling the\ncomputation flow are therefore ex pected to ease computerized medical\nexperiments development.\n\nWorkflow processing is a thoroughly researched area. Grid enabled\napplication ofte n need to process large datasets made of e.g.\nhundreds or thousand of dat a to be processed according to a same\nworkflow pattern. We are therefore proposing a workflow enactment\nengine which:\n- Makes the description of the application workflow simple from the\n application developer point of view.\n- Enables the execution of legacy code.\n- Optimizes the performan ces of data-intensive applications by exploiting\n the potential parallel ism of the grid infrastructure.\n\n** MOTEUR: an optimized service-based w orkflow engine\n\nMOTEUR stands for hoMe-made OpTimisEd scUfl enactoR. MOT EUR is written\nin Java and available under CeCILL Public License (a GPL-c ompatible\nopen source license) at http://www.i3s.unice.fr/~glatard. \nThe workflow description language adopted is the Simple Concept\nUnified Flow Language (Scufl) used by the Taverna and that is\ncurrently becoming a st andard in the e-Science community.\n\nFigure 1 shows the MOTEUR web interf ace representing\na workflow that is being executed. Each service is repre sented by a\ncolor box and data links are represented by curves. The servi ces are\ncolor coded depending on their current status: gray services have \nnever been executed\; green services are running\; blue services have\nf inished the execution of all input data available\; and yellow\nservices a re not currently running but waiting for input data to\nbecome available.\ n\nMOTEUR is interfaced to the job submission interfaces of both the EGEE\ ninfrastructure and the Grid5000 experimental grid. In addition\,\nlightwe ight jobs execution can be orchestrated on local\nresources. MOTEUR is abl e to submit different computing tasks on\ndifferent infrastructures during a single workflow execution. MOTEUR\nis implementing an interface to both Web Services and GridRPC\napplication services.\n\nBy opposition to the t ask-based approach implemented in DAGMan\, MOTEUR\nis service-based. The s ervices paradigm has been widely adopted by\nmiddleware developers for the high level of flexibility that it\noffers. Application services are simil arly well suited for composing\ncomplex applications from basic processing algorithms. In addition\, the\nindependent description of application ser vices and the data to be\nprocessed make this paradigm very efficient for processing large data\nsets. However\, this approach is less common for ap plication code as it\nrequires all codes to be instrumented with the commo n service\ninterface.\n\nTo ease the use of legacy code\, a generic wrappe r application service\nhas been developed. This grid submission service is exposing a\nstandard web interface and is controlling the submission of a ny\nexecutable code. It releases the user from the need to write a\nspecif ic service interface and recompile its application code. Only a\nsmall exe cutable invocation description file is required to enable the\ncommand lin e composition by the generic wrapper.\n\nTo enact different data-intensive applications\, MOTEUR implements two\ndata composition patterns. The data sets transmitted to a service can\nbe composed pairwise (each input of th e first input data set is\nprocessed with each input of the second one). T his correspond to the\ncase where the two input data sets are semantically connected. The\ndata sets can also be fully composed (all inputs of the f irst set are\nprocessed with all inputs of the second one). The use of the se two\ncomposition strategies significantly enlarges the expressiveness o f\nthe workflow language. It is a powerful tool for expressing complex\nda ta-intensive processing applications in a very compact format.\n\nFinally MOTEUR enables 3 different levels of parallelism for\noptimizing workflow application code execution:\n- workflow parallelism inherent to the workfl ow topology\;\n- data parallelism: different input data can be processed i ndependently in\n parallel\;\n- services parallelism: different services processing different data are\n independent and can be executed in parall el.\nTo our knowledge\, MOTEUR is the first service-based workflow enactor \nimplementing all these optimizations.\n\n** Performance analysis on an i mage registration assessment application\n\nMedical image registration alg orithms are playing a key role in a very\nlarge number of medical image an alysis procedures. They are\nfundamental processings often needed prior to any subsequent\nanalysis. The Bronze Standard application\n(http://egee-n a4.ct.infn.it/biomed/BronzeStandard.html) \nis a statistical procedure aim ing at assessing the precision and\naccuracy of different registration alg orithms. The complex application\nworkflow is illustrated in figure 1. Thi s\ndata-intensive application requires the processing of as much input\nim age pairs as possible to extract relevant statistics.\n\nThe Bronze Standa rd application has been enacted on the EGEE\ninfrastructure through the MO TEUR workflow execution engine. A 126\nimage pairs data base\, courtesy of Dr Pierre-Yves Bondiau (cancer\ntreatment center "Antoine Lacassagne"\, N ice\, France)\, was used for\nthe computations. In total\, the workflow ex ecution resulted in 756\njob submissions. The different levels of optimiza tion implemented in\nMOTEUR permitted a speed-up higher than 9.1 when comp ared to a naive\nexecution of the workflow.\n\nSuch data intensive applica tions are common in the medical image\nanalysis community and there is an increasing need for compute\ninfrastructure capable of efficiently process ing large image\ndatabases. MOTEUR is a generic workflow engine that was d esigned to\nefficiently process data intensive workflows. It is freely ava ilable\nfor download under a GPL-like license.\n\nhttp://indico.cern.ch/co ntributionDisplay.py?contribId=33&sessionId=15&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=33&sessionId=15 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Secured Medical Data Management on the EGEE grid DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-32@cern.ch DESCRIPTION:Speakers: Dr. MONTAGNAT\, Johan (CNRS)\n** Clinical data manag ement versus computerized medical analysis\n\nThe medical community is rou tinely using clinical images and\nassociated medical data for diagnosis\, intervention planning and\ntherapy follow-up. Medical imagers are producin g an increasing number\nof digital images for which computerized archiving \, processing and\nanalysis are needed.\n\nDICOM (Digital Image and COmmun ication in Medicine) is today\nthe most widely adopted standard for managi ng medical data in\nclinics. DICOM is including both the image content and additional\ninformation on the patient and the acquisition. DICOM was exc lusively\ndesigned to respond clinical requirements. The interface with\nc omputing infrastructures for instance is completely lacking.\n\nGrids are promising infrastructures for managing and analyzing the\nhuge medical dat abases. However\, the existing grid middlewares are\noften only providing low level data management services for\nmanipulating files\, making diffic ult the gridification of medical\napplications. Medical data often have to be manually transferred and\ntransformed from hospital sources to grid st orage before being\nprocessed and analyzed. To ease applications developme nt there is a\nneed for a data manager that: (i) shares access to medical\ ndata sources for computing without interfering with the clinical\npractic e\; (ii) ensures transparency so that accessing medical\ndata does not req uire any specific user intervention\; and (iii)\nensures a high data prote ction evel to respect patients\nprivacy.\n\n\n** MDM: a grid service for s ecured medical data management\n\nTo ease medical applications devlopment\ , We developed a Medical Data\nManager (MDM) service with the support of t he EGEE uropean IST\nproject. This service was developped on top of the ne w generation\nmiddleware release\, gLite.\n\nThe data management in the gL ite middleware is based on a set of\nStorage Elements which are exposing a same standard\nStorage Resource Manager SRM) interface. The SRM is handli ng\nlocal data at a file level. Additional services such as GridFTP or\ngL iteIO are coexisting on storage elements to provide transfer\ncapabilities . In addition to storage resources\, the gLite data\nmanagement system inc ludes a File Catalog (Fireman) offering\na unique entry point for files di stributed on all grid storage\nelements. Each file is uniquely identified through a\nGlobal Unique IDentifier (GUID).\n\nThe Medical Data Management service architecture is diagrammed in\nfigure 1. On the left\, is represe nted a clinical site:\nvarious imagers in an hospital are pushing the imag es\nproduced on a DICOM server. Inside the hospital\, clinicians can acces s\nthe DICOM server content through DICOM clients. In the center of\nfigur e 1\, the MDM internal logic is represented. On the\nright side\, the grid services interfacing with the MDM are shown. To\nremain compatible with the rest of the grid infrastructure\, the MDM\nservice is based on an SRM- DICOM interface software which translates\nSRM grid requests into DICOM tr ansactions addressed to the medical\nservers. Thus\, medical data servers can be transparently \nshared between clinicians (using the classical DICO M interface inside\nhospitals) and image analysis scientists (using the SR M-DICOM\ninterface to access the same data bases) without interfering\nwit h the clinical practice. An internal scratch space is used to\ntransform D ICOM data into files that are accessible through data\ntransfer services ( GridFTP or gLiteIO). For enforcing data\nprotection\, a highly secured and fault tolerant encryption key\ncatalog\, called hydra\, is used. In addit ion\, all DICOM files\nexported to the grid are anonimized. A metadata man ager is in charge\nof holding the metadata extracted from DICOM headers an d to ease data\nsearch. The AMGA ervice is used for ensuring secured stora ge of these very\nsensitive data. The AMGA server holds a relation between each DICOM\nslice and the image metadata.\n\nThe security model of the MD M relies on several components: (i) file\naccess control\, (ii) files anon ymization\, (iii) files encryption\, and\n(iv) secured access to metadata. The user is coherently identified\nthrough a single X509 certificate for all services involved in\nsecurity. The file access control is enforced by the gLiteIO service\nwhich accepts Access Control Lists (ACLs). The hydra key store and the\nAMGA metadata service both accept ACLs. To read an ima ge content\, a\nuser needs to be authorized both to access the file and to the\nencryption key. The access rights to the sensitive metadata associat ed\nto the files are administrated independently. Thus\, it is possible to \ngrant access to an encrypted file only (e.g. for replicating\na file wit hout accessing to the content)\, to the file content\n(e.g. for processing the data without revealing the patient\nidentity)\, or to the full file m etadata (e.g. for medical\nusage). Through ACLs\, it is possible to implem ent complex use cases\,\ngranting access rights to patients\, physicians\, healthcare\npractitioners\, or researchers independently.\n\n** Medical i mage analysis applications\n\nOn the client side\, three levels of interfa ces are available to access\nand manipulate the data hold by the MDM: (1) the standard SRM\ninterface\, can be used to access encrypted images provi ded that their\nGUID is known\; (2) the encryption middleware layer can bo th fetch and\ndecrypt files\; (3) the fully MDM aware client provides acce ss to the\nmetadata associated to files in addition.\n\nThe Medical Data M anager has been deployed on several sites for\ntesting purposes. Three sit es are actually holding data in three DICOM\nservers installed at I3S (Sop hia Antipolis\, France)\, LAL (Orsay\,\nFrance) and CREATIS (Lyon\, France ). An AMGA catalog has also been set\nup in CREATIS (Lyon) for holding all sites' metadata\, and an hydra key\nstore is deployed at CERN (Geneva\, S witzerland).\n\nThe testbed deployed has been used to demonstrate the viab ility of the\nservice by registering and retrieving DICOM files across\nsi tes. Registered files could be retrieved and used for computations\nfrom E GEE grid nodes transparently. The next important milestone will\nbe to exp eriment the system in connection with hospitals by\nregistering real clini cal data freshly acquired and registered on the\nfly from the hospital ima gers.\n\nThe Medical Data Manager is an important service for enabling med ical\nimage processing applications on the EGEE grid infrastructure. Sever al\nexisting applications could potentially use the MDM such as the GATE\, \nCDSS\, gPTM3D\, pharmokinetics\, and Bronze Standard applications\ncurre ntly deployed on the EGEE infrastructure.\n\nhttp://indico.cern.ch/contrib utionDisplay.py?contribId=32&sessionId=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=32&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Space Physics Interactive Data Resource - SPIDR DTSTART;VALUE=DATE-TIME:20060302T164000Z DTEND;VALUE=DATE-TIME:20060302T170000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-31@cern.ch DESCRIPTION:Speakers: Dr. ZHIZHIN\, Mikhail (Geophysical Center Russian Ac ad. Sci.)\, Mr. MISHIN\, Dmitry (Institute of Physics of the Earth Russian Acad. Sci.)\nSPIDR (Space Physics Interactive Data Resource) is a de fact o standard data source on\nsolar-terrestrial physics\, functioning within the framework of the ICSU World Data\nCenters. It is a distributed databas e and application server network\, built to\nselect\, visualize and model historical space weather data distributed across the\nInternet. SPIDR can work as a fully-functional web-application (portal) or as a grid\nof web-s ervices\, providing functions for other applications to access its data ho ldings. \n\nCurrently SPIDR archives include geomagnetic variations and in dices\, solar activity\nand solar wind data\, ionospheric\, cosmic rays\, radio-telescope ground observations\,\ntelemetry and images from NOAA\, NA SA\, and DMSP satellites. SPIDR database clusters\nand portals are install ed in the USA\, Russia\, China\, Japan\, Australia\, South Africa\,\nand I ndia.\n\nSPIDR portal combines functionality from the central XML metadata repository with two\nlevels of metadata\, descriptive and inventory\, wit h a set of distributed data source\nweb services\, web map services\, and raw observations data files collections. A user\ncan search for data using metadata inventory\, use persistent data basket to save the\nselection fo r the next session\, and to plot and download in parallel the selected\nda ta in different formats\, including XML and NetCDF. A database administrat or can\nupload new files into the SPIDR databases using either the web ser vices or the web\nportal. SPIDR databases are self-synchronising. User sup port on the portal includes\ndiscussion forum\, i-mail\, data basket for m etadata bookmarks and selected data\nsubsets\, and usage tracking. \n\nSPI DR technology can be used for environmental data sharing\, visualization a nd\nmining\, not only in space physics\, but also in seismology\, GPS meas urements\, tsunami\nwarning systems\, etc. All grid data services in SPIDR share the same Common Data\nModel and compatible metadata schema.\n\nhttp ://indico.cern.ch/contributionDisplay.py?contribId=31&sessionId=13&confId= 286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=31&sessionId=13 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Meteorology and Space Weather Data Mining Portal DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-30@cern.ch DESCRIPTION:Speakers: Dr. ZHIZHIN\, Mikhail (Geophysical Center Russian Ac ad. Sci.)\, Mr. MISHIN\, Dmitry (Institute of Physics of the Earth Russian Acad. Sci.)\, Mr. POYDA\, Alexey (Moscow State University)\nWe will demon strate an environmental data mining project Environmental Scenario\nSearch Engine (ESSE) including a secure web application portal for interactive\n searching for events over a grid of environmental data access and mining w eb services\nhosted by OGSA-DAI containers. The web services are grid prox ies for the database\nclusters with terabytes of high-resolution meteorolo gical and space weather\nreanalysis data over the past 20-50 years. The da ta mining is based on fuzzy logic to\nmake it possible to describe the sea rching events in natural language terms\, such as\n“very cold day”. Th e ESSE portal allows parallel data mining across disciplines for\ncorrelat ed events in space\, atmosphere and ocean. The ESSE data web-services are\ ninstalled in the USA\, Russia\, South Africa\, Australia\, Japan\, and Ch ina. The EGEE\ninfrastructure facilitates sharing of the environmental dat a and grid services with\nthe European environmental sciences community. T he work is done in cooperation with\nthe National Geophysical Data Center NOAA and supported by the grant from the\nMicrosoft Research Ltd.\n\nhttp: //indico.cern.ch/contributionDisplay.py?contribId=30&sessionId=22&confId=2 86 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=30&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Supporting legacy code applications on EGEE VOs by GEMLCA and the P-GRADE portal DTSTART;VALUE=DATE-TIME:20060302T153500Z DTEND;VALUE=DATE-TIME:20060302T155000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-37@cern.ch DESCRIPTION:Speakers: Mr. SIPOS\, Gergely (MTA SZTAKI)\nGrid environments require special grid-enabled applications capable of utilising \nthe under lying middleware services and infrastructures. Most Grid projects so far \ nhave either developed new applications from scratch\, or significantly re -engineered \nexisting ones in order to be run on their platforms. This pr actice is appropriate \nonly in the context where the applications are mai nly aimed at proving the concept \nof the underlying architecture. However \, as Grids become stable and commonplace in \nboth scientific and industr ial settings\, a demand will be created for porting a \nvast legacy of app lications onto the new platform. Companies and institutions can \nill affo rd to throw such applications away for the sake of a new technology\, and \nthere is a clear business imperative for them to be migrated onto the Gr id with the \nleast possible effort and cost.\nGrid computing has reached the point where reliable infrastructures and core Grid \nservices are avai lable for various scientific communities. However\, not even the \nEGEE Gr id contains any tool to support the turning of legacy applications into Gr id \nservices that provide complex functions on top of the core Grid layer . The Grid \nExecution Management for Legacy Code Architecture (GEMLCA)\, presented in this \npaper\, enables legacy code programs written in any so urce language (Fortran\, C\, \nJava\, etc.) to be easily deployed on the E GEE Grid as a Grid service without \nsignificant user effort. GEMLCA does not require any modification of\, or even \naccess to\, the original sourc e code. A user-level understanding\, describing the \nnecessary input and output parameters and environmental values – such as the number \nof pro cessors or the job manager required – is all that is needed to port the \nlegacy application binary onto the Grid. Moreover\, since GEMLCA has bee n integrated \nwith the P-GRADE Portal\, end-users can publish legacy appl ications as Grid services \nand can invoke legacy code services as a speci al kind of job (node) inside their \nworkflows by an easy to use graphical portal interface. \nThe GEMLCA - P-GRADE Portal has been operating for th e UK NGS community as a \nservice since September 2005. Recently\, the res earchers of the University of \nWestminster and MTA SZTAKI have developed the EGEE-specific version of this tool. \nThe EGEE-specific GEMLCA P-GRADE Portal offers the same legacy code management and \nworkflow-oriented app lication development and execution facilities for EGEE \nresearch communit ies that have been provided on the UK NGS for more than six months \nnow. \nOn top of the JSR-168 compliant portlets of the P-GRADE Portal (credenti al \nmanagement\, workflow enactment\, etc) the GEMLCA-specific version co ntains an \nadditional portlet that can be used to turn legacy application s into Grid services \nand to offer these services to other users of the p ortal. These users can invoke \nthe legacy code services with their own cu stom input data\, moreover\, they \ncan integrate legacy code services wit h newly developed codes inside their \nworkflows. The portal environment c ontains a GEMLCA-specific editor to help users \ndefine such workflows. Th e workflow enactment service integrated into the Portal is \ncapable to fo rward job submission and legacy code service invocation requests to \nappr opriate providers. While the core EGEE sites are responsible for job execu tion\, \nthe “legacy code repository” component of the portal server h andles legacy code \ninvocation requests. \nThis centralised repository pr ovides opportunity for portal users to share \napplications with each othe r. The facility is a natural step to extend the concept \nof Virtual Organ izations (VO). While the storage services of the EGEE Grid provide \nstora ge space for VO members in order to share data with each other\, the code \nrepository component of the GEMLCA P-GRADE Portal provides facility for VO members \nto share applications with each other. Moreover\, since the P -GRADE Portal can be \nconnected to multiple VOs at the same time\, applic ation sharing among the members \nof different VOs can take place through the Portal. \nAccording to the current notion of EGEE the Grid is separate d into research domain \nspecific VOs\, each of them containing relatively small number of resources. This \nconcept simply prohibits two scientists working on two different scientific domains \nto collaborate with each ot her. Because these researchers are members of two \ndifferent VOs there is no way for them to share applications with each other. \nHowever\, by pub lishing their applications in the “legacy code repository” component \ nof the GEMLCA P-GRADE Portal they can share these codes with other member s of the \nwhole EGEE community. This facility paves the way for revolutio nary results in \ninterdisciplinary research.\n\nBesides the GEMLCA P-GRAD E Portal the presentation will introduce an urban traffic \nsimulation app lication developed on the EGEE Grid using this tool. \nThe traffic simulat ion is based on a workflow consisting of three types of \ncomponents. The Manhattan legacy code (component 1) is an application to generate \ninputs for the MadCity simulator: a road network file and a turn file. The MadCi ty \nroad network file is a sequence of numbers\, representing a road topo logy of a road \nnetwork. The MadCity turn file describes the junction man oeuvres available in a \ngiven road network. Traffic light details are als o included in this file. MadCity \n(component 2) is a discrete-time micros copic traffic simulator that simulates \ntraffic on a road network at the level of individual vehicles behaviour on roads \nand at junctions. After completing the simulation\, a macroscopic trace file\, \nrepresenting the total dynamic behaviour of vehicles throughout the simulation run\, \nis c reated. Finally a traffic density analyser (component 3) compares the traf fic \ncongestion of several runs of the simulator on a given network\, wit h different \ninitial road traffic conditions specified as input parameter s. The component \npresents the results of the analysis graphically. \nThe lecture will use this application to describe how portal users can integr ate \ntheir domain-specific applications into a large distributed program to solve the \ncomplex problem of traffic simulation. This example will pr esent the benefits of \nportal-based collaborative work on the EGEE.\n\nht tp://indico.cern.ch/contributionDisplay.py?contribId=37&sessionId=17&confI d=286 LOCATION:CERN 40-S2-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=37&sessionId=17 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:On-line demonstration of Flood application at EGEE User Forum DTSTART;VALUE=DATE-TIME:20060301T154500Z DTEND;VALUE=DATE-TIME:20060301T160000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-36@cern.ch DESCRIPTION:Speakers: Dr. TRAN\, Viet (Institute of Informatics\, Slovakia )\nThe flood application has been successfully demonstrated at EGEE second review in \nDecember and we would demonstrate it at EGEE User forum for G rid application \ndevelopers and Grid users.\n\nFlood application consists of several numerical models of meteorology\, hydrology \nand hydraulics. A portal is developed for comfortable use of flood application. The \nport al has four main modules:\n• Workflow management module: for managing ex ecution of tasks with data \ndependences\n• Data management module: allo ws users to search and download data from \nstorage elements\n• Visualiz ation module: show the output from models in several forms: text\, \npictu re\, animation and virtual reality\n• Collaboration module: allows users to communicate with each other and \ncooperate on flood forecasting\n\nTh e demonstration will be done on GILDA demonstration testbed. Job execution in the \nGrid tested will be performed using gLite middleware. The aim of the demonstration \nis to show how to implement complicate grid applicati ons with many models and \nsupport modules and also the FloodGrid portal\, that allows users to run the \napplication without knowledge about grid c omputing\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=36&sess ionId=11&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=36&sessionId=11 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Internal Virtual Organizations in the RDIG-EGEE Consortium DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-35@cern.ch DESCRIPTION:Speakers: Dr. TIKHONENKO\, Elena (Joint Institute for Nuclear Research (JINR))\nIn the beginning of 2005 the formal procedures and the p roper administrative \nstructures for creation and registration of the int ernal RDIG-EGEE virtual \norganizations were established in the Russian Da ta Intensive Grid (RDIG) \nconsortium. \nThe Service Center of Registratio n of the Virtual Organizations is accessible \nthrough the URL: http://r dig-registrar.sinp.msu.ru/newVO.html . All the documents \nand rules\, the basic document\, in particular - “Creation and Registration of \nVirtua l \nOrganizations in the frames of the RDIG-EGEE: Rules and Procedure” ( in Russian)\, \nand \nthe Questionnaire examples can be found there (http: //rdig-\nregistrar.sinp.msu.ru/VOdocs/newVOinRDIG.html). The Council on RD IG-EGEE extension \nhas been formed. The Council inspects all the new req uests for new virtual \norganizations to be created. \n The aim of th e creation of the RDIG-EGEE virtual organizations is to serve \nthe \nnati onal scientific projects and to test new application areas prior to includ ing \nthem into the global EGEE infrastructure. Nowadays we have 6 RDIG-EG EE internal \nvirtual organizations with 42 members in them. Brief informa tion on the Fusion VO \nfor ITER project activities in Russia\, eEarth VO for geophysics and cosmic research \ntasks (http://www.e-earth.ru/)\, and PHOTON VO for PHOTON and SELEX experiments \n(http://egee.itep.ru/PHOTON/i ndex29d5en.html) is presented in poster.\n\nhttp://indico.cern.ch/contribu tionDisplay.py?contribId=35&sessionId=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=35&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:International Telecommunication Union Regional Radio Conference an d the EGEE grid DTSTART;VALUE=DATE-TIME:20060301T141500Z DTEND;VALUE=DATE-TIME:20060301T143000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-34@cern.ch DESCRIPTION:Speakers: Dr. MANARA\, Andrea (ITU BR)\nThe Radiocommunication Bureau of the ITU (ITU-BR) manages the preparations for the\nITU Regional Radio Conference RRC06 to establish a new frequency plan for the\nintrodu ction of digital broadcasting (band III and IV/V) in Europe\, Africa\, Ara b\nStates and former-USSR States. During the 5 weeks of the RRC06 Conferen ce (15 May \nto\n16 June 2006) delegations from 119 Member States will ne gotiate the frequency plan.\n\nThe frequency plan will be established in a n iterative way. During week time at the\nRRC06 administrations will negot iate and submit their requirements to the ITU-BR\,\nwhich will conduct ove r the subsequent weekend all the calculations (analysis and\nsynthesis) th at would result in assigning specific frequencies for the draft plan.\nThe output of the calculations will be the input for negotiations in the subs equent\nweek\, with the last iteration constituting the basis for the fina l frequency plan. \nIn\naddition\, partial calculations are envisaged for parts of the planning area in\nbetween two global iterations (for the enti re planning area). \n\nFor obtaining optimum planning of the available fre quency spectrum\, two different\nsoftware processes have been developed by the European Broadcasting Union and they\nare run in sequence: compatibil ity assessment and plan synthesis. The compatibility\nassessment (which is very CPU demanding and can be run on a distributed\ninfrastructure) calcu lates the interference between digital requirements\, analogue\nbroadcasti ng and other services stations. The plan synthesis assigns channels to\nre quirements which could share the same channel.\n\nThe limited time to perf orm the calculation calls for the optimization of the\nprocess. The turna round time to provide a new set of results would be a critical\nfactor for the success of the Conference. The EGEE grid will greatly enhance the\nIT U-BR available resources allowing better serving the Conference. The grid\ ninfrastructure will complement the client-server distributed system devel oped within\nthe ITU-BR\, which has been used for the first exercises. In addition\, the \npossibility\nto perform faster calculations could improve the efficiency of the negotiation (for\nexample\, giving preliminary resu lts during the negotiation weeks themselves or allow\nextra quality checks and compatibility studies).\n\nThe compatibility assessment consists in r unning a large number of jobs (some tens \nof\nthousands). Each job is bas ically the same application running on different datasets\nrepresenting th e parameters of radio-stations. One should note that the execution\ntime v aries by more than 3 orders of magnitudes (the majority of jobs needs only few\nseconds but few jobs require many hours) depending on the input para meters and \ncannot\nbe completely predicted. To cope with this situation we decided to use a\nclient-server system called DIANE that allows run-tim e load balancing\, access to\nheterogeneous resources (Grid and local clus ter at the same time) and a robust\ninfrastructure to cope with run-time p roblems. In the DIANE terminology\, a job is\ndefined as a “task”. DIA NE allows using in the most effective way the available\nresources since e ach available worker nodes asks for the next task: while a long \ntask\nwi ll “block” a node\, in the mean time the short tasks (the large majori ty) will flow\nthrough the other nodes.\n\nWe have already demonstrated to be able to perform the required calculations on the\nEGEE/LCG infrastruct ure (in the first tests\, we have run with a parallelism of the\norder of 50\, observing the expected speed-up factor) and we are preparing\, in clo se\ncollaboration with CERN\, to use these techniques during the Conferenc e later this\nyear. The EGEE infrastructure does not only enable us to giv e the adequate support\nfor an important international event but\, in addi tion\, the substantial speed-up\nalready observed opens the possibility to allow faster and more detailed studies\nduring the Conference. The techni cal improvement gives the possibility to provide a\nbetter service and tec hnical data to the Conference’s delegates.\n\nThe present set up is well suited for the foreseen application. The possibility to\naccess resources from the grid and corporate resources (which we are not yet\nexploiting) is very appealing and should be interesting for other users. The\npossibil ity to describe and execute more complex workflow (presently we are using \nthe\nsystem to execute independent tasks in parallel) could increase the interest for the\ntools we are currently using.\n\nhttp://indico.cern.ch/ contributionDisplay.py?contribId=34&sessionId=11&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=34&sessionId=11 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Early Diagnosis of Alzheimer’s Disease Using a Grid Implementati on of Statistical Parametric Mapping Analysis DTSTART;VALUE=DATE-TIME:20060301T160000Z DTEND;VALUE=DATE-TIME:20060301T161500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-60@cern.ch DESCRIPTION:Speakers: Mrs. TORTEROLO\, Livia (Bio-Lab\, DIST\, University of Genoa)\nA voxel based statistical analysis of perfusional medical image s may provide \npowerful support to the early diagnosis for Alzheimer’s Disease (AD). A Statistical \nParametric Mapping algorithm (SPM)\, based o n the comparison of the candidate with \nnormal cases\, has been validated by the neurological research community to quantify \nipometabolic pattern s in brain PET/SPECT studies. Since suitable “normal patient” \nPET/SP ECT images are rare and usually sparse and scattered across hospitals and \nresearch institutions\, the Data Grid distributed analysis paradigm (“ move code \nrather than input data”) is well suited for implementing a r emote statistical \nanalysis use case\, described as follow.\n\nhttp://ind ico.cern.ch/contributionDisplay.py?contribId=60&sessionId=9&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=60&sessionId=9& confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Development of gLite Web Service Based Security Components for the ATLAS Metadata Interface DTSTART;VALUE=DATE-TIME:20060302T132000Z DTEND;VALUE=DATE-TIME:20060302T134000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-61@cern.ch DESCRIPTION:Speakers: Mr. DOHERTY\, Thomas (University of Glasgow)\nIntrod uction\n\nAMI (ATLAS Metadata Interface) is a developing application\, whi ch stores and allows\naccess to dataset metadata for the ATLAS experiment. It is a response to the large\nnumber of database-backed applications nee ded by an LHC experiment called ATLAS\, all\nwith similar interface requir ements. It fulfills the need of many applications by\noffering a generic w eb service and servlet interface\, through the use of\nself-describing dat abases. Schema evolution can be easily managed\, as the AMI\napplication d oes not make any assumptions about the underlying database structure.\nWit hin AMI data is organized in "projects". Each project can contain several\ nnamespaces (*). The schema discovery mechanism means that independently d eveloped\nschemas can be managed with the same software.\n\nThis paper sum marises the impact of the requirements contracted to AMI of five gLite\nme tadata interfaces. These interfaces namely MetadataBase\, MetadaCatalog\,\ nServiceBase\, FASBase and MetadaSchema [1] deal with a range of previousl y identified\nuse cases on dataset (and logical files) metadata by particl e physicists and project\nadministrators working on the ATLAS experiment. The future impact on AMI architecture\nof the VOMs security structure and the gLite search interface are both discussed.\n\nFundamental Architecture of AMI\n\nThe AMI core software can be used in a client server model. The re are three\npossibilities for a client (software installed on client sid e\, from a\nbrowser and web services) but the relevant client with regards to grid services is\nthe Web Services client. \n\nWithin AMI there are ge neric packages\, which constitute the middle layer of its\nthree-tier arch itecture. Command classes can be found within these packages. These\nclass es are key to the implementation of the gLite methods in each of the inter faces.\nThe implemented gLite interfaces are therefore situated on the ser ver side in this\nmiddle layer and directly interface with the client tier and the command classes in\nthis middle layer. It is possible to choose a corresponding AMI command that is\nequivalent to the basic requirements o f each of the gLite Interface methods. \n \n[Figure 1]\n\nFigure 1: A Sch ematic View of the Software Architecture of AMI [2]. This diagram\nshows t he AMI Compliant Databases as the top layer. This interfaces with the lowe st\nsoftware layer\, which is JDBC. The middle layer BkkJDBC package allow s for connection\nto both MySQL and Oracle. The generic packages contain c ommand classes which are used\nin managing the databases. Application spec ific software in the outer layer can\ninclude the generic web search pages .\n\nThe procedure used to further understand the structure necessary to i mplement the\ngLite methods was to observe how AMI is designed to absorb c ommands into its middle\ntier mechanism. This was achieved by mapping the delegation of methods through the\nrelevant code and is best illustrated with the use of an UML sequence diagram in\nfigure 2.\n\nThe deployment of AMI as a web application in a web container can take place using\nTomcat. To set up web services for AMI it is necessary to plug the Axis framework \ninto Tomcat. Then with the use of WSDL and the axis tools that allow con version from\nWSDL to Java client classes a Java web service client class can be deployed which\ncommunicates with the gLite interfaces.\n\n(*) name space is "database" in MySQL terms\, "schema" in ORACLE and "file" in SQLi te.\n \n [Figure 2]\n\nFigure 2: UML sequence diagram of basic workings of AMI. Note: A controller class\ndelegates what command class is invoked. A router loader is instantiated to connect\nto a database. XML output is re turned to the gLite interface implementation class.\n\n \nA direct consequ ence of grid services is secure access. This involves authentication\nand authorisation of users and machines. Authorisation in AMI is handled by a local\nrole-based mechanism. Authentication is implemented by securing the web services\nusing grid certificates. \n\nCurrently permissions in AMI a re based on a local role system. An EGEE wide role\nsystem called Virtual Organizations Membership Service (VOMS) [3] is being developed.\nAMI would then have to be set up to read and understand VOMS attributes and grant\n permissions based on a user's role in ATLAS. Requirements analysis work is currently\nunderway on the impact of this VOMS system on the AMI architec ture.\n\nAlso directly relevant to the gLite interface was the implementat ion of a query\nlanguage for performing cascaded searches through all proj ects. This implementation\nused a library (JFLEX) to define our own gramma r rules\, following the EGEE gLite\nMetadata Query Language (MQL) specific ation. It allows AMI to execute a search in a\ngeneric way on several data bases of any type (MySQL\, ORACLE or SQLite for example)\nstarting only fr om one MQL query.\n\nConclusion\n\nThis paper presents a description of th e implemention of the gLite Interfaces for\nAMI. It summarises how AMI was set up fully with these implementation classes\ninterfacing with web serv ice clients and how these clients are made secure with the\naid of grid ce rtificates.\n\nAMI as mentioned provides a set of generic tools for managi ng database applications.\nAMI also supports geographical distribution wit h the use of web services. To\nimplement the gLite interfaces as a wrapper to AMI using these web services provides\nthe user with a generic and sec ure metadata interface. Along with the gLite search\ninterface\, any third party application should be able to plug in AMI knowing it\nsupports a we ll defined API.\n\nReferences\n\n[1] Developer's Guide for the gLite EGEE Middleware -\nhttp://edms.cern.ch/document/468700\n[2] ATLAS Metadata Int erfaces (AMI) and ATLAS Metadata Catalogs\, Solveig Albrand\,\nJerome Fula chier\, LPSC Grenoble\n[3] VOMs - http://hep-project-grid-scg.web.cern.ch/ hep-project-grid-scg/voms.html\n\nhttp://indico.cern.ch/contributionDispla y.py?contribId=61&sessionId=13&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=61&sessionId=13 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:The ATLAS Rome Production Experience on the LHC Computing Grid DTSTART;VALUE=DATE-TIME:20060301T163000Z DTEND;VALUE=DATE-TIME:20060301T170000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-62@cern.ch DESCRIPTION:Speakers: Dr. CAMPANA\, Simone (CERN/IT/PSS)\nThe Large Hadron Collider at CERN will start data acquisition in 2007. The ATLAS (A\nToroi dal LHC ApparatuS) experiment is preparing for the data handling and analy sis\nvia a series of Data Challenges and production exercises to validate its computing\nmodel and to provide useful samples of data for detector an d physics studies. The\nlast Data Challenge\, begun in June 2004 and ended in early 2005\, was the first\nperformed completely in a Grid environment . Immediately afterwards\, a new production\nactivity was necessary in ord er to provide the event samples for the ATLAS physics\nworkshop\, taking p lace in June 2005 in Rome. This exercise offered a unique\nopportunity to estimate the reached improvements and to continue the validation of\nthe c omputing model. In this contribution we discuss the experience of the “R ome\nproduction” on the LHC Computing Grid infrastructure\, describing t he achievements\,\nthe improvements with respect to the previous Data Chal lenge and the problems\nobserved\, together with the lessons learned and f uture plans.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=62& sessionId=10&confId=286 LOCATION:CERN 40-5-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=62&sessionId=10 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:BOSS: the CMS interface for job summission\, monitoring and bookke eping DTSTART;VALUE=DATE-TIME:20060302T140000Z DTEND;VALUE=DATE-TIME:20060302T143000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-63@cern.ch DESCRIPTION:Speakers: CODISPOTI\, Giuseppe (Universita di Bologna)\nBOSS ( Batch Object Submission System) has been developed in the context of the C MS\nexperiment to provide logging and bookkeeping and real-time monitoring of jobs\nsubmitted to a local farm or a grid system. The information is p ersistently stored in\na relational database (right now MySQL or SQLite) f or further processing. In this way\nthe information that was available in the log file in a free form is structured in a\nfixed-form that allows eas y and efficient access. The database is local to the user\nenvironment and is not requested to provide server capabilities to the external\nworld: t he only component that interacts with it is the BOSS client process.\nBOSS can log not only the typical information provided by the batch systems (e .g.\nexecutable name\, time of submission and execution\, return status\, etc…)\, but also\ninformation specific to the job that is being executed (e.g. dataset that is being\nproduced or analyzed\, number of events done so far\, number of events to be done\,\netc…). This is done by means of user-supplied filters: BOSS extracts the specific\nuser-program informati on to be logged from the standard streams of the job itself\nfilling up a fixed form journal file to be retrieved and processed at the end of job\nr unning via the BOSS client process.\nBOSS interfaces to a local or grid sc heduler (e.g. LSF\, PBS\, Condor\, LCG\, etc…)\nthrough a set of scripts provided by the system administrator\, using a predefined\nsyntax. This a llow hiding to the upper layers its implementation details\, in\nparticula r whether the batch system is local or distributed. The interface provides \nthe capability to register\, un-register and list the schedulers. BOSS p rovides an\ninterface to the local scheduler for the operations of job sub mission\, deletion\,\nquerying and output retrieval. At output retrieval t ime the information in the\ndatabase is updated using information sent bac k with the job.\nBOSS provides also an optional run-time monitoring system that\, working in parallel\nto the logging system\, collects information while the computational program is still\nrunning\, and presents it to the upper layers through the same interface. The\nreal-time information sent by the running jobs are collected in a separate database\nserver\, the sa me real-time database server may support more than one BOSS database.\nThe information in the real-time database server has a limited lifetime: in g eneral\nit is deleted after that the user has accessed it\, and in any cas e after successful\nretrieval of the journal file. It is not possible to u se the information in the\nreal-time database server to update the logging information in the BOSS database once\nthe journal file for the related j ob has been processed.\nThe run-time monitoring is made through a pair cli ent-updater registered as a plug-in\nmodule: they are the only components that interact with the real time database. The\nreal-time updater is a cli ent of the real-time database server: it sends the\ninformation of the jou rnal file to the server at pre-defined intervals of time. The\nreal-time c lient is a tool used by BOSS to update his database using the real-time\ni nformation.\nThe interface with the user is made through:\na command line \, kept as similar as possible to the one of the previous versions\; it\ni s the minimal way to access BOSS functionalities to give a straightforward test and\ntraining instrument\;\nC++ API\, increasing functionalities and ease-to-use for programs using BOSS:\ncurrently it is under development a nd is meant to grown-up with the users requirements\;\nPython API\, givin g almost the same functionalities of the C++ one\, plus the\npossibility t o run BOSS from a python command line.\nUser programs may be chained toget her to be executed by a single batch unit (job).\nThe relational structure supports not only multiple programs per job (program chains)\nbut also mu ltiple jobs per chain (in the event of job resubmission). Homogeneous\njo bs\, or better "chains of programs"\, may be grouped together in tasks (e. g. as a\nconsequence of the splitting of a single processing chain into ma ny processing chains\nthat may run in parallel). The description of a tas k is passed to BOSS through an\nXML file\, since it can model its hierarch ical structure in a natural way.\nThe process submitted to the batch sched uler is the BOSS job wrapper. All\ninteractions of the batch scheduler to the user process pass through the BOSS wrapper. \nThe BOSS job wrapper sta rts the chosen chaining tool\, and optionally the real-time\nupdater. An i nternal tool for chaining programs linearly is implemented in BOSS but\nin future external chaining tools may be registered to BOSS so that more com plex\nchaining rules may be requested by the users. BOSS will not need to know how they\nwork and will just pass any configuration information trans parently down to them.\nThe chaining tool starts a BOSS “program wrapper ” for each user program.The program\nwrapper starts all processes needed to get the run-time information from the user\nprograms into the journal file. This program wrapper is unique and it has to be\nstarted passing onl y one parameter\, the program id.\nThe BOSS client determines finished job s by a query to the scheduler. It retrieves\nthe output for those jobs and uses the information in the journal file to update the\nBOSS database.\nT he BOSS client pops the information about running jobs from the real-time database\nserver through the client part of the registered Real Time Monit or. It also deletes\nfrom the server the information concerning jobs for w hich the BOSS database has\nalready been updated using the journal file. T he information extracted from the\nreal-time database server may be used t o update the local BOSS database or just to\nshow the latest status to the user.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=63&sessio nId=15&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=63&sessionId=15 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Massive Ray Tracing in Fusion Plasmas on EGEE DTSTART;VALUE=DATE-TIME:20060301T143000Z DTEND;VALUE=DATE-TIME:20060301T150000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-64@cern.ch DESCRIPTION:Speakers: Mr. VAZQUEZ-POLETTI\, Jose Luis (Universidad Complut ense de Madrid (Spain))\nPlasma heating in magnetic confinement fusion dev ices can be performed by launching a\nmicrowave beam with frequency in the range of the cyclotron frequency of either ions\nor electrons\, or close to one of their harmonics. The Electron Cyclotron Resonance\nHeating (ECRH ) is characterized by the small size of the wavelength that allows one\nto study the wave properties using the geometrical optics approximations. Th is means\nthat the microwave beam can be simulated by a large amount of ra ys. If there is no\ncritical plasma layer (like cut off or resonance) clos e to the beam waist\, it is\npossible to use the far field approximation a nd the beam can be simulated by a bunch\nof one or two hundred rays\, whic h can be performed in a cluster. However\, if the beam\nwaist is closed to the critical layer and the heating method uses Electron Bernstein\nWaves (EBW)\, the number of rays needed is much larger. Being all the ray comput ations\nindependent\, this problem is well suited to be solved in the grid relying on the EGEE\ninfrastructure [1].\n\nWe have developed a MRT (Mass ive Ray Tracing) framework using the lcg2.1.69 User\nInterface C++ API. It sends over the grid the single ray tracing application (called\nTruba [2] ) which performs the tracing of a single ray. This framework works in the\ nfollowing way: First of all\, a launcher script generates the JDL files n eeded. Then\,\nthe MRT framework launches all the single ray tracing jobs simultaneously\,\nperiodically querying each job's state. And finally\, it retrieves the job's output.\n\nWe performed several experiments in the SW ETEST VO with a development version of\nTruba\, whose average execution ti me on a Pentium 4 3.20 GHz is 9 minutes. Truba's\nexecutable file size is 1.8 MB\, input file size is 70 KB\, and output file size is\nabout 549 KB. In the SWETEST VO\, there were resources from the following sites: LIP\n( 16 nodes\, Intel Xeon CPU 2.80 GHz)\, IFIC (117 nodes\, AMD Athlon 1.2 Ghz )\, PIC (69\nnodes\, Intel Pentium 4 2.80 GHz)\, USC (100 nodes\, Intel Pe ntium III 1133 MHz)\, IFAE\n(11 nodes\, Intel Pentium 4 2.80 GHz) and UPV (24 nodes\, Pentium III). All Spanish\nsites are connected by RedIRIS\, th e Spanish Research and Academic Network. The\nminimum link bandwidth is 62 2 Mbps and the maximum\, 2.5 Gbps.\n\nThe MRT framework traced 50 rays and it took an overall time of 88 minutes. In this\ncase\, we analyzed the fo llowing parameters: execution time (how much time took Truba\nto be execut ed in the remote resource not including queue time)\, transfer time\,\nove rhead (how much overhead is introduced by the Grid and the framework itsel f due to\nall the inner nodes and stages the job passes through) and produ ctivity (number of\njobs per time unit). The average execution time was 10 .09 minutes and its standard\ndeviation was 2.97 minutes (this is due to t he resource heterogeneity). The average\ntransfer time was 0.5 minutes and its standard deviation was 0.12 minutes (this is\ndue to dynamic network bandwidth). The average overhead was 29.38 minutes. Finally\,\nthe product ivity was 34.09 rays/hour.\n\nNevertheless\, we found the lack of opportun istic migration (some jobs remained\n“Scheduled” for too long) and fau lt tolerance mechanisms (specially during submission\nusing Job Collection s\, retrieving output and some “Ready” status that were really\n“Fai led” and took too long to be rescheduled) as limitations of the LCG-2\ni nfrastructure (some of the nodes marked by the GOC as “OK” were not). Even\, problems\nhandling Job Collections and submitting more than 80 jobs were found. \n\nIn order to bypass these problems\, we used GridWay\, a l ight-weight framework. It\nworks on top of Globus services\, performing jo b execution management and resource\nbrokering\, allowing unattended\, rel iable\, and efficient execution of jobs\, array\njobs\, or complex jobs on heterogeneous\, dynamic and loosely-coupled Grids. GridWay\nperforms all the job scheduling and submission steps transparently to the end user\nand adapts job execution to changing Grid conditions by providing fault recov ery\nmechanisms\, dynamic scheduling\, migration on-request and opportunis tic migration [3].\nThis scheduling is performed using the data gathered f rom the Information System\n(GLUE schema) that is part of the LCG-2 infras tructure.\n\nGridWay performs the job execution in three simple steps: Pro log\, which prepares the\nremote system by creating an experiment director y and transferring the needed files.\nWrapper\, which executes the actual job and obtains its exit status code. And Epilog\,\nwhich finalizes the re mote system by transferring the output back and cleaning up the\nexperimen t directory.\n\nAfter performing different experiments in similar conditio ns\, we obtained the\nfollowing results. The overall time was 65.33 minute s. The average execution time was\n10.06 minutes and its standard deviatio n was 4.32 minutes (this was almost the same\nwith the pilot application). The average transfer time was 0.92 minutes and its\nstandard deviation wa s 0.68 minutes (this was higher because of the submission of the\nProlog a nd Epilog scripts). The average overhead was 22.32 minutes (this was lower as\nless elements were taking part in the scheduling process). And finall y\, the\nproductivity was 45.92 rays/hour.\n\nThe reason for this higher p roductivity is that GridWay reduces the number of nodes\nand stages the jo b passes through. Also\, this productivity is the result of GridWay's\nopp ortunistic migration and fault tolerance mechanisms.\n\nAs a key improveme nt needed to better exploit this technique on EGEE we can find that\nthe d ata contained in the Information System should be updated more frequently and\nshould represent the real situation of the remote resource when tryin g to submit a\njob to it. This is a commitment between the resource admini strator and the rest of\nthe EGEE community. \n\nThe last aspect we would like to notice is the difference between the LCG-2 API and\nDRMAA. While t he LCG-2 API relays on a specific middleware\, DRMAA (which is a GGF\nstan dard) doesn't. The scope of this user API specification is all the high le vel\nfunctionality which is necessary for an application to consign a job to a DRM system\,\nincluding common operations on jobs like synchronizatio n\, termination or suspension.\nIn case this abstract is accepted\, we wou ld like to perform an on line demonstration.\n\n\nREFERENCES:\n[1] Massive Ray Tracing in Fusion Plasmas: Memorandum of Understanding. Francisco\nCa stejón. CIEMAT. Spain.\n[2] Electron Bernstein Wave Heating Calculations for TJ-II Plasmas. Francisco\nCastejón\, Maxim A. Tereshchenko\, et al. A merican Nuclear Society. Volume 46\, Number\n2\, Pages 327-334\, September 2004.\n[3] A Framework for Adaptive Execution on Grids. E. Huedo\, R. S. Montero and I. M.\nLlorente. Software - Practice & Experience 34 (7): 631- 651\, June 2004.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId =64&sessionId=10&confId=286 LOCATION:CERN 40-5-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=64&sessionId=10 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:G-PBox: A framework for grid policy management DTSTART;VALUE=DATE-TIME:20060302T160000Z DTEND;VALUE=DATE-TIME:20060302T163000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-65@cern.ch DESCRIPTION:Speakers: Mr. CALTRONI\, Andrea (INFN)\nSharing computing and storage resources among multiple Virtual Organizations which\ngroup people from different institutions often spanning many countries\, requires a\n comprehensive policy management framework.\nThis paper introduces G-PBox\, a tool for the management of policies which integrates\nwith other VO-bas ed tools like VOMS\, an attribute authority and DGAS an accounting\nsystem \, to provide a framework for writing\, administering and utilizing polici es in a\nGrid environment.\n\nhttp://indico.cern.ch/contributionDisplay.py ?contribId=65&sessionId=15&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=65&sessionId=15 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:BioDCV: a grid-enabled complete validation setup for functional pr ofiling DTSTART;VALUE=DATE-TIME:20060301T134500Z DTEND;VALUE=DATE-TIME:20060301T140000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-66@cern.ch DESCRIPTION:Speakers: PAOLI\, Silvano (ITC-irst)\nAbstract\nBioDCV is a di stributed computing system for the complete validation of gene\nprofiles. The system is composed of a suite of software modules that allows the\ndef inition\, management and analysis of a complete experiment on DNA microarr ay data.\nThe BioDCV system is grid-enabled on LCG/EGEE middleware in orde r to build \npredictive\nclassification models and to extract the most imp ortant genes on large scale\nmolecular oncology studies. Performances are evaluated on a set of 6 cancer\nmicroarray datasets of different sizes and complexity\, and then compared with \nresults\nobtained on a standard Lin ux cluster facility. \n\nIntroduction\nThe scientific objective of BioDCV is a large scale comparison of prognostic gene\nsignatures from cancer mic roarray datasets realized by a complete validation system\nand run in Grid . The models will constitute a reference experimental landscape for\nnew s tudies. Outcomes of BioDCV consist of a predictive model\, the straighforw ard\nevaluation of its accuracy\, the lists of genes ranked for importance \, the\nidentification of patient subtypes. Molecular oncologists from med ical research\ncenters and collaborating bioinformaticians are currently t he target end-users of\nBioDCV. The comparisons presented in this paper de monstrate the factibility of this\napproach on public data as well as on o riginal microarray data from IFOM-Firc. The\ncomplete validation schema de veloped in our system involves an intensive replication\nof a basic classi fication task on resampled versions of the dataset. About 5x105 \nbase\nmo dels are developed\, which may become 2x106 if the experiment is replicate d with\nrandomized output labels. The scheme must ensure that no selection bias effect is\ncontaminating the experiment. The cost of this caution is high computational \ncomplexity. \n\nPorting to the Grid\nTo guarantee fa st\, slim and robust code\, and relational access to data and a model\ndes criptions\, BioDCV was written in C and interfaced with SQLite\n(http://ww w.sqlite.org)\, a database engine which supports concurrent access and\ntr ansactions useful in a distributed environment where a dateset may be repl icated\nfor up to a few million models. In this paper\, we present the por ting of our\napplication to grid systems\, namely the Egrid (http://www.eg rid.it) computational\ngrids. The Egrid infrastructure is based on Globus/ EDG/LCG2 middleware and is\nintegrated as an independent virtual organizat ion within Grid.it\, the INFN \nproduction\ngrid. The porting requires jus t two wrappers\, one shell script to submit jobs and \none\nC MPI program. When the user submits a BioDCV job to the grid\, the grid middleware\nloo ks for the CE (Computing Element: where user tasks are delivered) and the WNs\n(Worker Nodes: machines where the grid user programs are actually exe cuted) require\nto run the parallel program. As soon as the resources (CPU s in WNs) are available\,\nthe shell script wrapper is executed on the ass igned CE. This script distributes the\nmicroarray dataset from the SE (Sto rage Element stores user data in the grid) to all\nthe involved WNs. It th en starts the C MPI wrapper which spawns several instances of\nthe BioDCV program itself. When all BioDCV instances are completed\, the wrapper\ncop ies all outputs including model and diagnostic data from the WNs to the st arting\nSE. Finally\, the process outputs are returned\, thus allowing the reconstruction of a\ncomplete data archive for the study.\n\nExperiments and results\nTwo experiments were designed to measure the performance of t he BioDVC parallel\napplication in two different computing available envir onments: a standard Linux\ncluster and a computational grid.\nIn Benchmark 1\, we study the scalability of our application as a function of the\nnum ber of CPUs. The benchmark is executed on a Linux clusters formed by 8 Xeo n 3.0\nCPUs and on the EGEE grid infrastructure ranging from 1 to 64 Xeon CPUs. Two DNA\nmicroarray datasets are considered: LiverCanc (213 samples\ , ATAC-PCR\, 1993 genes) \nand\nPedLeuk (327 samples\, Affymetrix\, 12625 genes). On both dataset we obtain a speed-up\ncurve very close to linear. The speed-up factor for n CPUs is defined as the user\ntime for one CPU di vided by the user time for n CPUs.\nIn Benchmark 2\, we characterize the B ioDCV application different d (number of\nfeatures) and N (number of sampl es) values for a complete validation experiment\, and\nwe execute a task f or each dataset on the EGEE grid infrastructure using a fixed\nnumber of C PUs. The benchmark was run on a suite of six microarray datasets:\nLiverCa nc\, PedLeuk\, BRCA (62 samples\, cDNA\, 4000 genes)\, Sarcoma (35 samples \, cDNA\,\n7143 genes)\, Wang (286 samples\, Affymetrix\, 17816 genes)\, C hang (295 samples\, cDNA\,\n25000 genes). It can be observed that effectiv e execution time (total execution time\nwithout queueing time at grid site ) increases linearly with the dataset footprint\,\ni.e. the product of num ber of genes and number of samples. The performance penalty\npayed with re spect to a standard parallel run performed on local cluster is limited\nan d it is mainly due to data transfer from user machine to grid site and bet ween \nWNs. \n\nDiscussion and Conclusions\nThe two experiments\, which su m up to 139 CPU days within the Egrid infrastructure\,\nimplicate that gen eral behavior of the BioDCV system on LCG/EGEE computational grids\ncan be used in practical large scale experiments. The overall effort for\ngridif ication was limited to three months. We will investigate if substituting a \nmodel of one single job asking for N CPUs (MPI approach) with a model th at submits N\ndifferent single CPU jobs can overcome some limitations. Nex t step is porting our\nsystem under EGEE's Biomed VO. \n\nBioDCV is an ope n source application and it is currently distributed under GPL\n(SubVersio n repository at http://biodcv.itc.it).\n\nhttp://indico.cern.ch/contributi onDisplay.py?contribId=66&sessionId=9&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=66&sessionId=9& confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Solid Earth Physics on EGEE DTSTART;VALUE=DATE-TIME:20060301T160000Z DTEND;VALUE=DATE-TIME:20060301T161500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-67@cern.ch DESCRIPTION:Speakers: MOGUILNY\, Geneviève (Institut de Physique du Globe de Paris)\nThis abstract describes the "Solid Earth Physics" applications of the ESR(Earth \nScience Research) VO. These applications\, developed o r ported by the "Institut de \nPhysique du Globe de Paris" (IPGP) address mainly seismology\, data processing as \nwell as simulation.\nSolid Earth Physics deployed successfully two applications on EGEE. \nThe first one al lows the rapid determination of earthquake mechanisms\,\nand the second o ne\, SPECFEM3D\, allows numerical simulation of earthquakes \nin complex t hree-dimensional geological models.\nA third application\, currently being ported\, will allow gravity gradiometry\nstudies from GOCE satellite data .\n\n1) Rapid determination of Earthquake centroid moment tensor (E. Clév édé\, IPGP)\n\nThe goal of this application is to provide first order in formations\non seismic source for large Earthquakes occurring worldwide.\n These informations are: the centroid\, which corresponds to the location\n of the space-time barycenter of the rupture\; the first moments of\nthe ru pture in the point-source approximation\,\nwhich are the scalar moment giv ing the seismic energy released\n(from which the moment magnitude is deduc ed)\, the source duration\, \nand the moment tensor that describes the glo bal mechanism of the source\n(from which is deduced the orientation of the rupture plane\nand the kind of displacement on this plane).\nThe data use d are three-components long-period seismic signals\n(from 1 to 10 MHz) rec orded worldwide. In the case of a 'rapid' determination\nwe use data from the GEOSCOPE network that allows us to obtain\nrecords from a dozen of sta tions within a few hours after the occurrence\nof the event.\nIn order to deal with the trade-off between centroid and moment tensor\ndeterminations \, the centroid and the source duration are estimated\nby an exploration o ver\na space-time grid (longitude\, latitude\, depth and source duration). \nWhen the centroid is supposed to be known and fixed\, the relation betwe en\nthe moment tensor and the data is linear.\nThen\, for each point of th e centroid parameter space\, we compute\nGreen functions (one for each of the 6 elements of the moment tensor)\nfor each receiver\, and proceed to l inear inversions in the spectral\ndomain\, for each different source durat ions.\nThe best solution is determined by the data fit.\n\nThis applicatio n is well adapted to the EGEE grid\, as each point of the\ncentroid parame ter space can be treated independently\, the main part\nof the time comput ation being the Green functions computation.\nFor a single point\, a run i s performed in a few minutes.\nIn a typical case\, an exploration\ngrid (l ongitude\, latitude\, depth and source duration) of 10x10x10x10\nrequires about 100h of time computation\, which is reduced to about 1 hour\nover a hundred different jobs submitted to the EGEE grid.\n\nThe new features for workflow provided by gLite should allow the simplification \nof the manag ement of the different steps of a run.\n\n2) SPECFEM3D: Numerical simulati on of earthquakes in complex three-dimensional \ngeological models (D. Kom atitsch MIGP\; G. Moguilny\, IPGP)\n\nThe spectral-element method (SEM) fo r regional scale seismic wave\npropagation problems is used to model wave propagation at high\nfrequencies and for complex geological structures. \n Simulations based upon a detailed sedimentary basin model and this\naccura te numerical technique produce generally nice waveform fits\nbetween the d ata and 3-D synthetic seismograms. Moreover\, remaining\ndiscrepancies bet ween the data and synthetic seismograms could\nultimately be utilized to i mprove the velocity model based upon a\nstructural inversion\, or the sour ce parameters based upon a centroid\nmoment-tensor (CMT) inversion.\n\nThi s application\, written in Fortran 90 and using MPI\, is very\nscalable an d already ran outside EGEE on 1994 processors in the Japanese\nEarth Simu lator\, and inside EGEE on 64 processors at Nikhef (NL).\n\nThe amount of disk space and memory depend on the input parameters but are\nnever very l arge. However\, this application\nhas some technical constraints : the I/ O have to be done\nin local files (on each node) and on shared files (seen by all nodes)\,\nand the script must be able to submit 2 executable files sequentially\, \nwhich use the same nodes in the same order. This\nis be cause the SPECFEM3D software package consists of two different\ncodes\, a mesher and a solver\, which work on the same data.\n\nSome successful test s have been done with gLite but the problem of\ndifferentiate a node (with several CPUs) and a CPU when\nrequiring the resources\, doesn't seem to b e solved.\n\nIt also will be interesting to have access to "fast clusters" (with\nhigh throughput and low latency networks\, as Myrinet\, SCI...)\,\ nand\, to access larger configurations\, by having the possibility\nto acc ess various sites during a given run.\n\n3) Gravity gradiometry (G. Pajot\ , IPGP)\n\nThe GOCE satellite (see [1]) is to be launched by the European Space Agency\nby the end of this year. Onboard is an instrument\, called a gradiometer\,\nwhich measures the spatial derivatives of the gravity fiel d in three\nindependent directions of space. Although gravity gradiometry was born more\nthan a century ago and successfully used for geophysical pr ospecting\, GOCE\nsatellite will provide the first set of gravity gradiome try data on the\nwhole Earth with unprecedented spatial resolution and acc uracy and specific\nmethods have to be developed. Thanks to these data\, w e will be able to\nderive information about the Earth inner mass distribut ion patterns at\nvarious scales (from the sedimentary basin to the Earth's Mantle).\n\nTo this aim\, we develop a pseudo Monte Carlo inversion metho d (see [2]) to\ninterpret GOCE data. One step of it is the model generatio n\, which is the\nlimiting factor of it. A model is a possible density dis tribution\, to which\ncorrespond calculated gravity gradients as they woul d be measured by the\ninstrument. These calculated gradients are compared to those actually\nmeasured\; the nearer they are from measured ones\, the closer the model is\nfrom real Earth. One rough pseudo random model takes about 5 minutes to be\ngenerated on a 2.8 GHz CPU\, finest ones generatio n reaches 20 minutes and a\nset of 1000 models is a good basis to start th e model space exploration\,\neach one being independent from the others. T hus\, EGEE is the perfect frame\nto develop such an application. We test a nd validate our algorithm using a\nset of marine gradiometry measurements provided by the Bell Geospace\nCompany. These data need a frequent restric ted access. First results of the\napplication and solutions to the confide ntiality problem are exposed here.\n\nReferences:\n[1] http://ganymede.ipg p.jussieu.fr/frog/\n[2] Geophysical Inversion with a Neighbourhood Algorit hm -I.\nSearching a parameter space\,* Sambridge\, M.\, *Geophys. J. Int.\ , **138 *\,\n479-494\, 1999.\n\nIn conclusion\, the main goal of these thr ee applications is to create a \nGrid-based infrastructure to process\, va lidate and exchange large sets of data\nwithin the worldwide Solid Earth p hysics community as well as to provide\nfacilities for distributed computi ng. The stability of the\ninfrastructure and the easiness to use the Grid are prerequisites\nto reach these objectives and bring the community to us e the Grid facilities.\n\nhttp://indico.cern.ch/contributionDisplay.py?con tribId=67&sessionId=11&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=67&sessionId=11 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Diligent and OpenDLib: long and short term exploitation of a gLite Grid Infrastructure DTSTART;VALUE=DATE-TIME:20060301T131500Z DTEND;VALUE=DATE-TIME:20060301T133000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-68@cern.ch DESCRIPTION:Speakers: Dr. BERNARDINI\, Davide (CNR-ISTI)\nThe demand for D igital Libraries has recently grown considerably\, DLs are perceived \nas a necessary instrument to support communication and collaboration among th e \nmembers of communities of interest\; many application domains require DL services\, \ne.g. e-Health\, e-Learning\, e- Government\, and many of t he organizations that demand \na DL are small\, distributed\, and dynamic\ , because they use the DL to support \ntemporary activities such as course s\, exhibitions\, projects\, etc.\nNowadays the construction and managemen t of a DL requires high investments and \nspecialized personnel because th e content production is very expensive and \nmultimedia handling requires high computational resources. The effect are that \nyears are spent in des igning and setting up a DL and that the DL systems lack \ninteroperability and the services provided are difficult to reuse.\nThis development model is not suitable to satisfy the demand of many organizations\, \nso the pu rpose of DILIGENT is to create a Digital Library Infrastructure that will \nallow members of dynamic virtual research organizations to create on-dem and \ntransient digital libraries based on shared computing\, storage\, mu ltimedia\, multi-\ntype content\, and application resources. Following thi s vision Digital libraries \nare not ends in themselves\; rather they are enabling technologies for digital asset \nmanagement\, electronic commerce \, electronic publishing\, teaching and learning\, and \nother activities. \nDILIGENT is a is a three-year European funded project that aims at devel oping a \ntest-bed DL infrastructure able to create a multitude of DLs on- demand\, manage the \nresources of a DL (possibly provided by multiple org anizations)\, and operate the DL \nduring its lifetime. These DLs created by DILIGENT will be active on the same set \nof shared resources: content sources (i.e. repositories of information searchable \nand accessible)\, s ervices (i.e. software tools\, that implement a specific \nfunctionality a nd whose descriptions\, interfaces and bindings are defined and \npublicly available) and hosting nodes (i.e. networked entities that offer computin g \nand storage capabilities and supply an environment for hosting content sources and \nservices).\nBy exploiting appropriate mechanisms provided b y the DL infrastructure\, producer \norganizations register their resource s and provide a description of them. The \ninfrastructure manages the regi stered resources by supporting their discovering\, \nreservation\, monitor ing and by implementing a number of functionalities that aim at \nsupporti ng the required controlled sharing and quality of service.\nThe compositio n of a DL is dynamic since the services of the infrastructure \ncontinuous ly monitor the status of the DL resources and\, if necessary\, change the \ncomponents of the DL in order to offer the best quality of service. By r elying on \nthe shared resources many DLs\, serving different communities\ , can be created and \nmodified on-the-fly\, without big investments and c hanges in the organizations that \nset them up.\nThe DILIGENT infrastructu re is being constructed by implementing a service oriented \narchitecture in a Grid framework. The DILIGENT design will be service oriented in \nord er to provide as many reusable components as possible for other e-applicat ions \nthat could be created on top of the basic DILIGENT infrastructure. Furthermore\, \nDILIGENT exploits the Grid middleware\, gLite\, and the Gr id production \ninfrastructure released by the Enabling Grid for E-Science in Europe (EGEE) \nproject. By merging a service-oriented approach with a Grid technology we can \nexploit the advantages of both. In particular\, the Grid provides a framework where \na good control of the shared resourc es is possible. By taking full advantage of the \nscalable\, secure\, and reliable Grid infrastructure each DL service will provide an \nenhanced fu nctionality with respect the equivalent non-Grid-aware service. \nMoreover \, the gLite Grid enables the execution of very computational demanding \n applications\, such as those required to process multimedia content. DILIG ENT will \nenhance existing Grid services with the functionality needed to support the complex \nservices interactions required to build\, operate a nd maintain transient virtual \ndigital libraries.\nIn order to support th e services of the DILIGENT framework and the user community \nexpectations some key Grid services are needed: the Grid infrastructure should \nsuppo rt a cost-effective DL operational model based on transient\, flexible\, \ ncoordinated “sharing of resources”\, address the main DL architectur e requirements \n(distribution\, openness\, interoperability\, scalability \, controlled sharing\, \navailability\, security\, quality)\, provide a b asic common infrastructure for serving \nseveral different application dom ains and offer high storage and computing \ncapabilities that enable the p rovision of powerful functionality on multimedia \ncontent e.g. images and videos.\nFrom the conceptual point of view the services that implement th e DILIGENT \ninfrastructure are organized in a layered architecture.\nThe top layer\, i.e. the Presentation layer\, is user-oriented. It supports th e \nautomatic generation of user-community specific portals\, providing pe rsonalized \naccess to the DLs.\nThe Workflows layer contains services tha t make it possible to design and verify \nthe specification of workflows\, as well as services ensuring their reliable \nexecution and optimization. Thanks to these set of services it is possible to \nexpand the infrastruc ture with new and complex services capable to satisfy \nunpredicted user n eeds.\nThe DL Components layer contains the services that provide the DL f unctionalities. \nKey functionalities provided by this area are: managemen t of metadata\; \nautomatically translation for achieving metadata interop erability among disparate \nand heterogeneous content sources\; content se curity through encryption and \nwatermarking\; archive distribution and vi rtualization\; distributed search\, access\, \nand discovery\; annotation\ ; cooperative work through distributed workspace \nmanagement.\nThe servic es of the lower architectural layer\, the Collective Layer\, jointly with \nthose provided by the gLite Grid middleware released by the EGEE project \, manage \nthe resources and applications needed to run DLs. The set of r esources and the \nsharing rules are complex since multiple transient DLs are created on-demand and \nare activated simultaneously on these resource s.\nFollowing the first tests performed on the first releases of the gLite middleware \nthe following Grid requirements were identified: it should b e possible to query for \nthe maximum number of CPUs concurrently availabl e in order to allow to a DILIGENT \nhigh level service to automatically pr epare a DAG where each node will be entitled \nto process a partition of t he data collection\, to use parametric jobs/automatic \npartitioning on da ta\, to support service certificate for a high level service\, to \nspecif y a job specific priority\, to specify a priority for a user or for a serv ice\, \nto ask for on-disk encryption of data\, to dynamically manage VO c reation and to \ndynamically support user/service affiliation to a VO.\nDI LIGENT will be demonstrated and validated by two complementary real-life \ napplication scenarios: one from the culture heritage domain\, one from th e \nenvironmental e-Science domain. The former is an interesting challenge thanks to \nthe multidisciplinary collaborative research\, the image base d retrieval\, the \nsemantic analysis of images\, and the support for rese arch and teaching. The latter \nobliges DILIGENT to manage a wide variety of content types (maps\, satellite images\, \netc.) with very large\, dyna mic data sets in order to support community events\, \nreport generation\, disaster recovery.\nThe DILIGENT project collaborates with EGEE mainly th rough technical interactions \n(technical meetings (mainly with JRA1)\, gL ite mailing lists subscription\, tutorial) \nand feedback on EGEE activiti es and on DILIGENT project (gLite bugs submission and \ngrid related DL re quirements).\nNow DILIGENT has two independent infrastructures (gLite v1.4 ): a Development \nInfrastructure (DDI) and a Testing infrastructure (DTI) . These infrastructures are \ngeographically distributed\, linking 6 sites in Athens\, Budapest\, Darmstadt\, Pisa\, \nInnsbruck and Rome. We are ru nning gLite experimentation tests on these \ninfrastructures since July 20 05 and we collected some useful data about data and \njob management. \nAs first approach to exploit the gLite Grid storing and processing on demand \ncapabilities\, we developed two experimental brokers that\, starting fr om an existing \ndigital library management system\, named OpenDLib\, allo w interfacing the DDI. \nThe gLite SE broker provides OpenDLib services wi th the pool of SEs available via \nthe gLite software. Moreover\, it optim izes the usage of the available SEs. In \nparticular\, this service interf aces the gLite I/O server to perform the storage \n(put) and withdrawal (r m) of files and the access to them (get). In designing this \nservice one of our main goals was to provide a workaround to two main problems\, \ni.e . inconsistence between catalog and storage resource management systems\, and \nfailure without notification in the access or remove operations. Alt hough the gLite \nSE broker could not improve the reliability of the reque sted operations we designed \nit in such a way to: (i) monitor its request s\, (ii) verify the status of the \nresources after the processing of the operations\, (iii) repeat the registration in \nthe catalog and/or storage of the file until it is considered correct or \nunrecoverable\, (iv) retu rn a valid message reporting the exit status of the \noperation. \nThe gLi te WMS wrapper provides to the other OpenDLib services with the computing \npower supplied by gLite CEs. Actually\, the goal of this service is to p rovide an \nhigher level interface than those provided by the gLite compon ents for managing \njobs\, i.e. applications that can run on CEs\, and DA Gs\, i.e. direct acyclic graphs \nof dependent jobs. The gLite WMS broker has therefore been designed to: (i) deal \nwith more than one WMS\, (ii) m onitor the quality of service provided by these WMSs \nby analyzing the nu mber of managed jobs and the average time of their execution\, \nand\, fin ally\, (iii) monitor the status of each submitted job querying the Logging \nand Bookkeeping (LB) service.\n\nhttp://indico.cern.ch/contributionDisp lay.py?contribId=68&sessionId=11&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=68&sessionId=11 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:BIOINFOGRID: Bioinformatics Grid Application for life science DTSTART;VALUE=DATE-TIME:20060301T133000Z DTEND;VALUE=DATE-TIME:20060301T134500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-69@cern.ch DESCRIPTION:Speakers: Dr. MILANESI\, Luciano (National Research Council - Institute of Biomedical Technologies)\nProject descriptions\n\nThe Europea n Commission promotes the Bioinformatics Grid Application for life \nscien ce (BIOINFOGRID) project. The BIOINFOGRID project web site will be availab le at \nhttp://www.itb.cnr.it/bioinfogrid.\n \nThe project aims to connect many European computer centres in order to carry out \nBioinformatics res earch and to develop new applications in the sector using a \nnetwork of s ervices based on futuristic Grid networking technology that represents \nt he natural evolution of the Web.\n\nMore specifically the BIOINFOGRID proj ect will make research in the fields of \nGenomics\, Proteomics\, Transcri ptomics and applications in Molecular Dynamics much \neasier\, reducing da ta calculation times thanks to the distribution of the \ncalculation at an y one time on thousands of computers across Europe and the world. \n\nFurt hermore it will provide the possibility of accessing many different databa ses \nand hundreds of applications belonging to thousands of European user s by exploiting \nthe potential of the Grid infrastructure created with th e EGEE European project and \ncoordinated by CERN in Geneva. \n\nThe BIOI NFOGRID project foresees an investment of over one million euros funded \n through the European Commission’s “Research Infrastructures” budget. \nGrid networking promises to be a very important step forward in the In formation \nTechnology field. Grid technology will make a global network made up of hundreds of \nthousands of interconnected computers possible\, allowing the shared use of \ncalculating power\, data storage and structur ed compression of data. This goes \nbeyond the simple communication betwe en computers and aims instead to transform the \nglobal network of compute rs into a vast joint computational resource.\n\nGrid technology is a very important step forward from the Web\, that simply allows \nthe sharing of information over the internet. The massive potential of Grid \ntechnology will be indispensable when dealing with both the complexity of models and \nthe enormous quantity of data\, for example\, in searching the human ge nome or when \ncarry out simulations of molecular dynamics for the study o f new drugs. \n\n\nThe grid collaborative and application aspects. \n\nTh e BIOINFOGRID projects proposes to combine the Bioinformatics services and \napplications for molecular biology users with the Grid Infrastructure c reated by \nEGEE (6th Framework Program). In the BIOINFOGRID initiative we plan to evaluate \ngenomics\, transcriptomics\, proteomics and molecular dynamics applications studies \nbased on GRID technology.\n\nGenomics Appl ications in GRID\n• Analysis of the W3H task system for GRID.\n• GRID analysis of cDNA data.\n• GRID analysis of the NCBI and Ensembl database s.\n• GRID analysis of rule-based multiple alignments.\nProteomics Appli cations in GRID\n• Pipeline analysis for domain search for protein funct ional domain analysis.\n• Surface proteins analysis in GRID platform.\nT ranscriptomics and Phylogenetics Applications in GRID \n• Data analysis specific for microarray and allow the GRID user to store and \nsearch this information\, with direct access to the data files stored on Data Storage \nelement on GRID servers.\n• To validate an infrastructure to perform Application of Phylogenetic based \non execution application of Phylogenet ic methods estimates trees.\nDatabase and Functional Genomics Applications \n• To offer the possibility to manage and access biological database by using \nthe GRID EGEE.\n• To cluster gene products by their functionali ty as an alternative to the \nnormally used comparison by sequence similar ity.\nMolecular Dynamics Applications\n• To improve the scalability of M olecular Dynamics simulations.\n• To perform simulation folding and aggr egation of peptides and small \nproteins\, to investigate structural prope rties of proteins and protein-DNA complexes \nand to study the effect of m utations in proteins of biomedical interest.\n• To perform a challenge o f the Wide In Silico Docking On Malaria.\n\n\nEGEE and EGEEII future plan\ n\nBIOINFOGRID will evaluate the Grid usability in wide variety of applica tions\, the \naim to build a strong and unite BIONFOGRID Community and exp lore and exploit common \nsolutions.\nThe BIOINFOGRID collaboration will b e able to establish a very large user group in \nBioinformatics in EUROPE. This cooperation will be able to promote the \nBioinformatics and GRID ap plications in EGEE and EGEEII. The aim of the BIOINFOGRID \nproject is to bridge the gap\, letting people from the bioinformatics and life \nscience be aware of the power of Grid computing just trying to use it. We intend to \npursue this goal by using a number of key bioinformatics applications and getting \nthem run onto the European Grid Infrastructure. \nThe most natural and important spin off of the BIOINFOGRID project will then be a \ nstrong dissemination action within the user’s communities and across th em. In fact\, \nfrom one side application’s experts will meet Grid exper ts and will learn how to re-\nengineer and adapt their applications to “ run on the Grid” and\, from the other side \n(and at the same time)\, ap plication’s experts will meet other-applications’ experts \nwith a hig h probability that ones’ expertises can be exploited as others’ solut ions.\nThe BIOINFOGRID project will provide the EGEEII with very useful in puts and \nfeedbacks on the goodness and efficiency of the structure deplo yed and on the \nusefulness and effectiveness of the Grid services made av ailable at the continental \nscale. In fact\, having several bioinformatic s scientific applications using these \nGrid services is a key moment to s tress the generality of the services themselves.\n\nhttp://indico.cern.ch/ contributionDisplay.py?contribId=69&sessionId=9&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=69&sessionId=9& confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:The Grid and the Biomedical community: achievements and open issue s DTSTART;VALUE=DATE-TIME:20060301T093500Z DTEND;VALUE=DATE-TIME:20060301T102000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-2@cern.ch DESCRIPTION:Speakers: MAGNIN\, Isabelle (INSERM Lyon)\n \n\nhttp://indico .cern.ch/contributionDisplay.py?contribId=2&sessionId=8&confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=2&sessionId=8&c onfId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Worldwide ozone distribution by using Grid infrastructure DTSTART;VALUE=DATE-TIME:20060301T153000Z DTEND;VALUE=DATE-TIME:20060301T154500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-99@cern.ch DESCRIPTION:Speakers: PETITDIDIER\, Monique (IPSL)\nESRIN : L. Fusco\, J. Linford\, C. Retscher\nIPSL : C. Boonne\, S. Godin-Beekmann\, M. Petitdidi er\, D. Weissenbach\nKNMI: W. Som de Cerff\nSCAI-FHG: J. Kraus\, H. Schwic htenberg\nUTV : F. Del Frate\, M. Iapaolo\n\nSatellite data processing pre sents a challenge for any computer resources due to \nthe large volume of data and number of files. The vast amount of data sets and \ndatabases are all distributed among different countries and organizations. The \ninvest igation of such data is limited to some sub-sets. As a matter of fact\, al l \nthose data cannot be explored completely due on one hand to the limita tion in local \ncomputer and storage power\, and on the other hand to the lack of tools adapted to \nhandle\, control and analyse efficiently so lar ge sets of data. \nIn order to check the capability of a Grid infrastructu re to fill those \nrequirements\, an application based on ozone measuremen ts was designed to be ported \nfirst on DataGrid\, then on EGEE and local Grid in ESRIN.\nThe satellite data are provided by the experiment\, GOME a board the satellite ERS. \nFrom the ozone vertical total content\, ozone p rofiles have been retrieved by using \ntwo different algorithm schemas\, o ne is based on an inversion protocol (KNMI)\, the \nother on a neural netw ork approach (UTV). The porting on DataGrid was successful \nhowever some functionalities are missing to make the application operational. In \nEGEE \, the reliability of the infrastructure has been as reliable as a local G rid. \nThe second part of the application has been the validation of those satellite ozone \nprofiles by profiles measured by ground-based lidars. T he goal was to find out \ncollocated observations meta databases were buil t to solve this problem. The result \nhas been the production of the 7 yea rs of data on EGEE and on local Grid at ESRIN \nwith two versions of the N eural Network algorithm and several months by the \ninversion algorithm. It is an amount of around 100 000 files registered on EGEE. \nThen\, the v alidation of this set of data was carried out by using all the lidar \npro files available in the NDSC databases (Network Detection of Stratospheric \nChanges). To find collocation data an OGSA-DAI metadata server has been implemented \nand geospatial queries permit to search the orbit passing ov er the lidar site.\nThe second work\, started during DataGrid\, has been t he development of a portal\, \nspecific to the Ozone application\, describ ed above\, and extended latter to other \nsatellite data like Meris…The role of this portal is to provide an operational way \nto a friendly end-u se of Grid infrastructure. It provides the missing \nfunctionalities of th e Grid infrastructure.\nEGEE offers the possibility to store all the ozone data obtained by satellite \nexperiment (GOME\, GOMOS\, MIPAS…) as well as ground-based network of lidars and \nradiosoundings… The next goal o n the way is to be able to find out at a given \nlocation and/or at a give n time the distribution of ozone by combining all the \nexisting databases . \nIn this presentation\, the scientific and operational interest will be pointed out.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=99 &sessionId=11&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=99&sessionId=11 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Replication on the AMGA Metadata Catalogue DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-98@cern.ch DESCRIPTION:Speakers: DE SOUSA SANTOS\, Nuno Filipe (Universidade de Coimb ra)\n1. Introduction\n\nMetadata Services play a vital role on Data Grids\ , primarily as a means of \ndescribing and discovering data stored on file s but also as a simplified database \nservice. They must\, therefore\, be accessible to the entire Grid\, comprising several \nthousands of users sp read across hundreds of Grid sites geographically distributed. \nThis mean s they must scale with the number of users\, with the amount of data store d \nand also with geographical distribution\, since users in remote locati ons should have \nlow-latency access to the service. Metadata Services mus t also be fault-tolerant to \nensure high-availability.\n\nTo satisfy such requirements\, Metadata Services must offer flexible replication and \ndi stribution mechanisms especially designed for the Grid environment. They m ust cope \nwith the heterogeneity and dynamism of a Grid\, as well as the typical workloads.\n\nTo address these requirements\, we are building repl ication and federation mechanisms \ninto AMGA\, the gLite Metadata catalog ue. These mechanisms work at the middleware \nlevel\, providing database i ndependent replication\, especially suited for \nheterogeneous Grids. We u se asynchronous replication for scalability on wide-area \nnetworks and im proved fault-tolerance. Updates are supported on the primary copy\, \nwith replicas being read-only. For flexibility\, AMGA supports partial replica tion \nand federation of independent catalogues\, allowing applications to tailor the \nreplication mechanisms to their specific needs.\n\n\n2. Use Cases\n\nReplication on AMGA is designed to cover a broad range of usage s cenarios that are \ntypical of the main user communities of EGEE. \n\nHigh Energy Physics (HEP) applications are characterised by large amounts of \ nread-only metadata\, produced on a single location and accessed by hundre ds of \nphysicists spread across many remote sites. By using AMGA replicat ion mechanisms\, \nremote Grid sites can create local replicas of the meta data they require\, \neither of the whole metadata tree or of parts of it. Users at remote sites \nwill experience a much improved performance by ac cessing a local replica.\n\nFor Biomed applications the main concern with metadata is ensuring its security\, as \nit often contains sensitive infor mation about patients that must be protected from \nunauthorised users. Th is task is made more difficult by the existence of many grid \nsites produ cing metadata\, that is\, the different hospitals and laboratories where i t \nis generated. Creating copies on remote sites increases the security r isk and\, \ntherefore\, should be avoided. AMGA replication allows the fed eration of these Grids \nsites into a single virtual distributed metadata catalogue. Data is kept securely on \nthe site it was generated\, but user s can access it transparently from any AMGA \ninstance\, which discovers w here the data is located and redirects the request to \nthat AMGA instance \, where it will be executed after the user credentials have been \nvalida ted. \n\nWe believe that partial replication and federation as they are be ing implemented in\nAMGA provides the necessary building blocks for the di stribution needs of many other \napplications\, while at the same time off ering scalability and fault-tolerance.\n\n\n3. Current Status and Future W ork\n\nWe have implemented a prototype of the replication mechanisms of AM GA\, which is \ncurrently undergoing internal testing. Soon we will be rea dy to start working with \nthe interested communities\, with the goal of b etter evaluating our ideas and of \nobtaining user feedback to guide us th rough further development of the replication \nmechanisms.\n\nA clear user requirement that we will study is the dependability of the system\, \ninc luding mechanisms for detecting failures of replicas and for recovering fr om \nthose failures. If the failure is on a replica\, clients should be re directed \ntransparently to a different replica. If the failure is on the primary copy\, then \nthe remaining replicas should elect a new primary co py among themselves. All these \nmechanisms need an underlying discovery s ystem to allow replicas to locate and query \neach other\, as well as mech anisms for running distributed algorithms among the nodes \nof the system. \n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=98&sessionId=22 &confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=98&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:GPS@: Bioinformatics grid portal for protein sequence analysis on EGEE grid DTSTART;VALUE=DATE-TIME:20060301T130000Z DTEND;VALUE=DATE-TIME:20060301T131500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-91@cern.ch DESCRIPTION:Speakers: Dr. BLANCHET\, Christophe (CNRS IBCP)\, Mr. LEFORT\, Vincent (CNRS IBCP)\nOne of current major challenges in the bioinformatic s field is to derive valuable information from the complete \ngenome seque ncing projects\, which provide the bioinformatics community with a large n umber of unknown \nsequences. The first prerequisite step in this process is to access up-to-date sequence and 3D-structure \ndatabanks (EMBL\, GenB ank\, SWISS-PROT\, Protein Data Bank...) maintained by several bio-computi ng centres \n(NCBI\, EBI\, EMBL\, SIB\, INFOBIOGEN\, PBIL\, …). For effi ciency reasons\, sequences should be analyzed using the \nmaximal number o f methods on a minimal number of different Web sites. To achieve this\, we developed a \nWeb server called NPS@ [1] (Network Protein Sequence Analys is) that provides biologists with many of the \nmost common tools for prot ein sequence analysis through a classic Web browser like Netscape\, or thr ough a \nnetworked protein client software like MPSA [2]. Today\, the geno mic and post-genomic web portals available \nhave to deal with their local cpu and storage resources. That’s why\, most of the time\, the portal \ nadministrators put some restrictions on the methods and databanks availab le. Grid computing [3]\, as in the \nEuropean EGEE project [4]\, will be a viable solution to foresee these limitations and to bring computing \nres ources suitable to the genomic research field.\nNevertheless\, the current job submission process on the EGEE platform is relatively complex and uns uitable \nfor automation. The user has to install an EGEE user interface m achine on a Linux computer (or to ask for a \naccount on a public one)\, t o remotely log on it\, to init manually a certificate proxy for authentica tion reasons\, \nto specify the job arguments to the grid middleware using the Job Description Language (JDL) and then to \nsubmit the job through a command line interface. Next\, the grid-user has to check periodically th e resource \nbroker for the status of his job: “Submitted"\, "Ready"\, “Scheduled”\, “Running”\, etc. until the “Done” status. As a \ nfinal command\, he has to get his results with a raw file transfer from t he remote storage area to his local file \nsystem.\nThis mechanism is most of times off-putting scientist that are not aware of advanced computing t echniques. \nThus\, we decide to provide biologists with a user-friendly i nterface for the EGEE computing and storage \nresources\, by adapting our NPS@ web site. We have called this new portal GPS@ for “Grid Protein Seq uence \nAnalysis”\, and it can be reached online at http://gpsa.ibcp.fr\ , yet for experimental tests only. In GPS@\, we \nsimplify the grid analys is query: GPS@ Web portal runs its own EGEE low-level interface and provid es \nbiologists with the same interface that they are using daily in NPS@. They only have to paste their protein \nsequences or patterns into the co rresponding field of the submission web page. Then simply pressing the \n “submit” button launches the execution of these jobs on the EGEE platf orm. All the EGEE job submission is \nencapsulated into the GPS@ back offi ce: scheduling and status of the submitted jobs. And finally the result of \nthe bioinformatics jobs are displayed into a new Web page\, ready for o ther analyses or for results download in \nthe appropriate data format.\n\ n[1] NPS@: Network Protein Sequence Analysis. Combet C.\, Blanchet C.\, Ge ourjon C. et Deléage G. Tibs\, 2000\, \n25\, 147-150.\n[2] MPSA: Integrat ed System for Multiple Protein Sequence Analysis with client/server capabi lities. Blanchet \nC.\, Combet C.\, Geourjon C. et Deléage G. Bioinformat ics\, 2000\, 16\, 286-287.\n[3] Foster\, I. And Kesselman\, C. (eds.) : Th e Grid 2 : Blueprint for a New Computing Infrastructure\, (2004).\n[4] Ena bling Grid for E-sciencE (EGEE)\, online at www.eu-egee.org\n\nhttp://indi co.cern.ch/contributionDisplay.py?contribId=91&sessionId=9&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=91&sessionId=9& confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Encrypted File System on the EGEE grid applied to Protein Sequence Analysis DTSTART;VALUE=DATE-TIME:20060301T131500Z DTEND;VALUE=DATE-TIME:20060301T133000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-90@cern.ch DESCRIPTION:Speakers: Dr. BLANCHET\, Christophe (CNRS IBCP)\, Mr. MOLLON\, Rémi (CNRS IBCP)\nIntroduction\nBiomedical applications are pilot ones i n the EGEE project [1][2] and have their own virtual organization: the \n “biomed” VO. Indeed\, they have common security requirements such as e lectronic certificate system\, \nauthentication\, secured transfer\; but t hey have also specific ones such as fine grain access to data\, encrypted \nstorage of data and anonymity. Certificate system provides biomedical en tities (like users\, services or Web \nportals) with a secure and individu al electronic certificate for authentication and authorization management. \nOne key quality of such a system is the capacity to renew and revoke th ese certificates across the whole grid. \nBiomedical applications also nee d fine grain access (with Access Control Lists\, ACLs) to the data stored on the \ngrid: biologists and biochemists can then\, for example\, share d ata with colleagues working on the same \nproject in other places. Thus\, biomedical data need to be gridified with a high level of confidentiality because \nthey can concern patients or sensitive scientific/industrial exp eriments. The solution is then to encrypt the \ndata on the Grid storage r esources\, but to provide authorized users and applications with transpare nt and \nunencrypted access.\n\nBiological data and protein sequence analy sis applications\nBiological data and bioinformatics programs have both sp ecial formats and behaviors\, especially highlighted \nwhen they are used into a distributed computing platform such as grid [2].\nBiological data r epresent very large datasets of different nature\, from different sources\ , with heterogeneous \nmodels: protein three-dimensional structures\, func tional signatures\, expression arrays\, etc. Bioinformatics \nexperiences use numerous methods and algorithms to analyze whole biological data which are available to the \ncommunity [3]. For each domain of Bioinformatics\, they are several different high-quality\nprograms that are available for computing the same dataset in as many ways. But most bioinformatics \nprog rams are not adapted to distributed platform. One important disadvantage i s that they are only accessing \ndata with local file system interface to get the input data and to store their results\, an other one being that \n these data must be unencrypted.\n\nThe European EGEE grid\nThe Enabling Gr ids for E-sciencE project (EGEE) [4]\, funded by the European Commission\, aimed to build on \nrecent advances in grid technology and to develop a s ervice grid infrastructure such as described by Foster et \nal. at the end of 1990s [5].\nThe EGEE middleware provides grid users with a “user int erface” (UI) to launch a job. Among the components \nof the EGEE grid: t he “workload management system” (WMS) is responsible of job scheduling . The central \npiece is the scheduler (or “resource broker”) that det ermines where and when to send a job on the “computing \nelements” (CE ) and get data from the “storage elements” (SE). The “data managemen t system” (DMS) is a key \nservice for our bioinformatics applications. Having efficient usage of DMS will be synonymous of good \ndistribution of our protein sequence analysis applications. Inside the DMS\, the “repli ca manager system” (RMS) \nprovides users with data replica functionalit ies. But there is no available encryption service onto the \nproduction gr id of EGEE\, built upon the LCG2 middleware.\n\n“EncFile” encrypted fi le manager\nWe have developed the EncFile\, encrypted file management syst em\, to provide our bioinformatics applications \nwith facilities for comp uting sensitive data on the EGEE grid. The cipher algorithm AES (Advanced Encryption \nStandard) is used with 256 bits keys. And to bring fault tole rance properties to the platform\, we have also \napplied a M-of-N techniq ue described by Shamir for secret sharing [6]. We split a key into N share s\, each \nstored in a different server. To rebuild a key\, exactly M of t he N shares are needed. With less than M shares\, it \nis impossible to de duce several bits or even one of them.\nThe “EncFile” system is compos ed of these N key servers and one client. The client is doing the decrypti on of \nthe file for the legacy application\, and is the only component ab le to rebuild the keys\, securing their \nconfidentiality. The transfer of the keys between the M servers and the client is secured with encryption and \nmutual authentication. In order to determine user authorization\, th e EncFile client send the user proxy to \nauthenticate itself. Nonetheless \, to avoid that a malicious person creates a fake EncFile client (e.g. to retrieve \nkey shares)\, a second authentication is required with a speci fic certificate of the EncFile system.\nAs seen before\, most bioinformati cs programs are only able to access their data through local file system \ ninterface\, and also not encrypted. To answer to these 2 strong issues\, we have combined the EncFile client \nand the Parrot software [7]. The res ultant client (called Perroquet in Figure 1) acts as a launcher for \nappl ications\, catching all their standard IO calls and replacing them with eq uivalent remote calls to remote \nfiles. Perroquet understands the logical file name (LFN) locators of our biological resources onto the EGEE grid\, \nand do on-the-fly decryption. This has mainly two consequences: (i) hig her security level because decrypted \nfile copies could endanger data\, ( ii) better performances because files aren't read twice to locally copy an d to \ndecrypt.\nThus\, the EncFile client permits any applications to tra nsparently read and write remote files\, encrypted or \nnot\, as if they w ere local and plain-text files. We are using EncFile system to secure sens itive biological data \non the EGEE production platform and to analyze the m with world-famous legacy bioinformatics applications \nsuch as BLAST\, S Search or ClustalW.\n\nConclusion\nWe have developed the EncFile system fo r encrypted files management\, and deployed it on the production \nplatfor m of the EGEE project. Thus\, we provided grid users with a user-friendly component that doesn’t \nrequire any user privileges\, and is fault-tole rant because of the M-of-N technique\, used to deploy key shares \non seve ral key servers. The EncFile client provides legacy bioinformatics applica tions with remote data access\, \nsuch as the ones used daily for genomes analyses.\n\nAcknowledgement\nThis works was supported by the European Uni on (EGEE project\, ref. INFSO-508833). Authors express thanks \nto Douglas Thain for the interesting discussions about the Parrot tool.\n\nReference s\n[1] Jacq\, N.\, Blanchet\, C.\, Combet\, C.\, Cornillot\, E.\, Duret\, L.\, Kurata\, K.\, Nakamura\, H.\, Silvestre\, T.\, Breton\, \nV. : Grid as a bioinformatics tool. \, Parallel Computing\, special issue: High-perf ormance parallel bio-\ncomputing\, Vol. 30\, (2004).\n[2] Breton\, V.\, B lanchet\, C.\, Legré\, Y.\, Maigne\, L. and Montagnat\, J.: Grid Technolo gy for Biomedical \nApplications. M. Daydé et al. (Eds.): VECPAR 2004\, L ecture Notes in Computer Science 3402\, pp. 204–218\, \n2005.\n[3] Comb et\, C.\, Blanchet\, C.\, Geourjon\, C. et Deléage\, G. : NPS@: Network P rotein Sequence Analysis. Tibs\, \n25 (2000) 147-150.\n[4] Enabling Grid for E-sciencE (EGEE). Online: www.eu-egee.org\n[5] Foster\, I. And Kessel man\, C. (eds.) : The Grid 2 : Blueprint for a New Computing Infrastructur e\, (2004).\n[6] Shamir.\, A. “How to share a secret”. Communications of the ACM \, 22(11):612–613\, Nov. 1979.\n[7] Thain\, D. and Livny\, M.: Parrot: an application environment for data-intensive computing. Scala ble \nComputing: Practice and Experience 6 (2005) 9-18\n\nhttp://indico.ce rn.ch/contributionDisplay.py?contribId=90&sessionId=9&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=90&sessionId=9& confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Encrypted Data Storage in EGEE DTSTART;VALUE=DATE-TIME:20060302T154500Z DTEND;VALUE=DATE-TIME:20060302T160500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-93@cern.ch DESCRIPTION:Speakers: FROHNER\, Ákos (CERN)\nThe medical community is r outinely using clinical images and\nassociated medical data for diagnosi s\, intervention planning and\ntherapy follow-up. Medical imaging is producing an increasing\nnumber of digital images for which comput erized archiving\,\nprocessing and analysis are needed.\n\nGrids are prom ising infrastructures for managing and analyzing\nthe huge medical databa ses. Given the sensitive nature of medical\nimages\, practiotionners are often reluctant to use distributed\nsystems though. Security if ofte n implemented by isolating the\nimaging network from the outside world i nside hospitals. Given the\nwide scale distribution of grid infrastructure s and their multiple\nadministrative entities\, the level of security f or manipulating\nmedical data should be particularly high.\n\nIn this pr esentation we describe the architecture of a\nsolution\, the gLit e Encrypted Data Storage (EDS)\, which was\ndeveloped in the frame work of Enabling Grids for E-sciencE\n(EGEE)\, a project of the Eu ropean Commission (contract number\nINFSO--508833). The EDS does enforce strict access control to any\nmedical file stored on the grid. It also provides file encryption\nfacilities\, that ensure the protection of da ta sent to remote\nstorage\, even from their administrator. Thus\, dat a are not only\ntransferred but also stored encrypted and can only be dec rypted in\nhost memory by authorized users.\n\nIntroduction\n============\ n\nThe basic building blocks of the grid data management\narchit ecture are the Storage Elements (SE)\, which provide\ntransport (e.g. gridftp)\, direct data access (e.g. direct\nfile access\, r fio\, dcap) and administrative (Storage Resource\nManagement\, SRM) in terfaces for a storage system. However the most\nwidely adopted standard t oday for managing medical data in clinics\nis DICOM (Digital Image and COm munication in Medicine).\n\nThe simplified goal is to secure the data mov ement among these\nblocks\, and the client hosts\, which actually process the data.\n\nChallenges\n==========\n\nHere we describe the most important challenges and requirements\nof the medical community and how they are a ddressed by EDS on the\ncurrent grid infrastructure.\n\n Access Control\n --------------\nThe most basic requirement is to restrict the access to any\ndata\, which is on the grid\, to permitted users. Although it\nlooks like a simple requirement\, the distributed nature of the\n architecture and the limitations of the building blocks required\nsome w ork to satisfy the requirements.\n\nThe first problem faced is the comple x access patterns of the\nmedical community. It is usually not enough to define a single\nuser or group which is allowed to access the file\ , but instead\naccess is needed by a list of users. The solution is to us e Access\nControl Lists (ACLs)\, instead of basic POSIX permission bi ts\,\nhowever most of the currently deployed Storage Elements do not\n provide ACLs.\n\nTo solve the semantical mismatch\, we "wrapped" the e xisting\nStorage Elements into a service\, which enforced the access contr ol\nsettings\, according to the medical community's requirements. This\ns ervice is called the gLite I/O server\, which is installed beside\nevery used storage element.\n\nThe gLite I/O server provides a POSIX like file access\ninterface to remote clients\, and uses the direct dat a access\nmethods of the Storage Element to access the data. It\nauthenticates the clients and enforces authorization decisions\n( i.e. if the client is allowed to read a file or not)\, so it acts\nlike a Policy Enforcement Point in the middle of the data access.\n\nThe authori zation decision is not made inside the gLite I/O\nserver. A separate service holds the ACLs (and other file\nmetadata) of every file stored in the Storage Elements. In\nour deployment it was the gL ite File and Replica Management\n(FiReMan) service\, which acts like a Policy Decision Point in the\narchitecture.\n\nThe gLite FiReMan service is a central component\, which also\nacts like a file catalog (dir ectory functionality)\, replica\nmanager (which file has a copy o n a given SE) and file\nauthorization server (if a given client is allowed to access a\nfile). The gLite FiReMan service supports rich ACL semantics\,\nwhich satisfy the access pattern requirements of th e medical\ncommunity.\n\n Encryption\n ----------\nThe other importan t requirement is privacy: the sensitive\nmedical data shall not be stored on any permanent storage or\ntransferred over the network unenc rypted\, outside the originating\nhospital.\n\nThe solution is to encryp t every file\, when it leaves the\noriginating hospital's DICOM serve r\, and decrypt it only inside\nthe authorized client applications.\n\nF or the first step we developed a specialized Storage\nElement\, the Medical Data Manager (MDM) service\, which "wraps"\nthe hospital' s DICOM server and offers interfaces\, which are\ncompatible with ot her grid Storage Elements. In this way the\nhospital's data storage will look like just another Storage\nElement\, for which we alr eady have grid data managements\nsolutions.\n\nDespite the apparent similarity between the MDM service and\nan ordinary Storage Element there is an important difference:\nthe MDM service serves only encry pted files. When a file is\naccessed through the grid interfaces\, the service generates a new\nencryption key\, encrypts the file and register s the key in a key\nstore. Therefore every file which crosses the externa l network and\nis stored on stored on an external element stays encrypted during\nits whole lifetime.\n\nOn the client side we provided a tran sparent solution to\ndecrypt the file: on top of the gLite I/O client libraries\, we\ndeveloped a client library\, which can retrieve keys fr om t he key\nstorage and decrypt files on the fly. The client side li brary\nprovides a POSIX like interface\, which hides the details of the \nremote data access\, key retrieval and decryption.\n\nThe key storage ha d to satisfy several requirements: it has to\nbe reliable\, secure and p rovide fine grained access control for\nthe keys.\n\nTo satisfy these requirements we developed the gLite Hydra\nKeyStore. To satisfy reliab ility the keys are not only stored at\none place\, but at least at two lo cations. To satisfy security\, one\nservice cannot store a full key\, b ut only a part of it\, thus\neven when the service is compromised th e keys cannot be fully\nrecovered. We implemented Shamir's Secret Shar ing Scheme inside\nthe client library to split and distribute the ke ys among at\nleast three Hydra services\, according to the above me ntioned\nrequirements.\n\nThe key storage also has to provide fine grained access\ncontrol\, similar to the files\, on the keys. Our curre nt solution\nactually applies the same ACLs as the FiReMan service\, th us one\ncan be sure that only those who can access the encryption key of a \nfile are allowed to access the file itself.\n\nConclusion\n==========\n\ nThe solution for encrypted storage described above has been\nalready released in the gLite software stack and been deployed and\ndemonstrated t o work at a number of sites.\n\nAs the underlying software stack of the grid evolves we will\nalso adapt our solution to exploit new functio nality and to\nsimplify our additional security layer.\n\nhttp://indico. cern.ch/contributionDisplay.py?contribId=93&sessionId=13&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=93&sessionId=13 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:CRAB: a tool for CMS distributed analysis in grid environment. DTSTART;VALUE=DATE-TIME:20060301T170000Z DTEND;VALUE=DATE-TIME:20060301T173000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-95@cern.ch DESCRIPTION:Speakers: FANZAGO\, Federica (INFN-PADOVA)\nThe CMS experiment will produce a large amount of data (few PBytes each year) that\nwill be distributed and stored in many computing centres spread in the countries\n participating to the CMS collaboration and made available for analysis to world-wide\ndistributed physicists.\nCMS will use a distributed architectu re based on grid infrastructure to analyze data\nstored at remote sites\, to assure data access only to authorized users and to ensure\nremote resou rces availability.\nData analisys in a distributed environment is a comple x computing task\, that assume\nto know which data are available\, where d ata are stored and how to access them.\nThe CMS collaboration is developin g a user friendly tool\, CRAB (Cms Remote Analysis\n Builder)\, whose aim is to simplify the work of final users to create and to submit\nanalysis jobs into the grid environment. Its purpose is to allow generic users\,\nw ithout specific knowledge of grid infrastructure\, to access and analyze r emote data\nas easily as in a local environment\, hiding the complexity of distributed\ncomputational services.\nUsers have to develop their analisy s code in an interactive environment and decide\nwhich data to analyze\, p roviding to CRAB data parameters (keywords to select data and\ntotal numbe r of events) and how to manage produced output (return file to UI or store \ninto remote storage). \nCRAB creates a wrapper of the analisys executabl e which will be run on remote\nresources\, including CMS environment setup and output management. CRAB splits the\nanalisys into a number of jobs ac cording to user provided information about number of\nevents. The job subm ission is done using grid workload management command.\nThe user executabl e is sent to remote resource via inputsandbox\, together with the\njob. Da ta discovery\, resources availability\, status monitoring and output retri eval\nof submitted jobs are fully handled by CRAB.\nThe tool is written in python and have to be installed to the User Interface\, the\nuser access point to the grid. \nUp to now CRAB is installed in ~45 UI and about ~210 different kind of data are\navailable in ~40 remote sites. \nThe weekly ra te of submitted jobs is ~10000 with a success rate about 75%\, that means\ njobs arrive to remote sites and produce outputs\, while the remnant 25% a borts due to\nsite setup problem or grid services failure.\nIn this report we will explain how CRAB is interfaced with other CMS/grid services\nand will report the daily user's experience with this tool analyzing simulated data\nneeded to prepare the Physics Technical Design Report.\n\nhttp://in dico.cern.ch/contributionDisplay.py?contribId=95&sessionId=10&confId=286 LOCATION:CERN 40-5-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=95&sessionId=10 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:The gLite File Transfer Service DTSTART;VALUE=DATE-TIME:20060302T152500Z DTEND;VALUE=DATE-TIME:20060302T154500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-94@cern.ch DESCRIPTION:Speakers: Mr. BADINO\, Paolo (CERN)\nIn this paper we describe the architecture and implementation of the gLite\nFile Transfer Service ( FTS) and list the most basic deployment\nscenarios. The\nFTS is addressing the need to manage massive wide-area data transfers on\ndedicated network channels while allowing the involved sites and users to\nmanage their pol icies. The FTS manages the transfers in a robust way\,\nallowing\nfor an o ptimized high throughput between storage systems.\n\nThe FTS can be used t o perform the LHC Tier-0 to Tier-1 data transfer as\nwell\nas the Tier-1 t o Tier-2 data distribution and collection. The storage\nsystem\npeculiarit ies can be taken into account by fine-tuning the parameters of\nthe\nFTS m anaging a particular channel. All the manageability related\nfeatures as\n well as the interaction with other components that form part of the overal l\nservice are described as well. The FTS is also extensible so that\npart icular\nuser groups or experiment frameworks can customize its behavior bo th for\npre-\nand post-transfer tasks.\n\nThe FTS has been designed based on the experience gathered from the Radiant\nservice used in Service Chall enge 2\, as well as the CMS Phedex transfer\nservice. The first implementa tion of the FTS was put to use in the\nbeginning\nof the Summer 2005. We r eport in detail on the features that have been\nrequested following this i nitial usage and the needs that the new features\naddress. Most of these h ave already been implemented or are in the\nprocess of\nbeing finalized. T here has been a need to improve the manageability\naspect of\nthe service in terms of supporting site and VO policies.\n\nDue to different implement ations of specific Storage systems\, the choice\nbetween 3rd party gsiftp transfers and SRM-copy transfers is nontrivial and\nwas requested as a con figurable option for selected transfer channels.\nThe way\nthe proxy certi ficates are being delegated to the service and are used to\nperform the tr ansfer\, as well as how proxy renewal is done has been\ncompletely\nrework ed based on experience. A new interface has been added to enable\nadminist rators to perform management directly by contacting the FTS\,\nwithout\nth e need to restart the service. Another new interface has been added in\nor der\nto deliver statistics and reports to the sites and VOs interested in useful\nmonitoring information. This is also presented through a web inter face\nusing\njavascript. Stage pool handling for the FTS is being added in order to\nallow\npre-staging of sources without blocking transfer slots o n the source and\nalso\nto allow the implementation of back-off strategies in case the remote\nstaging\nareas start to fill up.\n\nThe reliable tran sport of data is one of the cornerstones for distributed\nsystems. The tra nsport mechanisms have to be scalable and efficient\, making\noptimal usag e of the available network and storage bandwidth. In production\ngrids the most important requirement is robustness\, meaning that the\nservice\nnee ds to be run over extended periods of time with little supervision.\nMoreo ver\, the transfer middleware has to be able to apply policies for\nfailur e\, adapting parameters dynamically or raising alerts where\nnecessary. In \nlarge Grids\, we have the additional complication of having to support\n multiple\nadministrative domains while enforcing local site policies. At t he same\ntime\,\nthe Grid application needs to be given uniform interface semantics\nindependent\nof site-local policies.\n\nThere are several file transfer mechanisms in use today in Data Grids\, like\nhttp(s)\, (s)ftp \, scp or bbftp\, but probably the most commonly used one is\nGridFTP\, prov iding a highly performant secure transfer service. The Storage\nResource M anager SRM interface\, which is being standardized through the\nGlobal\nGr id Forum\, provides a common way to interact with a Storage Element\, as\n well\nas a data movement facility\, called SRM copy\, which in most implem entations\nwill again make use of GridFTP to perform the transfer on the u ser's behalf\nbetween two sites.\n\nThe File Transfer Service is the low l evel point to point file movement\nservice provided by the EU-funded Enabl ing Grids for E-SciencE (EGEE)\nproject's\ngLite middleware. It has been d esigned in order to address the challenging\nrequirements of a reliable fi le transfer service in production Grid\nenvironments. What distinguishes t he FTS from other reliable transfer\nservices\nis its design for policy ma nagement. The FTS can also act as the resource\nmanager's policy enforceme nt tool for a dedicated network link between two\nsites as it is capable o f managing the policies of the resource owner as\nwell\nas of the users (t he VOs). The FTS has dedicated interfaces to manage these\npolicies. The F TS is also extensible\; upon certain events user-definable\nfunctions can be executed. The VOs may make use of this extensibility\npoint to\ncall up on other services when transfers complete (e.g. register replicas in\ncata logs) or to change the policies for certain error handling operations\n(e. g. the retry strategy).\n\nThe LHC Computing Project (LCG) is the project that has built and\nmaintains a\ndata storage and analysis infrastructure for the entire high energy physics\ncommunity of the Large Hadron Collider (LHC)\, the largest scientific\ninstrument on the planet located at CERN. The data from the LHC experiments\nwill be distributed around the globe\, according to a multi-tiered model\,\nwhere\nCERN is the "Tier-0"\, the ce ntre of LCG.\nThe goal of LCG Service Challenges is to provide a productio n quality\nenvironment where services are run for long periods with 24/7 o perational\nsupport. These services include the Network and Reliable File Transfer\nservices. In Summer 2005 Service Challenge 3 started with gLite File\nTransfer\nService and CMS Phedex. The gLite FTS benefited from this collaboration and\nfrom the experience of prototype LCG Radiant Service\, used in Service\nChallenge 2. This meant that from the beginning its desig n took into\naccount\nall the requirements imposed by a production Grid in frastructure. The\ncontinuous interaction with the experiments was useful in order to react\nquickly to reported problems\, as well as to keep the d evelopment focused on\nreal use cases.\n\nhttp://indico.cern.ch/contributi onDisplay.py?contribId=94&sessionId=13&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=94&sessionId=13 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Use of the Storage Resource Manager Interface DTSTART;VALUE=DATE-TIME:20060302T160500Z DTEND;VALUE=DATE-TIME:20060302T162500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-97@cern.ch DESCRIPTION:Speakers: LITMAATH\, Maarten (CERN)\nSRM v2.1 features and sta tus\n----------------------------\n\nVersion 2.1 of the Storage Resource M anager interface offers various\nfeatures that are desired by EGEE VOs\, p articularly HEP experiments:\npinning and unpinning of files\, relative pa ths\, (VOMS) ACL support\,\ndirectory operations\, global space reservatio n. The features are\ndescribed in the context of actual use cases and ava ilability in the\nfollowing widely used SRM implementations: CASTOR\, dCac he\, DPM.\nThe interoperability of the different implementations and SRM v ersions\nis discussed\, along with the absence of desirable features like quotas.\n\nVersion 1.1 of the SRM standard is in widespread use\, but has various\ndeficiencies that are addressed to a certain extent by version 2. 1.\nThe two versions are incompatible\, necessitating clients and servers\ nto maintain both interfaces\, at least for a while. Certain problems\nwi ll only be dealt with in version 3\, whose definition may not be\ncomplete d for many months. There are various implementations of\nversions 1 and 2 \, developed by different collaborations for different\nuser communities a nd service providers\, with different requirements\nand priorities. In ge neral a VO will have inhomogeneous storage\nresources\, but a common SRM s tandard should make them compatible\,\nsuch that data management tools and procedures need not bother with\nthe actual types of the storage faciliti es.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=97&sessionId =13&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=97&sessionId=13 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:A service to update and replicate biological databases DTSTART;VALUE=DATE-TIME:20060301T141500Z DTEND;VALUE=DATE-TIME:20060301T143000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-96@cern.ch DESCRIPTION:Speakers: Mr. SALZEMANN\, Jean (IN2P3/CNRS)\nOne of the main c hallenges in molecular biology is the management of data and\ndatabases. A large fraction of the biological data produced is publicly available on\n web sites or by ftp protocols. These public databases are internationally known and\nplay a key role in the majority of public and private research. But their \nexponential\ngrowth raises an usage problem. Indeed\, scienti sts need easy access to the last\nupdate of the databases in order to appl y bioinformatics or data mining algorithms.\nThe frequent and regular upda te of the databases is a recurrent issue for all host \nor\nmirror centres \, and also for scientists using the databases locally for\nconfidentialit y reasons. \n\nWe proposed a solution for the updates of these distributed databases. This solution\ncome as a service embedded into the grid which uses its mechanisms and automatically\nperforms updates. So we developed a set of web services that will rely on the grid \nto\nmanage this task\, w ith the aim of deploying the services under any grid middleware\nwith a mi nimum of adaptation. This includes a client/server application with a set \nof\nrules and a protocol to update a database from a given repository an d distribute the\nupdate through the grid storage elements while trying to optimize network bandwidth\,\nfile transfers size and fault tolerance\, a nd finally offer a transparent automated\nservice which does not require u ser intervention. This represents the challenges of\nthe database update i n a grid environment and the solution we proposed is basically\nto define two types of storage on the grid storage elements: some storage of\nrefere nce where the update is first performed and working storage spaces where t he\njobs will pick up the information. The idea is to replicate the update on the grid\nfrom these reference points to the storage elements. From th e service point of view\,\nit is necessary that the grid information syste m can locate sites who host a given\ndatabase in order to have the benefit s of a dynamical database replication and\nlocation. From the user point o f view\, we need to dispose of the location \ninformation\nfor each databa se in order to achieve scalability and find replica on the grid\, this\nme ans having a metadata for each database that can refer to several physical \nlocations on the grid and contain certain information as well\, because the replica \ndo\nnot concern single files but a whole database with sever al files and/or \ndirectories. \n\nThis service is being deployed on two F rench Grid infrastructures: RUGBI (based on\nGlobus Toolkit 4) and Auvergr id (based on EGEE)\, so we plan a future deployment of\nthis service on EG EE\, especially in the Biomed VO\, but the real issues are that the\nservi ce need to be deployed as a grid service\, and managed as a grid service\, so \nsome\npeople from the VO should be able to deploy and administrate t he service beside the\nsite administrators\, a role which is finding its l imits in current VO management. \nThe\nservice is supposed to be embedded into the grid and is not just a pure application\nlaid on it. Eventually i t will be possible to offer this service as an application\,\nbut it would mean that its use is not mandatory and not automated\, which is\nsynonymo us with losing its benefits and transparency since the user will need to\n specify the use of the service in his workflow. There are also future plan s to add\nsome optimisation on the deployment of the databases: for exampl e\, being able to\nsplit databases to store each part on a different stora ge element\, or add the \nability\nto offer several reference storages per database which would require to synchronize\nthese storages with each oth er. The service will mature through its deployment on\ngrid middlewares an d will surely improve as it is used in production environments.\n\nhttp:// indico.cern.ch/contributionDisplay.py?contribId=96&sessionId=9&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=96&sessionId=9& confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Summary of parallel session 2b DTSTART;VALUE=DATE-TIME:20060303T083000Z DTEND;VALUE=DATE-TIME:20060303T090000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-11@cern.ch DESCRIPTION:Speakers: MONTAGNAT\, Johan (CNRS)\n \n\nhttp://indico.cern.c h/contributionDisplay.py?contribId=11&sessionId=19&confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=11&sessionId=19 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Summary of parallel session 2a DTSTART;VALUE=DATE-TIME:20060303T080000Z DTEND;VALUE=DATE-TIME:20060303T083000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-10@cern.ch DESCRIPTION:Speakers: KORNMAYER\, Harald (Forschungszentrum Karlsruhe)\n  \n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=10&sessionId=19 &confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=10&sessionId=19 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Summary of parallel session 2d DTSTART;VALUE=DATE-TIME:20060303T100000Z DTEND;VALUE=DATE-TIME:20060303T103000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-13@cern.ch DESCRIPTION:Speakers: DONNO\, Flavia (CERN)\n \n\nhttp://indico.cern.ch/c ontributionDisplay.py?contribId=13&sessionId=19&confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=13&sessionId=19 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Summary of parallel session 2c DTSTART;VALUE=DATE-TIME:20060303T090000Z DTEND;VALUE=DATE-TIME:20060303T093000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-12@cern.ch DESCRIPTION:Speakers: LOOMIS\, Cal (LAL Orsay)\n \n\nhttp://indico.cern.c h/contributionDisplay.py?contribId=12&sessionId=19&confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=12&sessionId=19 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:EGEE Technical Coordination group DTSTART;VALUE=DATE-TIME:20060303T103000Z DTEND;VALUE=DATE-TIME:20060303T110000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-15@cern.ch DESCRIPTION:Speakers: LAURE\, Erwin (CERN)\n \n\nhttp://indico.cern.ch/co ntributionDisplay.py?contribId=15&sessionId=19&confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=15&sessionId=19 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Long-term grid sustainability DTSTART;VALUE=DATE-TIME:20060303T110000Z DTEND;VALUE=DATE-TIME:20060303T113000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-16@cern.ch DESCRIPTION:Speakers: Prof. KRANZLMUELLER\, Dieter (Linz University and CE RN)\nEurope has invested heavily in developing Grid technology and\ninfras tructures during the past years\, with some impressive results. The EU\nEG EE Project (www.eu-egee.org)\, which provides a coordinating framework for \nnational\, regional and thematic Grids\, has proved a vital catalyst and \nincubator for the success of establishing a working\, large-scale\,\nmul ti-science production Grid infrastructure that serves many sciences. As\nt he Virtual Organizations established by scientific communities move from\n testing their applications on the Grid to routine and daily usage\, it\nbe comes increasingly important and necessary to ensure maintainance\,\nrelia bility and adaptiveness of the Grid infrastructure. This is rather\ndiffic ult with the usual (short) project funding cycles\, which inhibit\ninvestm ent from long-term users and industry. The situation is in some\nways anal ogous to that of scientifc networks\, where independent national\ninitiati ves led to common standards and ultimately the creation of the DANTE\norga nization. A similar evolution needs to be planned now for Grids\, i.e.\nNa tional Grid Initiatives to guide Grid infrastructure deployment and\nopera tion at country-level and a central coordinating body to ensure\nlong-term sustainability and interoperability.\n\nhttp://indico.cern.ch/contributio nDisplay.py?contribId=16&sessionId=19&confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=16&sessionId=19 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Conference summary DTSTART;VALUE=DATE-TIME:20060303T113000Z DTEND;VALUE=DATE-TIME:20060303T120000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-18@cern.ch DESCRIPTION:Speakers: LAMANNA\, Massimo (CERN)\nhttp://indico.cern.ch/cont ributionDisplay.py?contribId=18&sessionId=19&confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=18&sessionId=19 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:ARCHEOGRID Status Report DTSTART;VALUE=DATE-TIME:20060303T133500Z DTEND;VALUE=DATE-TIME:20060303T135500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-117@cern.ch DESCRIPTION:Speakers: \nhttp://indico.cern.ch/contributionDisplay.py?contr ibId=117&sessionId=21&confId=286 LOCATION:CERN Council Chamber URL:http://indico.cern.ch/contributionDisplay.py?contribId=117&sessionId=2 1&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Fusion Status Report DTSTART;VALUE=DATE-TIME:20060303T131500Z DTEND;VALUE=DATE-TIME:20060303T133500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-116@cern.ch DESCRIPTION:Speakers: \nhttp://indico.cern.ch/contributionDisplay.py?contr ibId=116&sessionId=21&confId=286 LOCATION:CERN Council Chamber URL:http://indico.cern.ch/contributionDisplay.py?contribId=116&sessionId=2 1&confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Sustainable management of groundwater exploitation using Monte Car lo simulation of seawater intrusion in the Korba aquifer (Tunisia) DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-48@cern.ch DESCRIPTION:Speakers: Mr. KERROU\, Jawher (University of Neuchatel)\nWorld wide\, seawater intrusion and salinisation of coastal aquifers and soils i s a\nmajor threat for food production. While the physico-chemical processe s triggering the\ntransport and accumulation of salts in these regions are relatively well known and\nwell described by a set of partial differentia l equations\, often it is extremely\ndifficult to model accurately these p henomena because of the lack of an accurate data\nset. On one hand the phy sical parameters (porosity\, permeability\, dispersivity) that\ncontrol gr oundwater flow are extremely variable in space within geological media and \nare only measured at some specific locations\, on the other hand the for cing terms\n(pumping\, precipitation\, etc.) are often not measured direct ly in the field. The\nresult is a high level of uncertainty. The problem i s how to take rational decision\ntoward sustainable water management in su ch a context ?\n\nOne possibility explored within this work is to run a la rge set of model simulations\nwith stochastic parameters by means of the E GEE GRID infrastructure and to define\nrobust and sustainable water manage ment decisions based on probabilistic analysis of\nthe resulting simulatio n outputs. This approach is currently being investigated in\nthe Cape Bon peninsula\, located 50 km South-East of Tunis\, one of the most productive \nagricultural areas in Tunisia. In this plain the World Bank has shown th at major\nwater resources problem could occur in the next decade. One of t he major sources of\nuncertainty in the Cap Bon aquifer system are the pum ping rates and their time\nevolution. To investigate the impact of this so urce of uncertainty\, first a\ngeostatistical model of the spatial distrib ution of the pumping has been constructed\nand then the GRID has been used to run a 3D density-dependent groundwater flow and\nsalt transport model in a Monte Carlo framework. \n\nWhile these results are still preliminary\ , GRID computing paradigm offers clearly a\nhuge potential within this fie ld. One particularly interesting aspect offered by this\nmethodology to Tu nisian water managers\, not having access to local computing\ntechnology\, is to be able in a near future to run directly\, via a web portal to the\ nGRID\, their groundwater flow simulation and uncertainty analysis. This o ption has not\nbeen tested yet and requires further development.\n\nhttp:/ /indico.cern.ch/contributionDisplay.py?contribId=48&sessionId=22&confId=28 6 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=48&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Experiences on Grid production for Geant4 DTSTART;VALUE=DATE-TIME:20060301T160000Z DTEND;VALUE=DATE-TIME:20060301T163000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-49@cern.ch DESCRIPTION:Speakers: Dr. RIBON\, Alberto (CERN)\nGeant4 is a general purp ose toolkit for simulating the tracking\n and interaction of particles thr ough matter. It is currently used\n in production in several particle phys ics experiments (BaBar\, HARP\, \n ATLAS\, CMS\, LHCb)\, and it has also a pplications in other areas\, \n as space science\, medical applications\, and radiation studies.\n The complexity of the Geant4 code requires carefu l testing of all \n of its components\, especially before major releases ( which happens\n twice a year\, in June and December).\n In this talk\, I w ill describe the recent development of an automatic\n suite for testing ha dronic physics in high energy calorimetry \n applications. The idea is to use a simplified set of hadronic \n calorimeters\, with different beam par ticle types\, and various beam \n energies\, and comparing relevant observ ables between a given \n reference version of Geant4 and the new candidate one. Only those \n distributions that are statistically incompatible are then printed \n out and finally inspected by a person to look for possible bugs. \n The suite is made of Python scripts\, and utilizes the "Statisti cal \n Toolkit" for the statistical tests between pair of distributions\, \n and runs on the Grid to cope with the large amount of CPU needed \n in a short period of time. In fact\, the total CPU time required for \n each of these Geant4 release validation productions amounts to about\n 4 CPU-ye ars\, which have to be concentrated in a couple of weeks. \n Therefore\, t he Grid environment is the natural candidate to perform \n this validation production. We have already run three of them\, \n starting in December 2 004. In the last production\, in December 2005\, \n we run as Geant4 VO\, for the first time\, demonstrating the full \n involvement of Geant4 insid e the EGEE communities. Several EGEE sites \n have provided us with the ne eded CPU\, and this has guaranteed the \n success of the production\, arri ving to an overall efficiency rate \n of about 99%.\n In the talk\, emphas is will be given on our experiences in using \n the Grid\, the results we got from it and possible future \n improvements. Technical aspects of the Grid framework that have\n been deployed for the production will only be m entioned\; for more \n details see the talks of P.Mendez and J.Moscicki.\n \nhttp://indico.cern.ch/contributionDisplay.py?contribId=49&sessionId=10&c onfId=286 LOCATION:CERN 40-5-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=49&sessionId=10 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:FUSION ACTIVITIES IN THE GRID DTSTART;VALUE=DATE-TIME:20060301T140000Z DTEND;VALUE=DATE-TIME:20060301T143000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-46@cern.ch DESCRIPTION:Speakers: Dr. CASTEJON\, Francisco (CIEMAT)\nThe future Magnet ic confinement Fusion energy research will be mainly based upon large inte rnational \nfacilities with the participation of a lot of scientist belong ing to different institutes. For instance\, the large \ndevice ITER (Inter national Tokamak Experimental Reactor) that will be built in Cadarache (Fr ance) is \nparticipated by six partners: Europe\, Japan\, USA\, Russia\, C hina\, and Korea. India is presently involved in \nnegotiations to join th e project and Brazil is also considering the possibility of joining the pr oject. Besides \nITER\, the Fusion community has a strong collaboration st ructure devoted both to the tokamak and the \nstellarator research. As a r esult of this structure\, there exists a network of groups and Institutes that are \nsharing facilities and/or results obtained on those facilities. \nMagnetic Fusion facilities are constituted by large devices devoted to study Plasma Physics that produce a \nlarge amount of data to be analysed (the typical rhythm of data production is about 1 GBy/s for a conventional \ndevice that can reach 10 times larger value in ITER). The analysis and availability of those data is a key point \nfor the scientific exploitatio n of those devices. \nAlso\, large computations are needed for understandi ng plasma Physics and developing new calculation \nmethods that are very C PU time consuming. A part of this computation effort can be performed in a \ndistributed way and Grid technologies are very suitable to perform thos e calculations. Several Plasma Physics \napplications are being envisaged for adapting into the grid\, those that can be distributed in different \n processors. \nThe first kind of applications is In particular\, Monte Carl o codes are suitable and powerful tools to perform \ntransport calculation s \, especially in those cases like the TJ-II stellarator that present rad ially extended ion \norbits\, which has strong influence on confinement: T he fact that orbits are wide makes that ions perform large \nradial excurs ions during a collision time\, which will enhance outward heat flux. The u sual transport \ncalculations based on local plasma characteristics that g ive local transport coefficients are not suitable for this \nkind of geome try in the long mean free path regime. The suitable way to estimate transp ort is to follow \nmillions of individual particles that move in a backgro und plasma and magnetic configuration. The interaction \nwith other partic les is simulated by a collision operator\, which depends on density and te mperature\, and by a \nsteady state electric field\, caused by the unbalan ced electron and ion fluxes. This tool will be also useful to \ntake into account other kinetic effects on electron transport\, like those related t o heating and current drive. \nThis transport tool is now working in a Sup ercomputer and is being prepared to be ported to the grid\, where \nwill r un soon. The capability of performing massive kinetic transport calculatio ns will allow us to explore \ntransport properties in different heating co nditions and collisionalities\, as well as with different electric field \ nprofiles. \nAnother application that requires distributed calculations is the massive ray tracing. The properties of \nmicrowave propagation and ab sorption are estimated in the geometrical optics (or WKB) approximation by \nsimulating the microwave beam by a bunch of rays. Those rays are launch ed and followed inside the plasma \nand all the necessary quantities are e stimated along ray trajectories. Since all the rays are independent\, they \ncan be calculated separately . The number of rays needed in a normal ca se is typically 100 or 200\, and the \ntime needed for every ray estimate is about 10-20 minutes. This approximation works when the waist of the \nb eam is far from any critical layer in the plasma. Critical layers are thos e where mode conversion\, absorption\, \nor reflection of microwaves happe ns. When the waist of the beam is closed to critical layers\, a much highe r \nnumber of rays is needed to simulate the beam. The typical number can be of the order of 10000\, which is \nhigh enough to make it necessary to run the application in the grid. Massive ray tracing calculations could \n also be useful to determine the optimum microwave launching position in a complex 3D device like a real \nstellarator.\nThese two former application s require that a common file with stellarator geometry data is distributed in all \nthe processors as well as individual files with the initial data of every ray and trajectory. \n \nStellarator devices present different m agnetic configurations with different confinement properties. It is \nnece ssary to look for the magnetic configuration that present the best confine ment properties\, considering \nthe experimental knowledge of confinement and transport in stellarators. Therefore\, stellarator optimization \nis a very important topic to design the future stellarators that have to play a role in Magnetic confinement \nfusion. The optimization procedure has to take into account a lot of criteria that are based on the previous \nstel larator experience: neoclassical transport properties\, viscosity\, stabil ity\, etc. A possible way to develop this \nprocedure is to parametrize th e plasma by the Fourier coefficients that describe the magnetic field. Eve ry set \nof coefficients is considered as a different stellarator with dif ferent properties. The optimization procedure \nhas to take into account t he desired characteristics for a magnetic configuration to be suitable for an \noptimised stellarator. The optimization criteria are set through fun ctions that take into account the properties \nthat favour plasma confinem ent . Every case can be run in a separate node of the grid in order to exp lore the \nhundreds of parameters that are involved in the optimization. \ nPresently\, other applications are being considered to be run in the grid in order to solve efficiently some \nproblems on Plasma Physics that are needed for the future magnetic confinement devices. For instance\, \ntrans port analysis is a key instrument in Plasma Physics that gives the transpo rt coefficients that fit the \nexperimental data. Transport analysis is pe rformed using transport codes on the real plasma discharges. A \nplasma co nfinement device can perform tens of thousands of discharges along its lif e and only a few of them \nare analysed. It would be possible to install a transport code in the grid that performs automatic transport \nanalysis o n the experimental shots. In this way\, the dependence of local transport coefficients on plasma \nparameters like magnetic configuration\, density\ , temperature\, electric field\, etc. can be extracted. And\, finally \nth e tokamak equilibrium code EDGE2D can be installed in the grid to obtain e quilibrium parameters in the \nedge\, which is basic to estimate the exact plasma position and the equilibrium properties in the plasma edge.\n\nhtt p://indico.cern.ch/contributionDisplay.py?contribId=46&sessionId=10&confId =286 LOCATION:CERN 40-5-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=46&sessionId=10 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:gLibrary: a Multimedia Contents Management System on the grid DTSTART;VALUE=DATE-TIME:20060302T170000Z DTEND;VALUE=DATE-TIME:20060302T172000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-86@cern.ch DESCRIPTION:Speakers: Dr. CALANDUCCI\, Tony (INFN Catania)\nNowadays huge amounts of information are searched and used by people from all over \nthe world\, but it is not always easy to find out what one is looking for. Se arch \nengines helps a lot\, but they do not provide a standard and unifor m way to make \nqueries.\nThe challenge of gLibrary is to design and devel op a robust system to handle \nMultimedia Contents in a easy\, fast and se cure way exploiting the Grid.\nExamples of Multimedia Contents are images\ , videos\, music\, all kind of electronic \ndocuments (PDF\, Excel\, Power Point\, Word\, HTML)\, E-Mails and so on. New types of \ncontent can be ad ded easily into the system. \nThanks to the fixed structure of the attribu tes per each content type\, queries are \neasier to perform allowing the u sers to choose their search criteria among a \npredefined set of attribute s.\nThe following are possible use examples:\n- A user wants to look for a ll the comedies in which Jennifer Aniston performed \ntogether with Ben St iller\, produced in 2004 \; or find all the songs of Led Zeppelin \nthat l ast for more than 6 minutes\;\n- An user needs to find all the PowerPoint Presentation about Data Management \nSystem in 2005 run by Uncle Sam (fant asy name)\;\n- A doctor wants to retrieve all the articles and presentatio ns about lung cancer \nand download some lung X-ray images to be printed i n his article for a scientific \nmagazine\;\n- (Google for storage) a job behaves as a “storage crawler”: it scans all the files \nstored in Sto rage Elements and publishes their related specific information into \ngLib rary for later searches through their attributes.\nNot all the users of th e system have the same authority into the system. Three kind \nof users ar e enabled: gLibrary Generic Users\, members of a Virtual Organization \nre cognized by the system\, can browse the library and make queries. They can also \nretrieve the wanted files if the submitter user authorized them\; gLibrary Submitter \nUsers can upload new entries attaching them the prope r values for the defined \nattributes\; finally gLibrary Administrator are allowed to define new content type \nand elect Generic User granting them submission rights.\nA first level of security on single file is implement ed: files uploaded to Storage \nElements can be encrypted using a symmetri c key. This will be placed in a special \ndirectory into the system and th e submitter will define which users are the rights \nto read it.\nAll the application is built on top of the grid services offered by the EGEE \nmid dleware: actual data is stored in Storage Elements spread around the world \, \nwhile the File Catalog keeps track of where they are located. A Metad ata Catalog \nservice is intensively used to contains the values of attrib utes and satisfy user’s \nqueries. Finally\, A Virtual Organization Memb ership Service comes in help to deal \nwith authorization.\n\nhttp://indic o.cern.ch/contributionDisplay.py?contribId=86&sessionId=13&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=86&sessionId=13 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:K-Wf Grid: Knowledge-based Workflows in Grid DTSTART;VALUE=DATE-TIME:20060302T153000Z DTEND;VALUE=DATE-TIME:20060302T160000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-44@cern.ch DESCRIPTION:Speakers: HLUCHY\, Ladislav (Institute of Informatics\, Slovak ia)\nWe present an IST project of the 6th Framework Programme\, aimed towa rds intelligent \ngrid middleware and workflow construction. The project's acronym K-Wf Grid stands \nfor “Knowledge-based Workflow System for Gri d Applications”. The project itself \nemploys ontologies\, artificial re asoning\, Petri nets and modern service-oriented \narchitectures in order to simplify the use of grid infrastructures\, as well as \nintegration of applications into the grid. K-Wf Grid system is composed of a set of \nmod ules. The most visible one is the collaboration portal\, from which a user can \ncontrol the infrastructure and manage his/her application workflows . Behind this \nportal are hidden services doing the workflow management\, monitoring of \napplications and infrastructure\, knowledge extraction\, management\, and reuse. The \nproject is behind its prototype phase and a successful review by the Commission. \n The idea of the project is based i n the observation\, that users often have to \nlearn not only how to use t he grid\, but also how to best take advantage of its \ncomponents\, how to avoid problems caused by faulty middleware\, application modules \nand th e inherent dynamic behavior of the grid infrastructure as a whole. \nAddit ionally\, with the coming era of resources virtualized as web and grid \ns ervices\, dynamic virtual organizations and widespread resource sharing\, the \nvariables that are to be taken into account are increasing in number . Therefore we \ntried to devise a user layer above the infrastructure\, t hat would be able to handle \nas much of the learning and remembering as p ossible. This layer should be able to \nobserve what happens during applic ation execution\, infer new knowledge from these \nobservations and use th is knowledge the next time an application is executed. This \nway the syst em would - over time - optimize its behavior and use of available \nresour ces. \n The realization of this idea has been split into several tasks and formed into the \narchitecture\, that became the K-Wf Grid project. \n T he main interaction of users with the system occurs through the Web Portal . \nThrough it\, users can access the grid\, its data and services\, obtai n information \nstored in the knowledge management system\, add new facts to it\, construct and \nexecute workflows. The portal consists of three ma in parts\, the Grid Workflow User \nInterface (GWUI)\, the User Assistant Agent (UAA) interface\, and the portal \nframework based on GridSphere\, i ncluding collaboration tools from the Sakai project \nand interfaces to ot her K-Wf Grid modules. GWUI is a Java applet visualization of a \nPetri ne t-modeled workflow of services\, in which the user can construct a workflo w\, \nexecute it and monitor it. UAA is an advisor\, which communicates to the user all \nimportant facts about his/her current context – the serv ices he/she considers to \nuse\, the data he/she has or needs. Apart from automatically generated data\, the \ndisplayed information contains also h ints entered by other users\, which may help \nanyone to select better dat a or services or avoid problems of certain workflow \nconfigurations. This way the users may collaborate together and share knowledge. \n Under the Web Portal lies the Workflow Orchestration and Execution module\, \ncompos ed of several components. These components together are able to read a \nd efinition of an abstract workflow\, expand this definition into a regular workflow \nof calls to service interfaces\, map these calls to real servic e instances and \nexecute this workflow to obtain the expected results\, d escribed in the original \nabstract workflow. This way the user does not n eed to know all the services that \nare present in the grid and he/she is required only to state what result is \nrequired. \n To be able to abstrac t the grid in such a way as described in previous paragraph\, \nthe system has to know the semantics of the grid environment it operates on\, and so \nwe need to employ serious knowledge management\, computer-based learnin g and \nreasoning. This is the area of the Knowledge module\, which is spl it into the \nstorage part – Grid Organization Memory (GOM)\, and the le arning part – Knowledge \nAssimilation Agent (KAA). KAA takes observed e vents from the monitoring system\, \nmaps them to the context of the perfo rmed operation and extract new facts from \nthem. These facts are then sto red into GOM\, as well as used in later workflow \ncomposition tasks in or der to predict service performance. GOM itself stores all \ninformation ab out the available application services in a layered ontology and new \napp lications may be easily added into its structure by describing their respe ctive \ndomains in an ontology\, connected to the general ontology layer d eveloped in K-Wf \nGrid. \n The monitoring infrastructure is integrated in to the original grid middleware\, \nwith the Grid Performance Monitoring a nd Instrumentation Service (GPMIS) as a \nprocessing core. GPMIS receives information from a network of sensors\, embedded \ninto the middleware\, a pplication services (where it is possible to instrument the \nservices) an d into the other K-Wf Grid modules. Apart from collecting observations \nf or the learning modules\, the monitoring infrastructure is also a comprehe nsive \ntool for performance monitoring and tuning\, with comfortable visu al tools in the \nuser portal. \n At the bottom of the architecture lies t he grid itself – the application services\, \ndata storage nodes and com munication lines. K-Wf Grid has three distinct and varied \npilot applicat ions\, which it uses to test the developed modules. One of them is a \nflo od prediction suite\, developed from a previous effort in the CROSSGRID pr oject. \nIt consists of a set of several simulation models for meteorology \, hydrology and \nhydraulics\, as well as support and visualization tools \, all instantiated as WSRF \nservices. The second application is from the business area – a web service-based \nERP system. The third application is a system for coordinated traffic management in \nthe city of Genoa.\n\ nhttp://indico.cern.ch/contributionDisplay.py?contribId=44&sessionId=15&co nfId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=44&sessionId=15 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:ArchaeoGRID\, a GRID for Archaeology DTSTART;VALUE=DATE-TIME:20060301T143000Z DTEND;VALUE=DATE-TIME:20060301T144500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-45@cern.ch DESCRIPTION:Speakers: Prof. PELFER\, Pier Giovanni (Dept. Physics\, Univer sity of Florence and INFN\, Italy)\nModern archaeology\, between the histo rical\, anthropological and social sciences\, is \nthe more suitable and m ature for the application of the Grid technologies. In fact\, \narchaeolog y is a multidisciplinary historical science\, using data and methods from \nmany of the natural and social sciences. Archaeological research do and has done \nlarge use of computers and digital technologies for data acqu isition and storage\, \nfor quantitative and qualitative data analysis\, f or data visualisation\, for \nmathematical modeling and simulation. The We b also is intensively used for results \nexchange\, for communication and for accessing to large database by the Web Services \ntechnology. The inte rest of archaeologist for such methods is today more than a \ntemporal int erest. There are many computational archaeologists through the world and \ nspecialised quantitative archaeology laboratories experimenting new metho ds in \nspatial analysis\, geostatistics\, geocomputation\, artificial int elligence \napplications to archaeology\, etc.\nIn fact any material remai ns\, artifacts and ecofacts\, macro and microscopic\, present \non the ear th surface\, representing the material culture of the past societies is \n relevant for the archaeology\, independently from its esthetical or econom ical \nvalue. Remains should be described according to their basic proper ties (shape\, \nsize\, texture\, composition\, spatial and temporal locati on)\, which implies the use of \nsophisticated procedures for its computer representation: 3D geometry and realistic \nrendering\, among them. \nFur thermore\, data should be related spatially and temporally in complex ways . In so \ndoing\, an archaeological site should be understood as a complex sequence of finite \nstates of a spatio-temporal trajectory\, where an or iginal entity (ground surface) is \nmodified successively\, by accumulatin g things on it\, by deforming a previous \naccumulation or by direct physi cal modification (building\, excavation). This spatio-\ntemporal represent ation must be considered as continuum made up of discrete\, \nirregular\, discontinuous geometrical shapes (surfaces\, volumes) defined by \nadditio nal characteristics (shape\, texture\, composition\, as dependent variable s of \nthe model) which in turn influence the variation of every archaeolo gical feature. \nThe idea is that interfacial boundaries represent success ive phases\, and are \ndynamically constructed. Within them\, there should be some statistical relationship \nbetween the difference in value of the dependent regionalised variable which defines \nthe discontinuity at any pair of points and their distance apart.\nThe complexities of archaeologic al data processing are more demanding when we \nconsider that archaeologic al analysis cannot be constrained to the study of a single \nsite. In rece nt years archaeological research teams are very much interested in \ndoin g extended projects involving the study of many different sites at very la rge \ngeographic regions during very long time spans. This work is special ly relevant in \nthe case of the study of paleoclimatic human adaptations\ , hunter-gatherer societies \nmobility and the study of the origins of cit ies and early state formation. In \nthese cases\, archaeological data pr oduced by excavation and field survey or \nretrieved from different types of available archives\, are not only huge in \nquantity but also in div ersity and complexity\, and the computing power needed for \ntheir analys is\, simulation and visualisation is very large. The purpose is then \nwor king towards a landscape archaeology which should reconstruct the evolutio n of \nsettlement organization on the studied region with a low or high sp atio-temporal \nresolution in relation with the analysed level\, intersite \, intrasite or regional. \nFor such a precise reconstruction of geomorph ology\, hydrology\, climate\, landcover \nand landuse of the region\, base d on known data\, must be done using models and \nsimulation. Moreover\, a s a social and historical science\, such a simulation cannot \nstops at th e physical elements\, but it should include the study of demographic \nvar iation\, including demographic models\, settlement and urban dynamics and \nproduction and exchange models. \n\nAll that means that archaeology is a computer intensive discipline. Model building \nis time consuming and res ource intensive\, and archaeological data are huge. They \nalso are unique in character\, so they cannot be substituted\, because they need care \n to preserve. Everything in our analysis has to be preserved and stored\, b ut also the \ninformation about them. The results of simulated data must b e preserved for a long \ntime because they represent the status of the dat a interpretation at some date and \nwill be useful for future analysis.("C risis of Curation"). For the previous reasons \nthe archaeology need to e xploit the GRID technology for data access\, storage and \nmanagement\, for data analysis\, for simulation\, for archaeological knowledge \ncircu lation : from WEB to GRID. ArchaeoGRID will offer the unique opportunity t o \nshare data\, processing and model building opportunities with other br anches of \nscience and create synergy with other GRID projects.( Earth Sc iences\, Digital \nLibrary\, Astrophysics GRID projects\, etc. )\nThe star ting project proposes to begin with the study of the origin of the city i n \nMediterranean area between XI and VIII Centuries B.C. using the GILDA t-\nInfrastructure. The study will provide a functional framework for bro ad studies of \nthe interactions of humans in ancient urban societies and with the environment .\nDuring the past fifteen years\, archaeologists in the Mediterranean have accumulated \nlarge amounts of computerized data t hat have remained trapped in localized and often \nproprietary databases. It is now possible to change that situation. ArchaeoGRID will \nbe made to facilitate ways in which such data might be brought together and shared \ nbetween researchers\, students\, and the general public. Archaeological data always \nincludes an intrinsic geographic component\, and the compila tion and sharing of \ngeographic data through GIS has become increasingly important in the governmental\, \nprivate sector and academic worlds durin g the past years. New GRID technologies for \nspatial data\, expansion of the Web Services and development of open GIS \ntechnology now make it p ossible to share geographic information quickly\, widely and \neffectively . \nThe first application running on the GILDA be will be related with pal eoclimate and \nweather simulation in the regions where the urban centers originate around the IX \nand VIII centuries B.C. In fact weather phenomen a\, climate and climate changes \nproduced effects on individuals and soc ieties in the past. In the next future\, \nGILDA will be used to explore the possibilities of different computational \nmethodologies insiting of t he tools for the analysis of spatio-temporal data. \nClassical statistical analysis of spatio-temporal series will be used\, but also we \nintend to develop new methods for the analysis of longitudinal analysis\, based on \nneural networks technology.\nSimulation programs and data available on t he web and free will be used for \napplication. Such data could be integra ted with data from archaeological excavation \nand survey. The complexity and the dimension of program code and data require the \nuse of MPI librar y for parallel calculation on GILDA computers using Linux OS.\nOpen source GRASS GIS and package R for statistical analysis installed on GILDA will \ngive the possibility to prepare the input data for the full Mediterranea n area and \nfor the territories of the urban centers. \nA schematic archi tecture of the ArchaeoGRID showing the relevant parts and their \nlinks wi ll be presented. Given the intrinsic nature of archaeological field work\, \nthe communication and the information exchange between groups on site a nd groups \nworking in distant laboratories\, museums and universities nee d fast and efficient \ncommunication ways. Telearchaeology lies at the re al nature of archaeological \nendeavor and could be very useful also for education and for diffusion of the \narchaeological knowledge. A multicas t architecture for advanced videoconferencing \nspecially tailored for lar ge scale persistent collaboration could be used. \nThe added value\, linke d with new perspectives of the archaeological and historical \nresearch\, with the management of the archaeological heritage\, with the media \nprod uction\, with the territory management and with tourism\, will be discuss ed.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=45&sessionId =11&confId=286 LOCATION:CERN 40-SS-D01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=45&sessionId=11 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Experience Supporting the Integration of LHC Experiments Software Framework with the LCG Middleware DTSTART;VALUE=DATE-TIME:20060302T131000Z DTEND;VALUE=DATE-TIME:20060302T132500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-42@cern.ch DESCRIPTION:Speakers: Dr. SANTINELLI\, roberto (CERN/IT/PSS)\nThe LHC expe riments are currently preparing for data acquisition in 2007 and because \ nof the large amount of required computing and storage resources\, they de cided to \nembrace the grid paradigm. The LHC Computing Project (LCG) prov ides and operates a \ncomputing infrastructure suitable for data handling\ , Monte Carlo production and \nanalysis.\n While LCG offers a set of high level services\, intended to be generic enough to \naccommodate the needs of different Virtual Organizations\, the LHC experiments \nsoftware framew ork and applications are very specific and focused on the computing \nand data models. \nThe LCG Experiment Integration Support team works in close contact with the \nexperiments\, the middleware developers and the LCG cer tification and operations \nteams to integrate the underlying grid middlew are with the experiment specific \ncomponents. The strategical position be tween the experiments and the middleware \nsuppliers allows EIS team to pl ay a key role at communications level between the \ncustomers and the serv ice providers.\nThis activity is the source of many improvements on the mi ddleware side\, especially \nby channelling the experience and the require ments of the LHC experiments. \n\n The scope of the EIS activity encompass es several areas:\n\n1) Understanding of the experiment needs\n2) Identify open issues and possible solutions\n3) Develop specific interfaces\, serv ices and components (when missing in or not yet \nsatisfactory)\n4) Provid e operational support during Data Challenges\, Service Challenges and \nma ssive productions. \n5) Provide and maintain the user documentation\;\n6) Provide tutorial for the users community\n\nIn the last year\, the focus h as been extended also to non High-Energy Physics \ncommunities like Biomed \, GEANT4 and UNOSAT. In this work we discuss the EIS \nexperience\, descr ibing the issues raising in the organization of the Virtual \nOrganization support and the achievements\, together with the lessons learned. This \n activity will continue in the framework of EGEE II\, and we believe could be an \nexample for several users communities on how to optimise their upt ake of grid \ntechnology in the most efficient way.\n\nhttp://indico.cern. ch/contributionDisplay.py?contribId=42&sessionId=17&confId=286 LOCATION:CERN 40-S2-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=42&sessionId=17 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:MEDIGRID: Mediterranean Grid of Multi-risk data and Models DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-43@cern.ch DESCRIPTION:Speakers: Dr. HLUCHY\, Ladislav (Institute of Informatics\, Sl ovakia)\nWe present an IST project of the 6th Framework Programme\, aimed to create a \ndistributed framework for multi-risk assessment of natural d isasters that will \nintegrate various models for simulation of forest fir e behavior and effects\, flood \nmodeling and forecasting\, landslides and soil erosion simulations. Also\, a \ndistributed repository with earth ob servation data\, combined with field \nmeasurements is being created\, whi ch provides data to all models using data format \nconversions when necess ary. The entire system of models and data will be shaped \nfurther as a mu lti-risk assessment and decision support information platform. \n \n There are 6 partners in the project from Greece\, Portugal\, France\, Spain\, U nited \nKingdom and Slovakia. \n \nThe system targets both Linux and Wind ows based simulation models. The Linux based \nmodels are meteorological\, hydrological and hydraulics models of the flood \nforecasting application \, with meteorology and hydraulics being a parallel MPI \ntasks. Other app lications - forest fire behaviour and effects\, landslides and soil \neros ion - are sequential Windows jobs. These simulations are being merged into one \nsystem that uses common distributed data warehouse containing data for pilot areas \nin France\, Portugal and Spain. User should be able to t ransparently run these \nsimulations from the application portal\, reuse d ata between models and store the \nresults annotated with metadata back to the data warehouse. \n \n In order to create a virtual organization (VO) for multi-risk assessment of \nnatural disasters a grid middleware had to be chosen to be used on computing \nresources. Because each of the partne rs provides some of the services on his own \nresources that run both Linu x and Windows\, we could not use available middleware \ntoolkits like LCG or Globus as they are focused on Unix/Linux platform. For \nexample\, they build their data services on the GridFTP standard for data transfer. \nHo wever\, there are stable implementations of GridFTP just for Unix based sy stems\, \nignoring the world of Windows. Therefore\, we have decided to im plement our own data \ntransfer and job submission services. In order to k eep some compatibility with the \nestablished grid infrastructures\, we ha ve chosen the Java implementation of the \nWSRF specification by the Globu s alliance as a base for our services. It is an \nimplementation of core w eb (grid) services with security\, notifications and other \nfeatures and it is capable of running on both Windows and Linux. Each of the system \nc omponents - simulation models\, data providers\, information services or o ther \nsupporting services - is exposed as a web service. We use WSRF as a standard basic \ntechnology that both serves as an implementation framewo rk for individual services \nand also enables to glue the individual compo nents together. \n \n The whole system will be accessible via a web portal . We have chosen GridSphere \nportal framework for its support of portlet specification. Application specific \nportlets will allow users to invoke all the simulation services plugged into the \nsystem in application speci fic manner\; for example using maps for selection of a \ntarget area or an ignition points for forest fire simulations. There will be \nportlets for browsing results\, metadata describing those results\, testbed \nmonitori ng and others. \n \n So far\, two services have been implemented on top o f the WSRF: Data Transfer \nservice and Job Submission service. \n \nData Transfer service serves as a replacement for widely used GridFTP tools. T he \nmain disadvantage of GridFTP is that implementations are available ju st for the \nUNIX platforms. In Medigrid\, Windows is a platform of severa l models and porting \nthem to UNIX world was not an option for developers . \n \nData Transfer service provides data access policies definition and enforcement in \nterms of access control lists (ACLs) defined for each da ta resource - a named \ndirectory serving as a root directory for given di rectory tree accessible via the \nservice. It has been integrated with cen tral catalog services we have deployed: \nReplica Location Service - a ser vice from Globus toolkit for which we had to \nimplement WSRF wrapper - an d Metadata Catalog Service - a service from Gryphyn \nproject that is just a plain web service. \n \nJob Submission service provides the ability to run the executable associated to it \nwith parameters provided with job s ubmission request. Currently\, jobs are started \nlocally using the "fork" mechanism on both Linux and Windows. Requests are queued \nby the service and run in the "first come first served" manner in order not to \noverloa d the computer. In near future we plan to add job submission forwarding fr om \nthe service to a Linux cluster and later on to a classical grid.A bas e of the \nproject's portal has been set up based on the Gridsphere portal framework. Thus far \nportlets have been developed for browsing the conte nts of the metadata catalog \nservice and a portlet for generic job submis sion. \n \n As it can be seen in this project\, the world of simulations is not limited to the \nUnix platform and support for Windows applications is desired but missing.Therefore \nwe think it may be important for the E GEE project to try to suppport Windows users \nin order to widen its reach and appeal.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=43& sessionId=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=43&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:SIMRI@Web : An MRI Simulation Web Portal on EGEE Grid Architecture DTSTART;VALUE=DATE-TIME:20060301T161500Z DTEND;VALUE=DATE-TIME:20060301T163000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-40@cern.ch DESCRIPTION:Speakers: Prof. BENOIT-CATTIN\, Hugues (CREATIS - UMR CNRS 551 5 - U630 Inserm)\nIn this paper\, we present a web protal that enables sim ulation of MRI images on the \ngrid. Such simulations are done using the S IMRI MRI simulator that is implemented on \nthe grid using MPI. MRI simula tions are useful for better understanding the MRI \nphysics\, for studying MRI sequences (parameterisation)\, and validating image \nprocessing algo rithms. The web portal client/server architecture is mainly based on \na j ava thread that screens a data base of simulation jobs. The thread submits the \nnew jobs to the grid\, and updates the status of the running jobs. When a job is \nterminated\, the thread sends the simulated image to the u ser. Through a client web \ninterface\, the user can submit new simulation jobs\, get a detailed status of the \nrunning jobs\, have the history of all the terminated jobs as well as their status \nand corresponding simula ted image.\nAs MRI simulation is computationally very expensive\, grid tec hnologies appear to a \nreal added value for the MRI simulation task. Neve rtheless the grid access should be \nsimplified to enable final user runni ng MRI simulations. That is why we develop a \ntis specific web portal to propose a user friendly interface for MRI simulation on \nthe grid.\n\nhtt p://indico.cern.ch/contributionDisplay.py?contribId=40&sessionId=9&confId= 286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=40&sessionId=9& confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:The gLite Workload Management System DTSTART;VALUE=DATE-TIME:20060302T133000Z DTEND;VALUE=DATE-TIME:20060302T140000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-87@cern.ch DESCRIPTION:Speakers: GIACOMINI\, Francesco (Istituto Nazionale di Fisica Nucleare (INFN))\nThe Workload Management System (WMS) is a collection of components\nproviding a service responsible for the distribution and manag ement of\ntasks across resources available on a Grid\, in such a way that\ napplications are conveniently\, efficiently and effectively executed.\n\n The main purpose of the WMS as a whole is then to accept a request of\nexe cution of a job from a client\, find appropriate resources to\nsatisfy it and follow it until completion\, possibly rescheduling it\,\ntotally or in part\, if an infrastructure failure occurs. A job is\nalways associated t o the credentials of the user who submitted it. All\nthe operations perfor med by the WMS in order to complete the job are\ndone on behalf of the own ing user. A mechanism exists to renew\ncredentials automatically and safel y for long-running jobs.\n\nThe different aspects of job management are ac complished by different\nWMS components\, usually implemented as different processes\ncommunicating via data structures persistently stored on disk to avoid\nas much as possible data losses in case of failure.\n\nRecent re leases of the WMS come with a Web Service interface that has\nreplaced the custom interface previously adopted. Moving to formal or\nde-facto standa rds will continue in the future.\n\nIn order to track a job during its lif etime\, relevant events (such as\nsubmission\, resource matching\, running \, completion) are gathered from\nvarious WMS components as well as from G rid resources (typically\nComputing Elements)\, which are properly instrum ented. Events are kept\npersistently by the Logging and Bookkeeping Servic e (LB) and indexed\nby a unique\, URL-like job identifier. The LB offers a lso a query\ninterface both for the logged raw events and for higher-level task\nstate. Multiple LBs may exist\, but a job is statically assigned to one\nof them. Being the LB designed\, implemented and deployed so that th e\nservice is highly reliable and available\, the WMS heavily relies on it \nas the authoritative source for job information.\n\nThe types of job cur rently supported by the WMS are diverse:\nbatch-like\, simple workflow in the form of Directed Acyclic Graphs\n(DAGs)\, collection\, parametric\, in teractive\, MPI\, partitionable\,\ncheckpointable. The characteristics of a job are expressed using a\nflexible language called Job Description Lang uage (JDL). The JDL also\nallows the specification of constraints and pref erences on the\nresources that can be used to execute the job. Moreover so me\nattributes exist that are useful for the management of the job itself\ ,\nfor example how much to insist with a job in case of repeated failures\ nor lack of resources.\n\nOf the above job types\, the parametric jobs\, t he collections\, and the\nworkflows have recently received special attenti on.\n\nA parametric job allows the submission of a large number of almost\ nidentical jobs simply specifying a parameterized description and the\nlis t of values for the parameter.\n\nA collection allows the submission of a number of jobs as a single\nentity. An interesting feature in this case is the possibility to\nspecify a shared input sandbox. The input sandbox is a group of files\nthat the user wishes to be available on the computer whe re the job\nruns. Sharing a sandbox allows some significant optimization i n\nnetwork traffic and\, for example\, can greatly reduce the submission\n time.\n\nSupport for workflows in the gLite WMS is currently limited to\nD irected Acyclic Graphs (DAGs)\, consisting of a set of jobs and a set\nof dependencies between them. Dependencies represent time\nconstraints: a chi ld cannot start before all parents have successfully\ncompleted. In genera l jobs are independently scheduled and the choice\nof the computing resour ce where to execute a job is done as late as\npossible. A recently added f eature allows to collocate the jobs on the\nsame resource. Future improvem ents will mainly concern error handling\nand integration with data managem ent.\n\nParametric jobs\, collections and workflows have their own job\nid entifier\, so that all the jobs belonging to them can be controlled\neithe r independently or as a single entity.\n\nFuture developments of the WMS w ill follow three main lines: stronger\nintegration with other services\, s oftware cleanup\, and scalability.\n\nThe WMS already interacts with many external services\, such as Logging\nand Bookkeeping\, Computing Elements\ , Storage Elements\, Service\nDiscovery\, Information System\, Replica Cat alog\, Virtual Organization\nMembership Service (VOMS). Integration with a policy engine (G-PBox)\nand an accounting system (DGAS) is progressing\; this will ease the\nenforcement of local and global policies regulating th e execution of\ntasks over the Grid\, giving fine control on how the avail able\nresources can be used. Designing and implementing a WMS that relies on\nexternal services for the above functionality is certainly more\ndiffi cult than providing a monolithic system\, but in fact doing so\nfavors a g eneric solution that is not application specific and can be\ndeployed in a variety of environments.\n\nThe cleanup will affect not only the existing code base\, but will also\naim at improving the software usability and at simplifying service\ndeployment and management. This effort will require the evaluation and\npossibly the re-organization of the current components \, yet keeping\nthe interface.\n\nLast but not least\, considerable effort needs to be spent on the\nscalability of the service. The functionality c urrently offered\nalready allows many kinds of applications to port their computing\nmodel onto the Grid. But additionally some of those application s have\ndemanding requirements on the amount of resources\, such as comput ing\,\nstorage\, network\, and data\, they need to access in order to acco mplish\ntheir goal. The WMS is already designed and implemented to operate in\nan environment with multiple running instances not communicating with \neach other and seeing the same resources. This certainly helps in case\n the available WMSs get overloaded: it is almost as simple as starting\nano ther instance. Unfortunately this approach cannot be extended much\nfurthe r because it would cause too much contention on the available\nresources. Hence the short term objective is to make a single WMS\ninstance able to m anage 100000 jobs per day. In the longer term it\nwill be possible to depl oy a cluster of instances sharing the same\nstate.\n\nhttp://indico.cern.c h/contributionDisplay.py?contribId=87&sessionId=15&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=87&sessionId=15 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:The Grid and the LHC experiments: achievements and open issues DTSTART;VALUE=DATE-TIME:20060301T102000Z DTEND;VALUE=DATE-TIME:20060301T110500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-1@cern.ch DESCRIPTION:Speakers: BROOK\, Nick (CERN and Bristol University)\nhttp://i ndico.cern.ch/contributionDisplay.py?contribId=1&sessionId=8&confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=1&sessionId=8&c onfId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Setting the scene DTSTART;VALUE=DATE-TIME:20060301T090500Z DTEND;VALUE=DATE-TIME:20060301T093500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-5@cern.ch DESCRIPTION:Speakers: JONES\, Bob (CERN)\n \n\nhttp://indico.cern.ch/cont ributionDisplay.py?contribId=5&sessionId=8&confId=286 LOCATION:CERN Main Auditorium URL:http://indico.cern.ch/contributionDisplay.py?contribId=5&sessionId=8&c onfId=286 END:VEVENT BEGIN:VEVENT SUMMARY:The EGRID facility DTSTART;VALUE=DATE-TIME:20060301T140000Z DTEND;VALUE=DATE-TIME:20060301T141500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-77@cern.ch DESCRIPTION:Speakers: Dr. COZZINI\, Stefano (CNR-INFM Democritos and ICTP) \nThe EGRID project aims at implementing a national Italian facility for p rocessing \neconomic and financial data using computational grid technolog y. As such\, it acts \nas the underlying fabric on top of which partner pr ojects\, more strictly focused on \nresearch in itself\, develop end-user applications.\nThe first version of the EGRID infrastructure has been in o peration since October \n2004. It is based on European Data-Grid (EDG) and the Large Hadron Collider \nComputing Grid (LCG) middleware\, and it is h osted as an independent Virtual \nOrganization (VO) within INFN’s grid.I T. Several temporary workarounds were \nimplemented mainly to tackle priva cy and security issues on data management: in \nthese last few months the infrastructure was fully re-designed\nto better address them. The redesign ed infrastructure makes use of several new \ntools: some are part of EDG/L CG/EGEE middleware\, while some others were developed \nindependently with in EGRID. Moreover the EGRID project joined recently EGEE as \npilot appli cation in the field of finance\, which means that the EGRID VO will be \ns oon recognized on the full EGEE computational grid\; this may impose some \ncompatibility constraints because of the afore mentioned additions we ma ke\, which \nwe will handle when the time comes.\n\nThe new infrastructure will be composed of various architectural layers that will \ntake care of different aspacts. \n\nSecurity issue has been handled at the low middle ware level that manages data: an \nimplementation of the SRM (Storage Reso urce Manager ) protocol is being completed \nwhere novel ideas have been a pplied\, thereby breaking free from the limitations of \ncurrent approache s. Indeed\, the SRM standard is becoming widely used as a storage \naccess interface and\, hopefully\, it will soon be available on the full EGEE \ ninfrastructure. The EGRID technical staff has an on-going long time colla boration \nwith INFN/CNAF on the StoRM SRM server\, with the intention to use this software for \nproviding the kind of fine grained access control that the project demands.\nWhat StoRM does is to add appropriate permissio ns (using POSIX ACLs) to a file \nbeing requested by a user\, and to remov e them when the client is done with the \nfile. Since permissions are gran ted on-the-fly\, grid users can be mapped into pool \naccounts\, and no sp ecial permission sets need to be enforced prior to grid usage.\nAn importa nt role is given to a secure web service (ECAR) built by EGRID to act as \ na bridge between the (resource-level) StoRM SRM server\, and the (grid-le vel) \ncentral LFC logical filename catalog from EGEE that replaces the ol d RLS of EDG.\nThe LFC natively implements POSIX-like ACLs on the logical file names\; the StoRM \nserver can thus read (via ECAR) the ACLs on the l ogical filename corresponding to a \ngiven physical file and grant or deny access to the local files\, depending on the \npermissions on the LFC. Th is provides users with a consistent view of the files in \ngrid storage.\n \nAt a higher level\, in order to make even more transparent the usage of data in the \ngrid\, we also developed ELFI that allows grid resources to be accessed through the \nusual POSIX I/O interface. Since ELFI is a FUSE file-system implementation\, grid \nresources are seen through a local mou nt-point so all the existing tools for \nmanaging the file-system automati cally apply: the classical command line\, any \ngraphical user interface s uch as Konqueror\, etc. Programs too will only have to\nbe interfaced with POSIX\, thereby aiding in grid prototyping/porting of \napplications.\nEL FI will be installed on all WN of the farm\, so applications will no longe r need \nto explicitly run file transfer commands but simply access them d irectly as though \nthey were local. Moreover\, ELFI will be able to fully communicate with StoRM\, and \nit will be installed in the host where the portal resides thereby easing portal \nintegration of SRM resources.\n\n\ nThe new EGRID infrastructure can be accessed via a web portal\, one of th e most \neffective ways to provide an easy-to-use interface to a larger co mmunity of users: \nthe portal will become the main interface for naive us ers.\nThe EGRID portal that is currently under development is based on P-g rade\, and \ninherits all the features already available there: still some parts must be \nenhanced to comply with our requirements. The P-grade tec hnology was chosen because \nit seemed sufficiently sophisticated and matu re to meet our needs.\nHowevever there are still missing functionalities i mportant to EGRID.We are \ncurrently collaborating with the P-grade team i n order to develop and integrate \nwhat we need:\n\nImproved proxy managem ent\n\nCurrently private key of the user must go through the portal\, and then into the \nMyProxy server\; we feel that for EGRID it should instead be uploaded directly from \nthe client machine without passing through the server: this is needed to decrease \nsecurity risks. To accomplish it we implemented a Java WebStart application which \ncarries out the direct upl oading. The application is seamlessly integrated into P-\ngrade\, through the standard "upload" button of the "certificates" portlet.\n\nData manage ment portlet that uses ELFI\n\nCurrently P-grade does not support the SRM protocol and does not support browsing of\nfiles present in the machine ho sting the portal itself. Since ELFI is our choice \nfor accessing grid dis k resources in general\, including those managed through \nStoRM\, a speci fic Portlet was written to browse and manipulate the file system \npresent in the portal server itself. In fact ELFI allows grid resources to be see n \nas a local mount point as already mentioned it becomes easier to modif y the portal \nfor local operations rather than for some other grid servic e.\nThe Portlet allows manual transfer of files between different director ies of the \nportal host\, but since some of these directories are ELFI mo unt points then \nautomatically a grid operation takes place behind the sc enes. So what happens is a \nfile movement between the portal server\, rem ote storage and computing elements.\n\nFile management and job submission interaction\n\nA new file management mechanism is needed besides that curr ently supporting "local" \nand "remote" files: similarly to the previous p oint what is required is "local on \nthe portal server"\, since the portal host will have ELFI mount points allowing \ndifferent grid resources to b e seen as local to the portal host. In this way the \nworkflow manager wil l be able to read/write input and output data through the SRM \nprotocol.\ nMoreover\, EGRID also needs a special version of job submission closely r elated to \nworkflow jobs: what we call swarm jobs. These jobs are such th at the application \nremains the same while the input data changes paramet rically over several possible \nvalues\; then a final job collects all res ults and makes some aggregate computation \non them. At the moment the spe cification of each input parameter is done manually: \nan automatic mechan ism is required.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId =77&sessionId=12&confId=286 LOCATION:CERN 40-4-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=77&sessionId=12 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Real time computing for financial applications DTSTART;VALUE=DATE-TIME:20060302T133000Z DTEND;VALUE=DATE-TIME:20060302T140000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-76@cern.ch DESCRIPTION:Speakers: Dr. COZZINI\, Stefano (CNR-INFM Democritos and ICTP) \nComputing grids are quite attractive for large scale financial applicati ons: this \nis especially evident in the segment of dynamic financial serv ices\, where \napplications must complete complex tasks within strict dead lines. The traditional \nresponse has been to over-provision for making su re there is plenty of ’headroom’ \nin resource availability\, thereby maintaining large computational resources booked \nand unused with a great cost in terms of infrastructure. Moreover nowadays some of \nthese comple x tasks need an amount of computing power that is unfeasible to keep in \n house.\nComputing grids can deliver the amounts of power needed in such a scenario\, but \nthere are still large limitations to overcome. In this br ief report we address the \nsolution we developed to provide real time com puting power through the EGRID \nfacility for a test case financial appli cation.\nThe test case we consider is an application that estimates the se nsitivities of a \nset of stocks\nto specific risk factors: technical deta ils about the procedure can be found \nelsewhere\; we will present here on ly the computational details of the \napplication to better define the pro blem we faced\, and the solutions adopted for \nporting it to the grid.\n\ nWe implemented different technical solutions for our application in a sor t of trial \nand error fashion. We will present briefly all of the attempt s.\n\nAll implemented solutions rely on a “job reservation mechanism”: we allocate grid \nresources in advance to eliminate latency due to the j ob submission mechanism. In \nthis way\, as soon as we get enough resource s allocated we can interact with them in \nreal time.\nThe drawback is tha t being an advanced booking strategy\, for “best effort” services \nth is approach could be unfeasible. It is not the case for this experimental work \nthough\, but the limitation should be taken into account when appro aching production \nruns.\nThe booking mechanism has been implemented in t he following way. An early \nsubmission of a bunch of jobs is run for secu ring the availability of WN at a given \ntime. \nEach pooled node will exe cutes a program that regularly checks a host (usually the \nUI\, but not n ecessarily). The contacted host enrolls this WN for the user’s \nprogram \, as soon as the user executes that program. When the\nexecution terminat es the results are available in real time without any delay \nintroduced b y WMS of the grid. The WNs remain booked\, and so are ready to be \nenroll ed again for other program executions\; eventually they are freed by the u ser.\nThis approach\, where the WN asks to be enrolled in a computation th ereby acting as \na client\, is needed because the WN cannot be reached di rectly from the UI.\n\nhttp://indico.cern.ch/contributionDisplay.py?contri bId=76&sessionId=16&confId=286 LOCATION:CERN 40-4-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=76&sessionId=16 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:SALUTE – GRID Application for problems in quantum transport DTSTART;VALUE=DATE-TIME:20060301T133000Z DTEND;VALUE=DATE-TIME:20060301T134500Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-75@cern.ch DESCRIPTION:Speakers: Prof. KARAIVANOVA\, Aneta (IPP-BAS)\nAuthors: E. Ata nassov\, T. Gurov\, A. Karaivanova and M. Nedjalkov\n Department o f Parallel Algorithms\n Institute for Parallel Processing - Bulgar ian Academy of Sciences\n E-mails:{emanouil\, gurov\, anet\, mixi} @parallel.bas.bg\n\nAbstract body:\nSALUTE (Stochastic ALgorithms for Ultr a-fast Transport in sEmiconductors) is an MPI \nGrid application developed for solving computationally intensive problems in \nquantum transport.\n \nMonte Carlo (MC) methods for quantum transport in semiconductors and sem iconductor \ndevices have been actively developed during the last decade. If temporal or spatial \nscales become short\, the evolution of the semico nductor carriers cannot be \ndescribed in terms of the Boltzmann transport [1] and therefore a quantum \ndescription is needed. We note the importan ce of active investigations in this \nfield: nowadays nanotechnology provi des devices and structures where the carrier \ntransport occurs at nanomet er and femtosecond scales. As a rule quantum problems \nare very computati onally intensive and require parallel and Grid implementations. \n\nSALUTE is a pilot grid application developed at the Department of Parallel \nAlg orithms\, Institute for Parallel Processing - BAS where the stochastic app roach \nrelies on the numerical MC theory applied to the integral form of the generalized \nelectron-phonon Wigner equation. The Wigner equation for the nanometer and \nfemtosecond transport regime is derived from a three equations set model based on \nthe generalized Wigner function [2]. The fu ll version of the equation poses serious \nnumerical challenges. Two major formulations (for homogeneous and inhomogeneous \ncases) of the equation are studied using SALUTE. \n\nThe physical model in the first formulation describes a femtosecond relaxation \nprocess of optically excited electro ns which interact with phonons in one-band \nsemiconductor [3]. The intera ction with phonons is switched on after a laser pulse \ncreates an initial electron distribution. Experimentally\, such processes can be \ninvestiga ted by using ultra-fast spectroscopy\, where the relaxation of electrons i s \nexplored during the first hundreds femtoseconds after the optical exci tation. In \nour model we consider a low-density regime\, where the intera ction with phonons \ndominates the carrier-carrier interaction. In the sec ond formulation we consider a \nhighly non-equilibrium electron distributi on which propagates in a quantum \nsemiconductor wire [4]. The electrons\, which can be initially injected or optically \ngenerated in the wire\, be gin to interact with three dimensional phonons. The \nevolution of such pr ocess is quantum\, both\, in the real space due to the \nconfinements of t he wire\, and in the momentum space due to the early stage of the \nelectr on-phonon kinetics. A detailed description of the algorithms can be found in \n[5\, 6\, 7].\n\nMonte Carlo applications are widely perceived as comp utationally intensive but \nnaturally parallel. The subsequent growth of c omputer power\, especially that of the \nparallel computers and distribute d systems\, made possible the development of \ndistributed MC applications performing more and more ambitious calculations. \nCompared to the parall el computing environment\, a large-scale distributed computing \nenvironme nt or a Computational Grid has tremendous amount of computational power. \ nLet us mention the EGEE Grid which today consists of over 18900 CPU in 20 0 Grid \nsites. \n\nSALUTE solves an NP-hard problem concerning the evolut ion time. On the other hand\, \nSALUTE consists of Monte Carlo algorithms which are inherently parallel. Thus\, \nSALUTE is a very good candidate fo r implementations on MPI-enabled Grid sites. By \nusing the Grid environme nt provided by the EGEE project middleware\, we were able to \nreduce the computing time of Monte Carlo simulations of ultra-fast carrier \ntranspor t in semiconductors. The simulations are parallelized on the Grid by \nspl itting the underlying random number sequences. \n\nSuccessful tests of the application were performed at several Bulgarian and South \nEast European EGEE GRID sites using the Resource Broker at IPP-BAS. The MPI version \nw as MPICH 1.2.6\, and the execution was performed on clusters using both pb s and \nlcgpbs jobmanagers\, i.e. with shared or non-shared home directori es. The test \nresults show excellent parallel efficiency. Obtaining resul ts for larger evolution \ntimes requires more computational power\, which means that the application should \nrun on larger sites or on several site s in parallel. The application can provide \nresults for other types of se miconductors like Si or for composite materials.\n\nFigure 1. Distribution of optically generated electrons in a quantum wire.\n\nREFERENCES\n[1] J. Rammer\, Quantum transport theory of electrons in solids: A single-\npart icle approach\, Reviews of Modern Physics\, series 63 no 4\, 781 - 817\, 1 991.\n[2] M. Nedjalkov\, R. Kosik\, H. Kosina\, and S. Selberherr\, A Wign er Equation for \nNanometer and Femtosecond Transport Regime\, In: Proceed ings of the 2001 First IEEE \nConference on Nanotechnology\, (October\, Ma ui\, Hawaii)\, IEEE\, 277-281\, 2001.\n[3] T.V. Gurov\, P.A. Whitlock\, "A n efficient backward Monte Carlo estimator for \nsolving of a quantum kine tic equation with memory kernel"\, Mathematics and \nComputers in Simulati on\, Vol. 60\, 85-105\, 2002.\n[4] M. Nedjalkov\, T. Gurov\, H. Kosina\, D . Vasileska. and V. Palankovski\, \nFemtosecond Evolution of Spatially Inh omogeneous Carrier Excitations: Part I: \nKinetic Approach\, to appear in Lecture Notes in Computing Sciences\, Springer-Verlag \nBerlin Heidelberg\ , Vol. 3743\, (2006)\n[5] E. Atanassov\, T. Gurov\, A. Karaivanova\, and M . Nedjalkov\, SALUTE – an MPI \nGRID Application\, in: Proceedings of th e 28th International Convetion\, MIPRO 2005\, \nMay 30-June 3\, Opatija\, Croatia\, 259 - 262\, 2005.\n[6] T.V. Gurov\, M. Nedjalkov\, P.A. Whitlock \, H. Kosina and S. Selberherr\, \nFemtosecond relaxation of hot electrons by phonon emission in presence of electric \nfield\, Physica B\, vol 314\ , p. 301\, 2002\n[7] T.V. Gurov and I.T. Dimov\, A Parallel Monte Carlo Me thod for Electron \nQuantum Kinetic Equation\, LNCS\, Vol. 2907\, Springer -Verlag\, 153—160\, 2004\n\nhttp://indico.cern.ch/contributionDisplay.py ?contribId=75&sessionId=12&confId=286 LOCATION:CERN 40-4-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=75&sessionId=12 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Migrating Desktop - graphical front-end to grid - On-line Demonstr ation DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-74@cern.ch DESCRIPTION:Speakers: PLOCIENNIK\, Marcin (PSNC)\, WOLNIEWICZ\, Pawel (PSN C)\nDemo description:\n\nDemo will show following features and functionali ty:\n- graphical user environment for job submission\, monitoring and othe r grid \noperations\n- running applications from different disciplines and communities\n- running within MD platform batch and MPI applications\n- r unning sequential and interactive applications\nTwo applications had been selected to present MD framework and mentioned above\nfeatures: parallel A NN training application\, MAGIC Monte Carlo Simulation \n\nParallel ANN tr aining application - Interactive application from CrossGrid\n–(descripti on of usecase in technical background section)\nThis application is used t o train an Artificial Neural Network (ANN) using\nsimulated data for the DELPHI experiment. The ANN is trained to distinguish between\nsignal (Higg s bosson) events and background event (in the demo the background used\nin cludes WW and QCD events). The evolution of the training can be monitored using \nthe\nMD with a graphics presenting curent error\, and 4 small grap hics that show the ANN\nvalue vs. an event variable (that can be selected by the user). The application is\ncompiled with MPICH-P4 for intracluster use and with MPICH-G2 for intercluster use.\nThis application uses the int eractive input channel to let the user make a clean \nstop\nof the trainin g (instead of killing the job)\, and also the possibility of resetting\nth e ANN weights to random values\, to avoid local minima.\n\nMAGIC Monte Car lo Simulation \nThe MAGIC Monte Carlos Simulation (MMCS) is one of the gen eric applications within\nEGEE. As the simulation of extensive air showers initiated by high\nenergetic cosmic rays is very compute intensive\, the MAGIC collaboration – together\nwith Grid resource centers from the EGEE project - migrate the MMCS application\nwithin the last years to the EGEE infrastructure to speed up the production of the\nsimulations. To get eno ugh statistics for a physics analysis\, many jobs with the \nsame\ninput p arameters but different random numbers needs to be submitted. The submissi on\ntools from the MAGIC Grid are integrated in the Migrating Desktop and its underlying\ninfrastructure. Therefore all services und features of the Migrating Desktop like \nJob\nMonitoring\, Data management\, etc. can be used by members of the MAGIC virtual\norganization. \n\n\n\nPlatform and s ervices\nTestbed:\n- EGEE production\, GILDA and CrossGrid testbed\nApplic ations:\n- MAGIC application running on EGEE\, \n- ANN interactive applica tion running on CrossGrid testbed \n\nServices:\n- usage of following EGEE services:\n - WMS: RB\, LB\, CE \n - Data Management: SE\, LCG-UTILS (Rep lica Manager)\n- Information Index\n- usage of following CrossGrid testbed services\n - WMS: RB\, LB\, CE \n - Data Management: SE\, LCG-UTILS (Repl ica Manager)\n- Information Index\n\n\nTechnical background:\n\nA number o f Grid middleware projects are working on user interfaces for interaction\ nwith grid applications\, however due to the dynamic and complex nature of the Grid\,\nit’s not easy to attract new users like ordinary scientists . To solve this problem \nwe\nintroduce the concept of Migrating Desktop w hich is a graphical\, user oriented tool\nthat simplifies the use of the g rid technology in the application area. \nThe Migrating Desktop (MD)is an advanced graphical user interface and a set of tools\ncombined with user-f riendly outlook\, similar to window based operating systems. It\nhides the complexity of the grid middleware and allows to access grid resources in \nan\neasy and transparent way with special focus on interactive and paral lel grid\napplications. These applications are both compute- and data-inte nsive and are\ncharacterised by the interaction with a person in a process ing loop. MD can attract\nnew users by its features: easy to use\, platfor m independed\, available everywhere\,\nenables possibility to easily add n ew application that can be batch or interactive\,\nsequential or parallel. Thanks to its open architecture it can easily integrate\nexisting or inco ming tools that for example supports grid operations or enables\ncollabora tive work. \nThis research refers to three different grid projects: EU Bal ticGrid project\, EU\nCrossGrid project\, and Progress (co-founded by Sun Microsystems and the Polish State\nCommittee for Scientific Research). As a key product of CrossGrid project\, Migrating\nDesktop has proved its use fulness in everyday work of users community. \n\nTechnical background\nPla tform overview\nThe aim of the Migrating Desktop is to provide scientists with a framework which\nhides the details of most Grid services and allows working with grid application in\nan easy and transparent way. The graphi cal user interface integrates and makes use \nof\nnumber of middleware and integrates the individual tools into a single product\nproviding a comple te grid front-end. It is built on base of a mechanism for\ndiscovering\, i ntegrating\, and running modules called bundles based on the OSGi\nspecifi cation. When the MD is launched\, the users can work with environment comp osed\nof the set of bundles. Usually a small tool is written as a single b undle\, whereas a\ncomplex tool has its functionality split across several bundles. A bundle is the\nsmallest unit of our platform that can be devel oped and delivered separately. Such\napproach allows increasing functional ity in an easy way without the need of\narchitecture changes.\nThe Migrati ng Desktop framework allows the user to access transparently the Grid\nres ources\, run sequential or interactive\, batch or MPI applications\, monit oring and\nvisualization\, and manage data files. MD provides a front-end framework for \nembedding\nsome of the application mechanisms and interfac es\, and allows the user to have\nvirtual access to Grid resources from ot her computational nodes.\nThe MD is a front end to The Roaming Access Serv er (RAS)\, which intermediates to\ncommunication with different grid middl eware and applications. The Roaming Access\nServer offers a well-defined s et of web-services that can be used as an interface \nfor\naccessing HPC s ystems and services (based on various technologies) in a common and\nstand ardised way. All communication bases on web services technology. \nOur pla tform can work with different grid testbeds: based on LCG 2.3/2.4\, LCG 2. 6\,\nProgress 1.0. Due to its open system nature it can be easily ported t o support other\ntestbeds.\n\nApplications use cases\n\nMAGIC Monte Carlo Simulation \nThe MAGIC Monte Carlos Simulation (MMCS) is one of the generi c applications within\nEGEE. As the simulation of extensive air showers in itiated by high energetic\ncosmic rays is very compute intensive\, the MAG IC collaboration– together with\nGrid resource centers from the EGEE pro ject - migrate the MMCS application within \nthe\nlast years to the EGEE i nfrastructure to speed up the production of the simulations.\nThe simulati on of the air showers requires the most computing time\, e.g. a request\nf or a Monte Carlo sample of 1.0 million gamma-events would need around 1500 \ncomputing\nhours on a standard CPU (2~MHz PentiumIV). This can be speed ed up by using many\nresources by parallelizing the application\, if possi ble. Therefore the simulation of\na Monte Carlo sample is split in subjobs of 1000 events to run in parallel on\ndistributed Grid resources.The resu lting 1000 data files are transferred and stored\non a dedicated Grid stor age center automatically when a subjob is finished. When all\nfiles are av ailable\, a program merges them to one single file that is processed by\nt he next program of the Monte Carlo workflow.\n\nTo track and manage the bi g number of jobs\, a meta database containing information\nabout single jo bs\, their status and available data was set up. The metadata are\nstored in a separate relational database combining information from the Grid doma in\nwith data needed by MAGIC scientists. A Grid user requests a given num ber of Monte\nCarlo events by writing this into the meta database\, while a daemon process \nregularly\nsubmits smaller bunches of subjobs to the Gr id resources. The current implementation\nof the MMCS system does not requ ire any additional software installation on Grid\nresources.\n\nThe submis sion tools from the MAGIC Grid are integrated in the Migrating Desktop and \nits underlying infrastructure. Therefore all services und features of th e Migrating\nDesktop like Job Monitoring\, Data management\, etc. can be u sed by members of the\nMAGIC virtual organization. \n\nInteractive Applica tion (CrossGrid) – Parallel ANN training application.\nThe user launches the ANN job wizard from the MD Job Wizard menu or from an already\nexisti ng job shortcut. After filling all the necessary parameters in Job Wizard the\nuser submits the job. Once it is running the ANN plugin can be launch ed. In the\nplugin the user can see a panel with four graphics representin g the value of the ANN\nfor a subset of the training events (signal events in green and background events in\nred) vs. several variables of the even ts. The user can change the selected variables\nusing the combo list at th e bottom of the plugin window. At the right side the user\ncan see the gra phic representing the evolution of the ANN training error vs the\ntraining epoch. The plugin also includes three options: "reset weights" that rese ts\nthe values of the ANN weights to random\, "Stop application" - the pr ogram goes out\nof the training loop stopping the training and "Exit" for closing the plugin window.\nThe user after the error is more or less in a plateau should press the "Reset\nweights" button and observe the error evo lution. Afterwards\, if necessary to finish\nthe demo the user can press t he "Stop Application" button.\n\nUsed technology\nThe Migrating Desktop ba ses on the Java applet technology. It can be launched using\nthe Java Webs tart technology or using a web browser with the appropriate Java Plug-\nin \nincluded in the Java Runtime Environment (JRE). We are basing on Swing libraries \nfor\ndesigning graphical user interface\, the Java CoG Kit ver sion 1.2 is being used as\nan interface to Globus (for operation on proxy and GridFTP/FTP) functionality and\nAxis ver.1.1 web services client for c ommunication with the Roaming Access\nServer. Migrating Desktop follows OS Gi Service Platform specification version 4\n(August 2005) and is based on the same plugin engine as Eclipse platform. Currently\nRAS for cooperatio n with EGEE infrastructure is using LCG2.6 platform but it is\nforeseen to move to gLite.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId= 74&sessionId=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=74&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:GridICE monitoring for the EGEE infrastructure DTSTART;VALUE=DATE-TIME:20060302T143500Z DTEND;VALUE=DATE-TIME:20060302T145000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-73@cern.ch DESCRIPTION:Speakers: Mr. ANDREOZZI\, Sergio (INFN-CNAF)\nGrid computing i s concerned with the virtualization\, integration and\nmanagement of servi ces and resources in a distributed\, heterogeneous\nenvironment that suppo rts collections of users and resources across\ntraditional administrative and organizational domains.\n\nOne aspect of particular importance is Grid monitoring\, that is the\nactivity of measuring significant Grid resource -related parameters\nin order to analyze usage\, behavior and performance of a Grid\nsystem. The monitoring activity can also help in the detection of\nfault situations\, contract violations and user-defined events.\n\nIn the framework of the EGEE (Enabling Grid for E-sciencE) project\,\nthe Gri d monitoring system called GridICE has been consolidated and\nextended in its functionalities in order to meet requirements from\nthree main categor ies of users: Grid operators\, site administrators\nand Virtual Organizati on (VO) managers. Besides the specific needs\nof these categories\, GridIC E offers a common sensing\, collection and\npresentation framework enablin g to share common features\, while also\noffering user-specific needs.\n\n A first common aspect to the different users is the set of\nmeasurements t o be performed. Typically\, there is a wide number of\nbase measurements t hat are of interest for all parties\, while a\nsmall number is specific to them. What makes the difference is the\naggregation criteria required to present the monitoring information.\nThis aspect is intrinsic to the multi dimensional nature of\nmonitoring data. Example of aggregation dimensions identified in\nGridICE are: the physical dimension referring to geographic al\nlocation of resources\, the Virtual Organization (VO) dimension\, the\ ntime dimension and the resource identifier dimension.\n\nAs an example\, considering the entity 'host' and the measure 'number\nof started processe s in down state'\, the Grid operator can be\ninterested in accessing the s um of the measurement values for all\nthe core machines (e.g.\, workload m anager\, computing element\,\nstorage element) in the whole infrastructure \, while the Virtual\nOrganization manager can be interested in the sum of the measurement\nvalues for all the core machines that are authorized to the VO\nmembers. Finally\, the site administrator can be interested in\nac cessing the sum of the measurement values for all machines part of\nits si te.\n\nAnother aspect that is common to all the consumers is being able to \nstart from summary views and to drill down to details. This feature\ncan enable to verify the composition of virtual pools or to sketch\nthe sourc es of problems.\n\nAs regards the distribution of monitoring data\, GridIC E follows a\n2-level hierarchical model: the intra-site level is within th e\ndomain of an administrative site and aims at collecting the\nmonitoring data at a single logical repository\; the inter-site level\nis across sit es and enables the Grid-wide access to the site\nrepository. The former is typically performed by a fabric monitoring\nservice\, while the latter is performed via the Grid Information\nService. In this sense\, the two leve ls are totally decoupled and\ndifferent fabric monitoring services can be adapted to publish\nmonitoring data to GridICE\, thought the proposed defa ult solution is\nthe CERN Lemon tool.\n\nConsidering the sensing activity\ , GridICE adopts the whole set of\nmeasures defined in the GLUE Schema 1.2 \, further it provides\nextensions to cover new requirements. The extensio ns include a more\ncomplete host-level characterization\, Grid jobs relate d attributes\nand summary info for batch systems (e.g.\, number of total s lots\,\nnumber of worker nodes that are down).\n\nThe development activity in the EGEE project has focused on the\nfollowing aspects: the redesign o f the presentation level took into\nconsideration the usability principles and compliance with W3C\nstandards\; sensors for measuring parameters rel ated to Grid job have\nbeen re-engineered to scale to the number of jobs e nvisioned by big\nsites (e.g.\, LCG Tier 1 centers)\; new sensors have bee n written to\ndeal with summary information for computing farms\; stabilit y and\nreliability of both server and sensors.\n\nThe deployment activity covers the whole EGEE framework with several\nserver instances supporting the work of different Grid sub-domains\n(e.g.\, whole EGEE Grid domain\, R OC domain\, national domain). Other\nGrid projects have adopted GridICE fo r monitoring their resources\n(e.g.\, EUMedGrid\, EUChinaGRID\, EELA).\n\n As regards the user experience\, GridICE has proven to be useful to\ndiffe rent users in different ways. For instance\, Grid operators have\nsummary views for aspects such as information sources status and\nhost status. Sit e administrators appreciate the job monitoring\ncapability showing the sta tus and computing activity of the jobs\naccepted in the managed resources. VO managers use GridICE to verify\nthe available resources and their stat us before to start the\nsubmission of a huge number of jobs. Finally\, Gri dICE has been\npositively adopted in dissemination activities.\n\nWhile Gr idICE has reached a good maturity level in the EGEE project\,\nmany challe nges are still open in the dynamic area of Grid systems.\nThe short term p lans are: (1) as regards the discovery process\,\nthere is the need to fin alize the transition from the MDS-based\ninformation service to the gLite service discovery plus publisher\nservices such as R-GMA producers and CEM on\; (2) integration with\ninformation present in the Grid Operation Cente r (GOC) database for\naccessing resource planned downtime and other manage ment\ninformation\; (3) tailored sensors for the workload management\nserv ice\; (4) sensors for measuring data transfer activities across\nGrid site s.\n\n\nReferences:\n\nDissemination website: http://grid.infn.it/gridice\ n\nPublications:\nhttp://grid.infn.it/gridice/index.php/Research/Publicati ons\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=73&sessionId =17&confId=286 LOCATION:CERN 40-S2-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=73&sessionId=17 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:gLite Service Discovery for users and applications DTSTART;VALUE=DATE-TIME:20060301T173000Z DTEND;VALUE=DATE-TIME:20060301T175000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-72@cern.ch DESCRIPTION:Speakers: Mr. WALK\, John (RAL)\nIn order to make use of the r esources of a grid\, to submit a job or query information\nfor example\, a user must contact a service that provides the capability\, usually via\na URL. Grid services themselves must often contact other services to do th eir work.\n In order to locate services\, some kind of dynamic service dir ectory is required and\nthere exist several grid information systems\, suc h as R-GMA and BDII\, that can\nprovide this service. However each inform ation system has its own unique interface\,\nso JRA1 have developed a stan dard Service Discovery API to hide these differences\nfrom applications th at simply want to locate services that meet their criteria.\n\nThe gLite S ervice Discovery API provides a standard interface to access service\ndeta ils published by information systems. There are four methods available fo r\ndiscovering services\, these are: listServices\, listAssociatedServices \,\nlistServicesByData and listServicesByHost. These all take a range of arguments for\nnarrowing the search and all return a list of service struc tures. Once you have\nfound a service it is then possible to use other me thods to obtain more detailed\ninformation about it (using its unique id). These methods are: getService\,\ngetServiceDetails\, getServiceData\, ge tServiceDataItem\, getServiceSite and getServiceWSDL.\n\nThe gLite Service Discovery API provides interfaces for the Java and C/C++\nprogramming lan guages and a command line tool (glite-sd-query). It uses plugins for\nthe R-GMA and BDII information systems\, and for retrieving the information f rom an\nXML file. Other plugins (e.g. UDDI) could be developed if needed.\ n\nJRA1 also provide a service tool\, rgma-servicetool\, to allow any serv ice running on a\nhost to easily publish service data via R-GMA. All a se rvice has to do is to provide\na description file that contains static inf ormation about itself and the name of a\ncommand to call\, plus any requir ed parameters\, in order to obtain the current state\nof the service. Thi s information is then published via R-GMA to a number of tables\nthat conf orm to the GLUE specification. The data published to these tables are use d\nby the R-GMA gLite Service Discovery implementation. Any service\, inc luding VO\nservices\, can make use of rgma-servicetool.\n\nThe existing sy stem assumes that the underlying information system has been correctly\nco nfigured. In the case of R-GMA this means that the client needs to know th e local\nR-GMA server (sometimes known as a "Mon box"). A user coming to a n unknown\nenvironment with a laptop needs to first find the information s ystem before\ninteracting with it. This is the well-known bootstrapping p roblem that can be solved\nby IP multicast techniques. We will provide di scovery of local services without\nmaking use of existing information syst ems and with near-zero configuration. Clients\nsend a multicast query to a multicast group and services that satisfy the query\nrespond directly to the client using unicast. This capability will initially be\nadded to R- GMA services. Once this has been done it will be possible to introduce\nad ditional R-GMA servers at a site\, for example to take increased load\, wi thout the\nneed to reconfigure any clients. The existing SD API with the R -GMA plugin will\nimmediately benefit from the new server. Subsequently th is component\, suitably\npackaged\, will be made available to other gLite services.\n\nThe combination of the rgma-servicetool and the gLite Service Discovery makes it\nsimple for any service to make itself known and then for user and high-level\napplications to find these services. In addition once the bootstrapping code is\ndeveloped and added to R-GMA\, the configu ration of R-GMA\, and thereby SD with the\nR-GMA plugin\, will become triv ial.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=72&sessionI d=22&confId=286 LOCATION:CERN URL:http://indico.cern.ch/contributionDisplay.py?contribId=72&sessionId=22 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:User Applications of R-GMA DTSTART;VALUE=DATE-TIME:20060302T160000Z DTEND;VALUE=DATE-TIME:20060302T163000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-71@cern.ch DESCRIPTION:Speakers: Dr. FISHER\, Steve (RAL)\nThe Relational Grid Monito ring Architecture (R-GMA) provides a uniform method to\naccess and publish both information and monitoring data. It has been designed to be\neasy f or individuals to publish and retrieve data. It provides information abou t the\ngrid\, mainly for the middleware packages\, and information about g rid applications for\nusers. From a user's perspective\, an R-GMA install ation appears as a single virtual\ndatabase. R-GMA provides a flexible in frastructure in which producers of information\ncan be dynamically created and deleted and tables can be dynamically added and\nremoved from a schem a. All of the data that is published has a timestamp\, enabling\nits use for monitoring. R-GMA is currently being used for job monitoring\,\nappli cation monitoring\, network monitoring\, grid FTP monitoring and the site\ nfunctional tests (SFT).\n\nR-GMA is a relational implementation of the Gl obal Grid Forum's (GGF) Grid Monitoring\nArchitecture (GMA). GMA defines producers and consumers of information and a\nregistry that knows the loca tion of all consumers and producers. R-GMA provides\nConsumer\, Producer\ , Registry and Schema services.\n\nThe consumer service allows the user to issue a number of different types of query:\nhistory\, latest and continu ous. History queries are queries over time sequenced data\nand latest que ries correspond to the intuitive idea of current information. For a\ncont inuous query\, new data are broadcast to all subscribed consumers as soon as those\ndata are published via a producer. Consumers are automatically m atched with producers\nof the appropriate type that will satisfy their que ry.\n\nData published by application code is stored by a producer service. R-GMA provides a\nproducer service that includes primary and secondary p roducers. Primary producers\nare the initial source of data within an R-G MA system. Secondary producers can be\nused to republish data in order to co-locate information to speed up queries (and\nallow multi-table queries )\, to reduce network traffic and to offer different producer\nproperties. It is envisaged that there will be numerous primary producers and one or \ntwo secondary producers for each subset of data. Both primary and secon dary\nproducers may use memory or a database to store the data and may spe cify retention\nperiods. Memory producers give the best performance for c ontinuous queries\, whereas\ndatabase producers give the best performance where joins are required.\n\nIt is not necessary for users to know where o ther producers and consumers are: this\nis managed by the local producer a nd consumer services on behalf of the user. In\nmost cases it is not even necessary to know the location of the local producer and\nconsumer servic es\, as worker nodes and user interface nodes are already configured to\np oint to their local R-GMA producer and consumer services.\n\nThere are alr eady a number of applications using R-GMA. The first example is job\nmoni toring. There was a requirement to allow grid users to monitor the progre ss of\ntheir jobs and for VO administrators to get an overview of what was happening on the\ngrid. The problems were that the location in which a g rid job would end up was not\nknown in advance\, and that worker nodes wer e behind firewalls so they were not\naccessible remotely.\n\nSA1 has adopt ed the job wrapper approach\, as this did not require any changes to the\n application code. Every job is put in a wrapper that periodically publish es\ninformation about the state of the process running the job and its env ironment. \nThese data are currently being published via the SA1 JobMonito ring table within\nR-GMA. A second application has been written to run on the resource broker nodes. \nThis application examines the logging and bo okkeeping logs and publishes data about\nthe changes in state of grid jobs . These data are made available via the SA1\nJobStatusRaw table.\n\nBoth the producer in the job wrapper and the producers on the resource broker n odes\nmake use of R-GMA memory primary producers. A database secondary pr oducer is used to\naggregate the data.\n\nOther uses of R-GMA include appl ication monitoring\, network monitoring and gridFTP\nmonitoring. There ar e a number of different ways to implement application monitoring\nincludin g the wrapper approach\, as the job monitoring\, and instrumentation of th e\napplication code. Instrumentation of the code can mean using a logging service\, e.g.\nlog4j\, which publishes data via R-GMA\, or calling R-GMA API methods directly from the\napplication code.\n\nThe network monitorin g group\, NA4\, have been using R-GMA to publish a number of\nnetwork metr ics. They used memory primary producers in the network sensors to\npublis h the data and a database secondary producer to aggregate the data.\n\nSA1 have made use of the consumer service for monitoring grid FTP metrics. T hey have\nwritten a memory primary producer that sits on the gridFTP serve r nodes and publishes\nstatistics about the file transfers. A continuous consumer is used to pull in all\nthe data to a central location\, from whe re it is written to an Oracle database for\nanalysis. This was used for S ervice Challenge 3.\n\nTwo patterns have emerged from the use made of R-GM A for monitoring. In both\npatterns data is initially published using mem ory primary producers. These may be\nshort lived and only make the data a vailable for a limited time\, e.g. the lifetime of\na grid job. In one pa ttern data are made persistent by using a consumer to populate\nan externa l database which applications query directly. In the other pattern\, an\n R-GMA secondary producer is used to make the data persistent and also make it\navailable for querying through R-GMA.\n\nIn the coming months we plan to add support for multiple Virtual Data Bases\,\nauthorization within th e context of a Virtual Data Base using VOMS attributes\,\nregistry replica tion\, load balancing over multiple R-GMA servers and support for Oracle. \n\nR-GMA is an information and monitoring system that has been specifical ly designed for\nthe grid environment. It can be used by systems\, VOs an d individuals and is already\nin use in production.\n\nhttp://indico.cern. ch/contributionDisplay.py?contribId=71&sessionId=16&confId=286 LOCATION:CERN 40-4-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=71&sessionId=16 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Grid computation for Lattice QCD DTSTART;VALUE=DATE-TIME:20060301T131500Z DTEND;VALUE=DATE-TIME:20060301T133000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-70@cern.ch DESCRIPTION:Speakers: Dr. ANDRONICO\, Giuseppe (INFN SEZIONE DI CATANIA)\n This is the first use of the GRID structure to an\n expensive QCD lattice calculation performed under the VO theophys.\n It concerns the study on the lattice of the SU(3) Yang-Mills\n topological charge distribution\, w hich is one of the most important non\n pertubative features of the theor y. The first moment of the\n distribution is the topological susceptibili ty\, which enters\n in the famous Witten Veneziano formula (See Luigi Del Debbio\,\n Leonardo Giusti\, Claudio Pica Phys.Rev.Lett.94:032003\,2005 and\n references therein). The codes adopted in this project\, are\n opt imized to run with high efficiency on a single pc using\n the SSE2 featur e of Intel and AMD processors to implement the \nperformances.\n (L. Gius ti\, C. Hoelbling\, M. Luscher\, H. \nWittig\,Comput.Phys.Commun.153:31-51 \,2003)\n Different codes based on parallel structure are already being \n developed and tested. They need a band interconnection among nodes\n greater than 250 MBytes/s and we hope they can be sent to the GRID in\n the future. The first physical results of the project are planned to be\ n presented at Lattice2006 international symposium at the end\n of Jul y in Tucson by the collaboration (L. Del Debbio (Edinburgh)\, L.\n Giust i (Cern)\, S. Petrarca (univ. of Roma 1)\, B. Taglienti (INFN\, Sez.\n o f Roma1).\n The production on a "small" SU(3) lattice(12^4) at beta=6.0 is finished.\n The results are very encouraging.\n We started a new ru n on a 14^4 lattice whith the same physical\n volume. Although the stati stics is yet unsufficient\, the signal is\n confirmed.\n\n The total CP U time used from the beginning of the work (20-10-2005) up\n to now (26-0 1-2006) under the VO theophys turns out to be 70000 hours.\n Total numbe r of job submitted is about 6500.\n Failures (approximately):\n 500 du e to non-sse2 CPU.\n 1000 job aborted due to unknown reasons.\n\n A typ ical 12^4 job requires 220 MB of ram\; all the production has been\n divi ded in\n small chunks requiring approximately 12 hours of CPU. (Longer jo bs are\n prone to be aborted\n by the GRID system). Every job reads and writes 5.7MB from/to a storage\n element.\n\n The resouces needed by the typical 14^4 job are nearly a factor of 2 for\n CPU\, ram and storage.\n We organized the production in 120 simultaneous jobs\, and each job \nru ns on a\n single processor.\n The job time length is chosen as a compro mise between the\n job time limit actually imposed by the GRID system and the bookkeeping\n activity needed to acquire the result and start a new job.\n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=70&session Id=12&confId=286 LOCATION:CERN 40-4-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=70&sessionId=12 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:In silico docking on EGEE infrastructure: the case of WISDOM DTSTART;VALUE=DATE-TIME:20060301T154500Z DTEND;VALUE=DATE-TIME:20060301T160000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-79@cern.ch DESCRIPTION:Speakers: Mr. JACQ\, Nicolas (CNRS/IN2P3)\nAdvance in combinat orial chemistry has paved the way for synthesizing large numbers \nof dive rse chemical compounds. Thus there are millions of chemical compounds \nav ailable in the laboratories\, but it is nearly impossible and very expensi ve to \nscreen such a high number of compounds in the experimental laborat ories by high \nthroughput screening (HTS). Besides the high costs\, the h it rate in HTS is quite \nlow\, about 10 to 100 per 100\,000 compounds whe n screened on targets such as \nenzymes. An alternative is high throughput virtual screening by molecular docking\, \na technique which can screen m illions of compounds rapidly\, reliably and cost \neffectively. Screening millions of chemical compounds in silico is a complex \nprocess. Screening each compound\, depending on structural complexity\, can take from \na fe w minutes to hours on a standard PC\, which means screening all compounds in a \nsingle database can take years. Computation time can be reduced ver y significantly \nwith a large grid gathering thousands of computers.\nWIS DOM (World-wide In Silico Docking On Malaria) is an European initiative to \nenable the in silico drug discovery pipeline on a grid infrastructure. Initiated \nand implemented by Fraunhofer Institute for Algorithms and Sci entific Computing \n(SCAI) in Germany and the Corpuscular Physics Laborato ry (CNRS/IN2P3) of Clermont-\nFerrand in France\, WISDOM has deployed a la rge scale docking experiment on the EGEE \ninfrastructure. Three goals mot ivated this first experiment. The biological goal \nwas to propose new inh ibitors for a family of proteins produced by Plasmodium \nfalciparum. The biomedical informatics goal was the deployment of in silico virtual \ndock ing on a grid infrastructure. The grid goal is the deployment of a CPU \nc onsuming application generating large data flows to test the grid operatio n and \nservices. Relevant information can be found on http://wisdom.eu-eg ee.fr and \nhttp://public.eu-egee.org/files/battles-malaria-grid-wisdom.pd f.\n\nWith the help of the grid\, large scale in silico experimentation is possible. Large \nresources are needed in order to test in a transparent way a family of targets\, a \nlarge enough amount of possible drug candida tes and different virtual screening \ntools with different parameter / sco ring settings. The grid added value lies not \nonly in the computing resou rces made available\, but also already in the permanent \nstorage of the d ata with a transparent and secure access. Reliable Workload Manager \nSyst em\, Information Service and Data Management Services are absolutely neces sary \nfor a large scale process. Accounting\, security and license manage ment services are \nalso essential to impact the pharmaceutical community. In a close future\, we expect \nimproved data management middleware servi ces to allow automatic update of compound \ndatabase and the design of a g rid knowledge space where biologists can analyze \noutput data. \nFinally key issues to promote the grid in the pharmaceutical community include cos t \nand time reduction in a drug discovery development\, security and data protection\, \nfault tolerant and robust services and infrastructure\, an d transparent and easy use \nof the interfaces.\n\nThe first biomedical da ta challenge ran on the EGEE grid production service from 11 \nJuly 2005 u ntil 19 August 2005. The challenge saw over 46 million docked ligands\, \n the equivalent of 80 years on a single PC\, in about 6 weeks. Usually in s ilico \ndocking is carried out on classical computer clusters resulting in around 100\,000 \ndocked ligands. This type of scientific challenge would not be possible without the \ngrid infrastructure - 1700 computers were s imultaneously used in 15 countries \naround the world. The WISDOM data cha llenge demonstrated how grid computing can \nhelp drug discovery research by speeding up the whole process and reduce the cost \nto develop new drug s to treat diseases such as malaria. The sheer amount of data \ngenerated indicates the potential benefits of grid computing for drug discovery and \nindeed\, other life science applications. Commercial software with a ser ver license \nwas successfully deployed on more than 1000 machines in the same time. \nFirst docking results show that 10% of the compounds of the d atabase studied may be \nhits. Top scoring compounds possess basic chemica l groups like thiourea\, guanidino\, \namino-acrolein core structure. Iden tified compounds are non peptidic and low \nmolecular weight compounds.\nF uture plans for the WISDOM initiative is first to process the hits again w ith \nmolecular dynamics simulations. A WISDOM demonstration will be conce ived at the aim \nto show the submission of docking jobs on the grid at a large scale. A second data \nchallenge planned for the fall of 2006 is als o under preparation to improve the \nquality of service and the quality of usage of the data challenge process on gLite.\n\nhttp://indico.cern.ch/co ntributionDisplay.py?contribId=79&sessionId=9&confId=286 LOCATION:CERN 40-SS-C01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=79&sessionId=9& confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Methodology for Virtual Organization Design and Management DTSTART;VALUE=DATE-TIME:20060302T164500Z DTEND;VALUE=DATE-TIME:20060302T170000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-78@cern.ch DESCRIPTION:Speakers: Mr. SKITAL\, Lukasz (ACC Cyfronet AGH / University o f Science and Technology)\nIntroduction\n\nContemporary grid environment a chieved high level of maturity. With still\nincreasing number of various a vailable resources\, their optimal exploitation\nbecomes a significant pro blem. One of solutions to the problem are Virtual\nOrganizations (VO)\, wh ich groups users and resources to solve a particular\nproblem or a set of problems. Each problem has its own specific requirements in\nname of compu tational power\, network bandwidth\, storage capacity\, resource\navailabi lity etc. During VO design process\, appropriate resources have to be\nsel ected from all available. This task can be vary difficult or time consumin g\,\nif done manually.\n\nCurrent EGEE middleware (lcg 2.6 or glite 1.4.1) with VOMS or VOMRS systems\naddress the problem of users management in ex isting VOs\, offering web based\ninterfaces for user registration and memb ership administration. However\,\ncreation of new VO is a heavy weight ta sk\, which is not automated. Existing EGEE\nprocedures covers very well al l administrative aspects\, but in current form\nthey are not feasible for automation of the VO creation task. There is no tool\,\nwhich support desi gn of new VO in EGEE environment.\n\nIn the presentation we propose a meth odology of VO design. This methodology can\nbe used to build a knowledge b ased system\, which would support the process of\nVO creation by automatin g tasks\, which do not need user interaction and support\nuser\, when the interaction is necessary. The methodology is general and can be\nadapted t o EGEE grid environment. The knowledge based system can be used to\nsuppor t design of new VO without changing existing EGEE procedures.\n\nMethodolo gy\n\nWe propose the way of VO design which consists of three steps: defin ition of\nthe VO\, creation of abstract VO\, creation of solid VO.\n\nThe first step of VO design is definition of the VO purpose with all\nrequirem ents and constraints. This step has to be performed by an expert who\nknow s the problem for which the VO is created. The definition of VO should be\ nwritten in a form\, which can be easily processed by machine\, therefore we\npropose to use ontology for this task. The expert from the VO domain\, does not\nhave to be familiar with any ontology language. There is a need for a tool\nwhich will allow VO definition by fulfilling forms and questi ons. This tool\ncan support the expert in the task\, by providing hints an d possible answers to\nquestions.\n\nThe next step is creation of abstract VO. Abstract VO consists of resource\ntypes and their amount which is nee ded to fulfill VO requirements. Abstract VO\nis derived from VO definition (and available resources). Abstract VO has exact\ninformation about requi red computational resources\, storage resources and all\nother specific re sources\, like data sources (e.g. physical experiment)\, but\ndoes not aim to any specific instance of resource (site). However\, the expert\ncan st ate\, that a specific site is required in VO\, and this requirement will b e\nfulfilled in the next step - creation of solid VO. For each resource ty pe\,\nthere are functional and not functional requirements. The functional \nrequirements are for example installed specific software on computationa l\nresources. Non functional requirements can be availability of resource or cost\nof usage.\n\nThe last step of VO design is creation of solid VO. During this step abstract\nresources are exchanged by real instances. This task can be performed\nautomatically. Resources selection is based on spe cified requirements and\nknowledge about the grid environment. The knowled ge consists of many kinds of\nfacts and information about each resource\, like computational power\, storage\ncapacity\, bandwidth (network\, storag e)\, statistics about resource availability\,\netc. Because of a dynamic n ature of the Grid\, available resources can change in\ntime. To support VO requirements\, unavailable resources should be replaced with\nnew ones du ring the VO lifetime. Therefore the last step of VO design should be\nrepe ated any time when needed.\n\nDuring the first step of design\, apart form getting the information on needed\nresources\, a workflow\, which defines the problem would be created. The workflow\nvisualizes a process of VO us age\, from data gathering\, through each necessary\nstep\, like preprocess ing\, computations\, postprocessing and visualisation. Using\nthe workflow \, one can easily generate a specific job description (can take\nadvantage of DAG jobs) to solve the problem. This step can be done\nautomatically.\ n\nSummary\n\nOptimal resource utilization is a very important task for co ntemporary grid\nenvironments. With grid environments growth in size and c omplexity\, this task\nbecomes more and more complicated. We proposed the methodology\, which can\npositively influence the process of optimal resou rce utilization by supporting\ndesign of a VO. Well designed VO hides siz e and complexity of the grid\nenvironments\, reveling only parts\, which a re important for the specific problem\n(for which VO was created). Selecti on of appropriate resources for VO is time\nconsuming task\, therefore it' s automation can significantly improve process of\nVO establishment.\n\nRe ferences\n[1] EGEE Home page \n[2] EGEE NA4 Home page \n[3] InteliGrid \n[ 4] KWf-Grid \n\nhttp://indico.cern.ch/contributionDisplay.py?contribId=78& sessionId=17&confId=286 LOCATION:CERN 40-S2-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=78&sessionId=17 &confId=286 END:VEVENT BEGIN:VEVENT SUMMARY:Genetic Stellarator Optimisation in Grid DTSTART;VALUE=DATE-TIME:20060301T153000Z DTEND;VALUE=DATE-TIME:20060301T160000Z DTSTAMP;VALUE=DATE-TIME:20130519T162613Z UID:indico-contribution-286-47@cern.ch DESCRIPTION:Speakers: Mr. VOZNESENSKY\, Vladimir (Nuclear Fusion Inst.\, R RC "Kurchatov Inst.")\nComputational optimisations can be found in a wide area of natural\, engineering and \neconomical sciences. They may be ca rried out by different methods\, that include \nclassical gradient-base d\, genetic algorithms\, etc. \n \nStellarator facilities optimisati on may be noted as an example of such task. \nStellarators are the toro idal devices for magnetic confinement of plasma. In \ncontrast to tokam ak (ITER facility\, for example)\, no toroidal current is required \nhe re\, so that stellarators are principally stationary devices. As a payment for \nstationary working\, stellarators are principally three-dimensio nal (non \naxisymmetric) configurations. This can lead to enhanced losses of fast particles - \nto an enhancement of losses of fast particles - th e product of fusion reaction- and \nplasma. \n \nThe plasma equili brium in stellarator can be found if the shape of the \nboundary plasma surface and the radial profiles of plasma pressure and toroidal \ncurr ent are prescribed. During the last decades it was shown that the properti es of \nthe stellarators can be significantly improved by appropriate cho ice of the shape \nof the boundary magnetic surface. Because of the large variety of stellarators the \noptimisation is still under way. \n \nBoundary surface may be characterised by a set of Fourier harmonics th at give the \nshape of the surface\, the magnetic field\, and the electri c current. The Fourier \ncoefficients compose a multidimensional space of optimisation (free) parameters and \ntheir number may exceed a hundr ed. \n \nThe quality parameters are functions depending on optimisat ion parameters and \ndescribing the properties of the considered config uration. As soon as the \nstellarator plasma equilibrium is found\, qua lity parameters such as stability of \ndifferent modes\, fast particle long time collision-less confinement\, neoclassical \ntransport coeffic ients\, bootstrap current\, etc. can be computed. \n \nIn the optimi sation task\, the measure of optimum\, so called a target function\, is \ nbased on quality parameters and may be\, for example\, a weighted sum of such \nparameters. Computation of a stellarator quality parameters set an d target function \nvalues for a given optimisation parameters vector tak es about 20 minutes on \nconventional PC. \n \nSuch computation may form a single grid job. The technique presented in this work \nmay be useful for tasks having target function calculation large enough for a job . \n \nSplitting each gradient-based optimisation step into several independent grid jobs \nmay be ineffective in case of numerical gradien t computation due to hardly \nasynchronous jobs completion. \n \nF or such reason\, genetic algorithms have been chosen as optimisation metho ds. Such \nmethod treats parameter vector of a variant as a "genome" an d imply three \nactivities in each iteration. The activities are select ion of "parents"\, their \nbreeding and computation of target function values for each "child" genome. \n \nInitial pool of genomes can be generated randomly inside the optimisation \nparameters variation domai n defined by a user. Genetic method iterations enrich \ngenome pool wit h new better genomes. \n \nGenetic algorithms behave well for grid co mputations\, because genome pool may \nbe appended by grid jobs results sporadically\, so aborting or delaying several jobs \ncompletion would not affect the overall optimisation process hardly. \n \nDuring the selection\, genome with better target function value should have a \np reference among genomes pool. The following algorithm has been used for ch oosing \n"mothers" and "fathers" of a new stellarator generation. \n \nGenomes pool is arranged according to target function values\, so th e better genomes \ngo first. Then\, iterations over the pool are carried out until a "father" is \nchosen. On every iteration\, a uniform random n umber is generated\, so current genome \nis chosen with some user-predefi ned probability\, say 2% or 3%. A "mother" is chosen \nin the same manner . \n \nSuch selection algorithm have no direct influence from target function derivatives\, \nso it suppresses fast appearing of "super gen ome" (i.e. "inbreeding") that may \nconstrain other potentially fruitfu l genomes. \n \nGenetic algorithm breeding in case of continual opti misation domain should not \nchange statistical mean and dispersion of genome pool\, because there is no reason \nto shift\, disperse or colle ct optimisation space points in the breeding activity. \nOnly selection activity should put such changes. The following method preserving \nsu ch statistical parameters have been used for stellarators. \n \nTwo coefficients f and m for each Fourier harmonic from every parent vectors p air \nwere bred separately. Every new coefficient was a random number o f Gaussian \ndistribution. The distribution had the mean (f+m)/2 and th e standard deviation | \nf-m|/2. \n \nA set of scripts realising the technique in Python language have been developed. \nOne of them genera tes an initial genome pool\, another one spawns new jobs for \nquality pa rameters computation\, the third gathers already computed results from the \ngrid and the fourth generates new part of genome pool depending on the existing \none. The number of concurrently spawned jobs is kept below a given threshold. New\, \nrunning and complete jobs' genomes and quality p arameters are stored in files of \nspecial directory hierarchy. \n \nThe iteration is realised by a Bash script. The script implies spawning\ , gathering\, \ngenetic generation scripts and scheduling a new iterati on using "at" command. The \nscripts are intended to run controlled by user commands on LCG-2 user interface \nhost. \n \nA test example of stellarator optimisation task have been computed. About 7.500 \nvar iant jobs have been spawn\, about 1.500 of them were discarded since no \ nequilibria were found. In other 6.000\, a set of quality parameters based on the \nfields and target function values were computed. \n \nHis tograms representing distribution of target function values in first\, sec ond\, \nthird\, fourth\, fifth and sixth thousands of results in order of appearance show \nthat the sets of best values converge to the belie ved optimum value with the linear \norder. \n \nThis technique can be employed fruitfully in developing new stellarator concepts \nwith differ ent optimization criteria. Moreover\, the proposed technique based on \ng enetic algorithms and grid computing that works for the stellarator optimi sation \ntask can be employed in a wide spectrum of applications\, both s cientific and \npractical. \n \nREFERENCES \n1. ESA Genetic Algo rithms Tutorial by Robin Biesbroek\, \nhttp://www.estec.esa.nl/outreach /gatutor/Default.htm \n2. M.I.Mikhailov\, V.D.Shafranov\, A.A.Subbotin\ , et.al. Improved alpha-particle \nconfinement in stellarators with pol oidally closed contours of the magnetic field \nstrength. // Nuclear Fu sion 42 (2002) L23-L26\n\nhttp://indico.cern.ch/contributionDisplay.py?con tribId=47&sessionId=10&confId=286 LOCATION:CERN 40-5-A01 URL:http://indico.cern.ch/contributionDisplay.py?contribId=47&sessionId=10 &confId=286 END:VEVENT END:VCALENDAR