Transcript ReportfromHEPCCC

Report from HEPCCC
Tobias Haas
XIII HTASC
13 March, 2003
HEPCCC Agenda
(18 October 2003 at CERN)
Ian Bird: Deployment Aspects of LCG
Laura Perini: Report from FOCUS 
Marcel Kunze: Definition of Tier 0/1/2 centers
Jacques Delabrouilles: Future computing needs of nonaccelerator-based experiments 
Fabricio Gagliardi: Status of EDG
Larry Price: Coordinating new Grid proposals
Harvey Newman: Status and Outlook for future networks 
Denis Linglin: The Lyon Biology Grid project 
iHEPCCC Developments 
Report from FOCUS
The “new” mandate
The issues dealt with in 2002
Perspectives for future
A new mandate for FOCUS
(Forum On Computing: Users and Services)
• Last revised 1st November 2001 Paul Jeffreys, Marco Cattaneo
• Background:
– FOCUS’s mandate is changed following the formation of the LHC
Computing Grid Project Structure.
– Working assumptions made to determine the revised mandate:
– FOCUS’s main role is to look at the implementation, defining,
running, and ultimately phasing out of services.
– As previously, it is primarily concerned with IT services run on the
CERN site.
– COCOTIME maintains control over resources.
– HEPCCC retains responsibility for providing ‘a forum in which the
Directors responsible for Computing at the major European
Institutes … are able to discuss the organisation, co-ordination and
optimisation of computing in terms both of money and personnel’.
The Terms of Reference
•
•
•
•
•
•
FOCUS will normally meet four times a year as a forum for bringing
together CERN IT providers and users to define and oversee:- the
commissioning, operation, prioritisation and decommissioning of
services; the services concerned are primarily those on the CERN
site;
it facilitates the agreement of clear definitions of service requirement
and provision, and monitors quality of delivery;
FOCUS concentrates on generic IT activities which have wider
relevance than the LHC experiments alone, relate to non-LHC
experiments, or disseminate developments from the LHC
experiments to other areas;
FOCUS reports to the Research Sector Management, and in
particular to the Director for Technology Transfer and Scientific
Computing;
FOCUS plans and operates across a medium range timescale,
typically two years;
its mandate will be reconsidered at the end of 2002
Activity in 2002
• Issues considered
– Decisions
• Preparation for them
• Proposals and discussions
– Information exchange
• Reports on ongoing IT activities
• Updates on status and needs of running experiments
– Matters arising etc.
• Way of working
– Draft Agendas prepared at beginning of the year, modify according to
the suggestions from IT and users
• Users somewhat too quiet…
– Review of membership in progress
March Agenda (1)
• 14:10
FOCUS matters
– Welcome of new Chairperson and secretary (H.Hoffmann)
Chairperson’s remarks (L.Perini)
Review of membership
(H.Hoffmann)
Agendas for 2002 (J.Boucrot)
• 14:40
5'
5’
10'
10’
COCOTIME matters
– Budget situation (W.von Rüden)
Allocations for 2002 (H.Meinhard)
10’
15’
• 15:10
New plan for end of RISC services T.Smith 10’
• 15:30 Tape services issues (TMS, Redwoods, high speed
tape drives) (H.Renshall) 10'
Discussion foreseen for each bullet in every Agenda
March Agenda (2)
• 16:10
LEP long-term data storage and access
– Experiments’ requirements (M.Maggi/Aleph) 10'
Possible solutions (H.Renshall)
• 16:40
Linux Service Review (see action 22/4)
– Experiments’ feedback (Fons Rademakers)
IT Division plans (B.Panzer-Steindel)
• 17:20
15’
15'
Updates on ongoing IT activities
– Security report (see action 21/5.1) (D.Heagerty)
Plans for Objectivity/DB (J.Shiers)
• 17:40
10’
Actions outstanding
10’
10’
June Agenda (1)
• 14:15 Reports from running experiments – plans
for 2002 data-taking
– COMPASS (B. Gobbo)
– NA 48 (C. Biino)
– NA 49 (A. Sandoval)
10’
10’
10’
• 15:00 Windows 2000 update
– Presentation (F. Hemmer)
10’
• 15:20 Plans for external access beyond ACB (VPN
etc.)
– Presentation (F. Hemmer, D. Heagerty)
10'
June Agenda (2)
• 16:00 Software Development Support and Application
software
– Development infrastructure (CVS, compilers, tools) ( A. Pfeiffer) 10’
– Libraries and toolkits: Aida, Anaphe (A. Pfeiffer)
15’
– Simulation (GEANT 4) (J. Apostolakis)
15’
• 17:00 Updates on ongoing IT activities
–
–
–
–
Update on Objectivity (J. Shiers)
Linux 7.2 (J. Iven)
CASTOR charging algorithm (H. Renshall)
Legacy UNIX (W. Von Rueden)
• 17:45 Actions outstanding
5’
10’
10’
5’
September Agenda (1)
• 14:15
Update on ongoing IT activities (W. Von
Rueden) 40’
• 15:15 Data Import/Export via Network (H. Renshall) 20’
• 16:10 Migration of COMPASS/HARP out of Objectivity
(J. Shiers) 15’
• 16:25 Reports from running experiments – experience
from 2002 data-taking
– NA 48 (F. Marchetto)
HARP (A. Grant)
10'
10'
• 16:55 Computing plans of the EP division (I.Videau) 5’
Snapshot on specific issues
• Linux
(slides from Iven)
• Objectivity (slides from Shiers)
• Mass Storage (slides from Renshall)
• Discontinuation of services (Smith, Von Rueden…)
• Security (slides from various presentations)
Just some significant examples extracted from
FOCUS presentations, many points as interesting
as these ones are left out
LINUX Timeline Iven’s June Slides
" last FOCUS presentation: 28.03.02; estimated date
for certification: 29.04.02
" “Blocking” products that were late:
"
"
"
"
CERNLIB: 30.04.02
ANAPHE: 02.05.02
OpenAFS: 13.05.02
ASIS-RPM: 13.05.02
" CERN RedHat Linux 7.2.1 certified on
13.05.02
After the certification
• Post-mortem discussion on 24.05.02:
– General certification issues
• too late vs. too often
• compiler decisions etc..
– Suggestions:
• more formal approach, steering body for Linux
certifications (neither CLUG nor FOCUS)
• clearly defined environments, explicit dependencies,
“environment responsibles”
• Standardize on tools like RPM
Linux update (1) Von Ruden September slides..
• CLUG held on September 13th:
– Recommendation: certify 7.3 until November, leave Red Hat 8.0 alone,
look at 8.1 later
– Discussing CLUG future
• Form a “certification team”
– Advice Linux team on technical choices, define priorities for releases
and help organising the certification process
– Invitation to user communities sent out early September to nominate a
member empowered to speak on their behalf
– Feedback positive, first names received
– Kick-off meeting proposed for 1st half of October
Linux update (2)
• Version 6.1.1:
– Currently still running on ~2200 machines
– Main reason: Objectivity (and inertia, still officially
supported...)
• CMS: no Objectivity needed for production in 3Q03
• HARP, COMPASS: plan to move off Objectivity
in 1Q03
– Red Hat 6.x will become unsupported by RedHat towards end
of year (security problems)
– We propose to freeze 6.1.1. now, except for security updates
and to stop it in May 2003 (some “pockets” with good justification
may go on a bit longer).
Linux update (3)
• Version 7.2.1:
• certified in May, currently ~1000 machines
• Only a few large-scale migrations so far (despite pressure during
certification):
• LXPLUS migrating to 7.x within 2 months (will be delayed by 7.3.1
certification)
• LXBATCH migrating within 6 months (pending Objectivity and experiments
needs)
• LHCb, CMS: code not yet fully tested, may delay until after 7.3.1 certification
• ALICE: 6.1.1 code runs on 7.2
• ATLAS: waiting for next code release (6 weeks) , but no problems expected
• COMPASS: code runs on 7.2, partly migrated desktops, but need Objectivity
for data...
–7.2.1 is default version for Desktop Machines
OBjY Shiers’ June slides
• LHC Experiments:
– LCG PF (POOL) underway; first release September
• Non-LHC:
– Concerns primarily HARP & COMPASS
• Also CHORUS… but manpower questions… on both sides…
– Detailed technical documents being prepared
• LCG PF timescale incompatible with needs of the above
• Nevertheless, strong motivation to stay as closely aligned as
possible
• These plans are still under discussion…
POOL Timetable
• September 2002: first prototype hybrid data store capable of providing
event data persistency in a production setting, and supporting also nonevent data persistency. This will be a release for deployment and testing by
developers and experts
• Mid-2003: more functional and robust version of the persistency
framework. Properly documented and packaged for general use by the
experiments
• Early 2005: Completion of the fully functional persistency framework
HARP
• 2002 is last year of data taking: total ~30TB
– Simple access patterns; mainly raw data
– Persistent<->Transient converters implemented (DATE)
• Need for conditions DB
– Propose Oracle implementation vs current Objectivity/DB version: same
(abstract) interface
• Expressed requirement for DB solution
– Navigation, transactions, … + metadata
• Propose conversion of Objy data to Oracle 9i R2
– 9iR1 bugs fixed; significant performance improvements
– HARP / NOMAD data models demonstrated with 9i
– Running on standard Intel / Linux systems
• IT-DB contact: Andrea Valassi (+Dirk Geppert)
COMPASS
• Data taking now – 2004 (and beyond??)
– LHC-style volumes & data rates
• Few persistent classes: <10
• Propose hand-coded converters
– As for HARP, but streaming to files in DATE format
– No need for – or advantage from – more general solution
– DB layer for meta-data + event lookup
• Conditions DB as for HARP
– i.e. Oracle implementation of agreed abstract interfaces
• IT-DB contact: Marcin Nowak
COMPASS (September)
• COMPASS will have collected over 300TB of data by end of
2002 run
– Approximately ½ the size of BaBar database
• This has to be migrated
 From old tape media to new
 From legacy ODBMS format to new
• 300TB @ 10MB / s = 365 days
• Such major migrations are likely to reoccur in the future
– At very least from one medium to another
COMPASS / HARP / LCG
• High-level – many similarities:
– Hybrid solutions combining Database layer with object streaming
– Metadata applications e.g. conditions DB
– Actual storage mechanism transparent to applications and may well
change with time!
• LCG: converters (will be) generic
– COMPASS / HARP already have hand-written converters from
DATE format
• HARP: streamed objects in DB
• COMPASS: streamed objects in files
Objy - Reminder
• Licenses are perpetual
• Use only on officially supported platforms
http://wwwinfo.cern.ch/db/objectivity/servicestools/versionsplatforms.html
TMS (1 of 2) March Renshall’s Slides
•
Managed storage implies end users no longer own or manipulate tapes
(though we are in a transition phase as regards efficient co-location)
•
CASTOR includes its own volume manager already containing much of
the functionality of TMS.
•
The CERN Tape Management System will not be used by the LHC
experiments
•
TMS (and its companion SYSREQ server) run on three very old SUN
servers. It would be a non-negligible cost (hardware and software) to
migrate them.
•
We propose to shut down TMS at the end of 2002 providing
restricted functionality alternatives for experiments still using it.
TMS (2 of 2)
•
To stop TMS we believe we need to enhance support in CASTOR for :
–
–
–
–
tape location in libraries. Only library names
supported and query is privileged.
write-locking volumes. Currently a privileged operation.
tag (comment) field per volume. Needs to be added.
•
CASTOR command line interfaces to the above exist but we could
simulate ‘sysreq tms …’ calls if really required. Which experiments
would need this ? Largest non-CASTOR user is probably NA48. Already
using CASTOR for reconstruction and analysis - could they switch for
raw data this year ?
•
NA49 Sony tapes would be entered into the CASTOR volume manager.
•
We would keep a frozen flat file extract of the final TMS database
•
After 2002 Opal will be the only production user of FATMEN and will
provide the effort (via S.Oneale) to make it TMS independent
Redwoods (2 of 2)
•
We propose to stop all Redwood usage by end 2002 with a
contingency up to end April 2003.
•
We propose to copy remaining NA48 Redwoods to the new higher
density STK drive when available (we would have to borrow drives from
LCG until we get our own). We have 150 KCHF for this - about 50
KCHF short so will recuperate later (by CASTOR repack).
•
We propose to reduce to 4 maintained drives from now and reactivate 4
drives to help in the NA48 Redwood copying.
•
We will prepare a costed plan to upgrade existing drives to the higher
density model including reusing existing media at higher density
through the planned CASTOR repack functionality.
•
We propose to block access to Redwoods already copied to CASTOR
when experiments agree but as soon as possible.
Proposal for charging algorithm (1 of 2)
•
At the November Focus we proposed to charge for tape usage:
– Proposal for charging algorithm in 2002
– Take into account:
• Amount of data on tape
– Only non-deleted data is billed
– Drive compression factor is taken into account
• Tape I/O activity: number of Gbytes transferred to and from tape
• Tape device time (to favor fast or lightly loaded disk servers)
•
•
•
Gigabyte cost in 2002: 2 CHF uncompressed (i.e. on disk occupancy)
We want to modify this to rather charge for the number of mounts and the
number of Gbytes transferred where the normalisation is that a mount/demount
cycle has the same cost as transferring 1GB since both take about 2 minutes of
real time.
We suggest (this is a political decision) to set the costs to recuperate the media
cost of user tapes data - about 60 KCHF/year (currently single copy only). In
practise this is spread among about 15 experiments to pay from 1 to 5
KCHF/year.
CHARGING PROPOSAL DROPPED AFTER FOCUS
DISCUSSION
Accelerated Schedule for RISC
decommissioning (T.Smith in March)
•
AIX
– HPSS
– Fatmen/HEPDB
•
shiftDELPHI
shiftALEPH
shiftNOMAD
DXPLUS
shiftSLAP
18
1
14
2002/07/24
2002/07/24
2
2002/06/30 - 2002/12/31
5
2002/07/24 - 2002/08/31
2002/12/31
HP
– HPPLUS
•
2002/04/30
2002/04/30
DUX
–
–
–
–
–
•
3
1
3
2002/07/24 - 2002/08/31
SGI
– shiftOPAL
– shiftL3
– shiftDELPHI
2
1
2002/07/24
1
2002/07/24 - 2002/12/31
2002/07/24
Year/Week
20
00
0
20 1
00
0
20 6
00
1
20 1
00
1
20 6
00
2
20 1
00
2
20 6
00
3
20 1
00
3
20 6
00
4
20 1
00
4
20 6
00
5
20 1
01
0
20 4
01
0
20 9
01
1
20 4
01
1
20 9
01
2
20 4
01
2
20 9
01
3
20 4
01
3
20 9
01
4
20 4
01
4
20 9
02
0
20 2
02
0
20 7
02
1
20 2
02
1
20 7
02
2
20 2
02
2
20 7
02
3
20 2
02
3
20 7
02
4
20 2
02
4
20 7
02
5
20 2
03
05
2003
2002
2001
2000
#CPUs
RISC Reduction (Von Rueden in September)
600
500
400
300
W/NT
AIX
IRIX
HP-UX
DUX
Solaris
200
100
0
Security (Von Rueden in September)
•
Closure of off-site telnet access to CERN
– Proposed date for closure is before Easter 2003
– Date needs to be coordinated with user communities
•
Closure of off-site ftp access to CERN
– When non clear-text replacement services are available
•
Passwords and sensitive data encrypted
– As soon as feasible for the application services
•
Registration of systems requiring off-site applications on
high numbered ports
– Initially ssh, others added as tools improve
•
Additional security checks for systems requesting access in
the firewall
– Initially web servers, others as tools improve
VPN (Hemmer in June)
• “Virtual Private Network”
• Is a technology that can be used to access any resource that
has been restricted to the CERN Intranet when you are using
a computer outside CERN
Using an ISP
Using an ISP thru a VPN
Pilot VPN Proposal
• Establish a VPN pilot service
– Based on same technology than ACB
– Restricted to managed computers on CERN Linux machines and
NICE 2000
• Requirements
– A NICE username with a secure password
– An explicit registration
• Pilot success criteria's
– User needs satisfied
– Scalability
– Reasonable security checks can be implemented
End of NICE 95/NT (Hemmer in June)
• Freeze NICE 95/NT by end of 2001
– Still installable by floppy
– No new applications, functionality, etc
• Stop (central) support by mid 2002
– No answers from helpdesk
– Solution to problems: upgrade to W2K
– Still installable by floppy
• Ensure servers are running until end of 2002
– NICE 95/NT environment still working
• NICE 95/NT for new PC’s ?
– Unlikely new PC’s will be able to run Windows 95
– We still have a stock of Windows 95 capable PC’s
Desktop Forum: Plan seems acceptable by all divisions except LHC
FOCUS-centric view
HEPCCC
ACCU?
Report upwards
Receive advice
Desktop
Forum
Crosssecretaries
Report to Focus
Cocotime
FOCUS
Swap agenda
items
LCG
EP Forum
FOCUS Future
• The LCG cloud is expanding
• The number of users who interact with Computing
Services via FOCUS only is contracting
• Which mandate for FOCUS in order to be as useful
in LHC/LCG times as it was in the past, and has
been also in 2002?
This last question is the conclusion of my talk…
Future computing needs of nonaccelerator-based experiments
No simple answer..
Jacques DELABROUILLE
PCC- Collège de France
Outline
- Specifics of non-accelerator data
online trigger + eventsvs.
other type of data
- Aspects of "non-event" type data processing
type of data; type of processing; simulations;
storage; handling (I/O); computing power
- Some non-accelerator-based experiments
Edelweiss, EROS, ANTARES, HESS (gamma), Supernovae, CMB, ...
- Observational science
observations vs. experiments; numerical investigation;
virtual observatories; short-timescale projects; merging information
Specifics of non-accelerator data
I - "Event-type" experiments :
• (Accelerators);
• Astroparticle data;
• Neutrinos (Antares, …)
• Direct detection of dark matter (Edelweiss, …)
• Ultra-High Energy Cosmic Rays (Auger, EUSO, …)
• High Energy Gamma rays (HESS, Celeste, …)
• Typically fast acquisition, a lot of storage needed, online
trigger, post-processing of a selection of events (event by event)
• The computing can be
• massively parallelised
• distributed among several computing centers
Specifics of non-accelerator data
II - "Other-type" experiments :
• Cosmic Microwave Background
• Planck, Archeops, Olimpo, …
• TBytes of timeline data, Gbytes of maps on disk
• Supernovae / Lensing
• EROS, SNLS (Megacam), SN Factory, SNAP
• Tbytes of maps on disk
• Gravity wave detectors
• VIRGO, (LIGO, LISA)
• Others …
Data handling/processing aspects
• Continuous (slow) sampling acquisition
• Modest storage (<100 Tbytes), on disk rather than tape (e.g. HPSS)
• Joint processing of possibly large data (up to Tbytes) for some exp.
• A lot of I/O (random accesses in the whole data set)
• Varying CPU depending on the processing needed
• Increasing importance of (heavy) Monte-Carlo processing of
simulated data sets (possibly suited for distributed processing)
Exemple I : Edelweiss
Direct detection of dark matter via interaction of WIMPS in a large
crystal (bolometer) cooled to ~10mK at Modane (present)
"Event-type" experiment
20  100  1000 detectors (5-10 years scale),
~10 Mbytes/day/detector in data acquisition mode
~100 Mbytes/day/detector in calibration mode
Somewhat larger numbers in the test phase (less online compression)
(Overall modest as compared to LHC experiments)
Exemple II : HESS
Observation of fluorescence light due to high energy gamma rays
using 4 telescopes with a 1000-pixel focal plane (phototubes)
(present)
"Event-type" experiment;
About 40 Tbytes of data per year, x2 or x3 in later phases
CPU annual needs ~few 105 hours
Exemple III : ANTARES
Underwater neutrino telescope collecting data in an array of ~1000
phototubes in the mediterranean sea (being built)
"Event-type" experiment
First level trigger produces ~1010
events per yr (100 Tbytes)
Second-level trigger to identify
events well suited to distributed
computing time
CPU annual needs ~few 107 hours
Exemple I : Edelweiss
Direct detection of dark matter via interaction of WIMPS in a large
crystal (bolometer) cooled to ~10mK at Modane (present)
"Event-type" experiment
20  100  1000 detectors (5-10 years scale),
~10 Mbytes/day/detector in data acquisition mode
~100 Mbytes/day/detector in calibration mode
Somewhat larger numbers in the test phase (less online compression)
(Overall modest as compared to LHC experiments)
Exemple II : HESS
Observation of fluorescence light due to high energy gamma rays
using 4 telescopes with a 1000-pixel focal plane (phototubes)
(present)
"Event-type" experiment;
About 40 Tbytes of data per year, x2 or x3 in later phases
CPU annual needs ~few 105 hours
Exemple III : ANTARES
Underwater neutrino telescope collecting data in an array of ~1000
phototubes in the mediterranean sea (being built)
"Event-type" experiment
First level trigger produces ~1010
events per yr (100 Tbytes)
Second-level trigger to identify
events well suited to distributed
computing time
CPU annual needs ~few 107 hours
Exemple IV : EROS
A good exemple of (qualitatively) very different data processing
Monitoring of ~107 star luminosity curves during 6 years (1996-2002)
1300 images of 4x106 pixels per night (10 Gbytes/night), for a total
of 2.5 million images and ~20 TBytes of data in 6 yrs
Very long events ( up to ~6 months or more!)
One very specific aspect : matrix transposition .
The data comes "per day", but is analysed "per star" in the end
Exemple V : Supernovae
Monitoring images of many galaxies to detect supernovae explosions
Three main (complementary) experiments
• SNLS : Supernovae Legacy Survey
• SNF (SNIFS) : The Supernovae "Factory" ("calibration")
• SNAP : satellite dedicated to wide-field photometry
Important (?) aspect : transient phenomena + alert
• Detecting a supernova candidate online triggers more data
taking (spectra) during the few next days
• Requirement on computing power availability
Large fraction of data has to be on disk
SNF/SNIFS - SNLS
SNF : Supernovae Factory (SNIFS) : search for a small number
(~100) nearby supernovae (2002-2007)
Small : 4 Tbytes total, 40,000 hrs of CPU
SNLS : Supernovae Legacy Survey : search for distant supernovae
with Megacam (2002-2007)
Same data used by different groups/institutes for different
purposes (weak shear)
10 Tbytes/yr, ~50 Tbytes total, ~500,000 hrs of CPU
Data processing cut in simple tasks (read-process-write) well suited
for parallel processing
SNAP
SNAP : Supernovae Acceleration Probe (begin 2008-2012?)
1000 Tbytes for three years
10-50 Tbytes disk
100 processors (1 GHz)
Note : particularly large data set for
a space-borne experiment
Exemple VI : CMB experiments
• Observation of spatial brightness/polarisation fluctuations of the
Cosmic Microwave Background emission (no intrinsic time variation!)
• PLANCK (2007-2009), archeops, olimpo, ...
~100 two-year long timelines sampled at ~100 Hz (1TByte)
• Timelines are combined in a joint way to form
~50 sky maps of 10 million pixel each
• A large fraction (>20 Gbytes) of the data must be stored in
(shared) memory, the rest on disk with rapid access (a lot of I/O).
Most typical operations:
•matrix (or filtering) operations M.x on the timelines
•FFTs
The map-making problem
y=Px+n
Data stream
1010 samples
Pointing matrix
1010 x 107 entries
(sparse)
noise stream
1010 samples
map
107 pixels
Current plans
Iterative close-to-optimal processing solutions (map-making) scaling as
•Memory O(n)
•FLOPS O(n log n)
Iterative processing : map-making steps repeated many times
Errors computed by Monte-Carlo : repeat the process many times
Most of processing done on a dedicated machine, except well defined
tasks suited for parallel/vectorial/distributed computing (?)
Observational science ...
OBSERVATIONS
≠
EXPERIMENTS
We have no direct access to the objects studied
Transient rare events require "trigger" + observe
• Supernovae, Gamma-ray bursts
 requirements on computing power availability
Need numerical simulations
Numerical investigations
• Growing need for computationally very intensive numerical
investigations (both large scale and Monte-Carlo)
• Astrophysical complex objects/phenomena
(supernovae explosions, various extreme events)
• Large size systems
(the Universe …! )
• Computationally very demanding - virtually no limit
(hundreds... of hours on huge parallel or vectorial computers)
• Priorities/scales still subject of discussion in the community
Putting observations together ...
Very different "observations" (in terms of experimental setup, data
description, data processing) are various means of accessing higherlevel information
• Observation at various wavelengths (radio, optical, gamma…) or with
various carriers (photons, neutrinos, protons, GW...)
• Observation of different phenomena depending each in a non-trivial way
on a common set of global parameters
• example : the rate of SN explosions, the statistics of CMB fluctuations,
the properties of galaxy clusters… all depend on a small set of
cosmological parameters
Qualitative evolution
Sparse, incomplete data
rich, complex, diverse
and complementary data sets
Virtual observatories / data mining ...
 Access needed to virtual observatories (data bases)
Type of access still unclear
from
copy once relevant data in repositories
to
multiple random access to distributed data
Objective of access still unclear
from
merge high level (processed) information
to
merge low-level data for the processing
Numerical
investigations
Virtual observatories,
Access to diverse data
Access to
computing power
Data merging,
Joint analyses
Short timescale projects
• (Competitive) area of research still open to surprises and new ideas
(theoretical and experimental) generating short timescale projects :
• EROS (microlensing)
• Archeops (CMB), ...
 New specific computing needs may appear tomorrow...
Summary
• Data type (events vs. other type of data)
"event-type" processing (AUGER, ANTARES, HESS, EDELWEISS…) not
fundamentally different for non-accelerator and accelerator based
experiments (different scales though)
• Non "event-type" data
•
•
•
•
(Archeops, PLANCK, SNLS, virgo?)
typically requires
global analysis of a (moderately) large quantity of data
large memory and disk rather than storage (I/O intensive)
needed CPU time very much data-set (and method) dependent
needed CPU time still subject to debating in the communities
• Observations (vs. Experiments)
Joint analysis of distributed complex data sets
Processing availability for "alerts" (supernovae, gamma-ray bursts...)
• Generation of "numerical data sets" :
• growing computationnaly simulation needs
• probably major source of need for distributed computing time
ICFA SCIC Report on World
Networks to the HEPCCC
Harvey B. Newman
California Institute of Technology
HEPCCC Meeting
October 18, 2002
Transatlantic Net WG (HN, L. Price)
Bandwidth Requirements (2001) [*]

2001 2002
2003
2004
2005
2006
CMS
100
200
300
600
800
2500
ATLAS
50
100
300
600
800
2500
BaBar
300
600
2300
3000
CDF
100
300
2000
3000
6000
D0
400
1600 2400 3200
6400
8000
BTeV
20
40
100
200
300
500
DESY
100
180
210
240
270
300
1100 1600
400
CERN 155- 622 2500 5000 10000 20000
BW
310
[*] Installed BW. Maximum Link Occupancy 50% Assumed
See http://gate.hep.anl.gov/lprice/TAN
History – One large Research
Site
Much of the Traffic:
SLAC  IN2P3/RAL/INFN;
via ESnet+France;
Abilene+CERN
Projections: 0.5 to 24 Tbps
by ~2012
ESnet History
Research ISP
100% growth in traffic/yr for
last 12 years
Continuous upgrades
Increase packet size (bulk
throughput apps)
As of 10/2002 Plan
Accelerated: 10 Gbps Asap
Baseline BW for the US-CERN
Link:
HENP Transatlantic WG
(DOE+NSF
)
Link Bandwidth (Mbps)
Transoceanic
Networking
Integrated with
the Abilene,
TeraGrid,
Regional Nets
and Continental
Network
Infrastructures
in US, Europe,
Asia, South
America


20000
15000
Baseline evolution typical
of major HENP
links 2001-2006
10000
5000
0
FY200 FY200 FY200 FY200 FY200 FY200
1
2
3
4
5
6
BW (Mbps)
310
622
2500
5000 10000 20000
DataTAG 2.5 Gbps Research Link since Summer 2002
10 Gbps Link for Production (2.5) & Research by 1Q 2003
DataTAG Project
NewYork
ABILEN
E
UK
SuperJANET4
It
GARR-B
STARLIGHT
ESNET
GENEVA
GEANT
NL
SURFnet
STAR-TAP
CALRE
N
Fr
Renater
EU-Solicited Project. CERN, PPARC (UK), Amsterdam (NL), and INFN (IT);
and US (DOE/NSF: UIC, NWU and Caltech) partners
Main Aims:
 Ensure maximum interoperability between US and EU Grid Projects
 Transatlantic Testbed for advanced network research
2.5 Gbps Wavelength Triangle 7/02 (10 Gbps Triangle by Spring 2003)
iGrid2002: OC192+OC48
Setup
Argonne
Amsterdam
September 2002
StarlightChicago
CERN
Assisted by Loans: Level3 (OC192) and Cisco (10GbE and 16X1GbE)
LHCnet Network : Late 2002-2003
GEANT
Switch
IN2P3
WHO
CERN -Geneva
Cisco 7609
CERN
Linux PC for
Performance tests
& Monitoring
Alcatel 7770 Cisco 7606 Juniper M10
DataTAG
DataTAG
DataTAG
(CERN)
(CERN)
(CERN)
Optical Mux/Dmux
Alcatel 1670
2.5 – 7.5G
(R&D)
0.622 to 2.5G
(Prod.)
Cisco 7609
Caltech
(DoE)
Caltech/DoE PoP – StarLight Chicago
Abilene
Optical Mux/Dmux
Alcatel 1670
Linux PC for
Performance tests
& Monitoring
ESnet
Development and tests
Alcatel 7770 Cisco 7606 Juniper M10
Caltech
DataTAG
Caltech
(DoE)
(CERN)
(DoE)
NASA
MREN
STARTAP
HENP Scenario Limitations:
Technologies and Costs
 Router Technology and Costs
(Ports and Backplane)
 Computer CPU, Disk and Bus, I/O Channel
Speeds to Send and Receive Data
 Link Costs: Unless Dark Fiber (?)
 MultiGigabit Transmission Protocols
End-to-End
 “100 GbE” Ethernet (or something else) by
~2006: for LANs to match WAN speeds
ICFA and International
Networking
ICFA Statement on Communications in Int’l HEP
Collaborations of October 17, 1996
See http://www.fnal.gov/directorate/icfa/icfa_communicaes.html
“ICFA urges that all countries and institutions wishing
to participate even more effectively and fully in
international HEP Collaborations should:
 Review their operating methods to ensure they
are fully adapted to remote participation
 Strive to provide the necessary communications
facilities and adequate international bandwidth”
NTF
ICFA Network Task Force: 1998
Bandwidth Requirements Projection
(Mbps)
1998
2000
2005
0.05 - 0.25
(0.5 - 2)
0.2 – 2
(2-10)
0.8 – 10
(10 – 100)
0.25 - 10
1.5 - 45
34 - 622
BW to a Home Laboratory Or
Regional Center
1.5 - 45
34 - 155
622 - 5000
BW to a Central Laboratory
Housing One or More Major
Experiments
34 - 155
155 - 622 2500 - 10000
BW on a Transoceanic Link
1.5 - 20
34 - 155
BW Utilized Per Physicist
(and Peak BW Used)
BW Utilized by a University
Group
622 - 5000
100–1000 X Bandwidth Increase Foreseen for 1998-2005
See the ICFA-NTF Requirements Report:
http://l3www.cern.ch/~newman/icfareq98.html
ICFA Standing Committee on
Interregional Connectivity (SCIC)
 Created by ICFA in July 1998 in Vancouver ; Following ICFA-NTF
 CHARGE:
Make recommendations to ICFA concerning the
connectivity between the Americas, Asia and Europe
As part of the process of developing these
recommendations, the committee should
 Monitor traffic
 Keep track of technology developments
 Periodically review forecasts of future
bandwidth needs, and
 Provide early warning of potential problems
 Create subcommittees when necessary to meet the charge
 The chair of the committee should report to ICFA once per
year, at its joint meeting with laboratory directors (Feb. 2003)
 Representatives: Major labs, ECFA, ACFA, NA Users, S. America
ICFA-SCIC Core Membership
 Representatives from major HEP
 ECFA representatives:
laboratories:
Manuel Delfino
(CERN)
to W. Von Rueden
Michael Ernst
(DESY)
Matthias Kasemann (FNAL)
Yukio Karita
(KEK)
Richard Mount
(SLAC)
 User Representatives
Frederico Ruggieri (INFN
Frascati),
Denis Linglin (IN2P3, Lyon)
 ACFA representatives:
Rongsheng Xu
(IHEP Beijing)
HwanBae Park
(Kyungpook Nat’l University)
Richard Hughes-Jones (UK)
 For South America:
Harvey Newman
(USA)
Dean Karlen
(Canada)
Sergio F. Novaes
(University of Sao Paulo)
 For Russia:
Slava Ilyin
(MSU)
ICFA SCIC Meetings[*] and Topics
 Focus on the Digital Divide This Year
 Identification of problem areas; work on ways to
improve
 Network Status and Upgrade Plans in Each Country
 Performance (Throughput) Evolution in Each Country,
and Transatlantic
 Performance Monitoring World-Overview
(Les Cottrell, IEPM Project)
 Specific Technical Topics (Examples):
 Bulk transfer, QoS, Collaborative Systems, Security,
VOIP
 Preparation of Reports to ICFA (Lab Directors’ Meetings)
 Last Report: World Network Status and Outlook - Feb.
2002
 Next Report: Digital Divide, + Monitoring, Advanced
SCIC Sub-Committees
Web Page http://cern.ch/ICFA-SCIC/
 Monitoring: Les Cottrell
(http://www.slac.stanford.edu/xorg/icfa/scic-netmon)
With Richard Hughes-Jones (Manchester), Sergio Novaes
(Sao Paolo); Sergei Berezhnev (RUHEP), Fukuko Yuasa
(KEK), Daniel
Davids (CERN), Sylvain Ravot (Caltech), Shawn McKee
(Michigan)
 Advanced Technologies: Richard Hughes-Jones with Vladimir
Korenkov (JINR, Dubna), Olivier Martin(CERN), Harvey
Newman
 End-to-end Connectivity: Richard Mount (SLAC)
 With Michael Ernst, Denis Linglin, Alexandre Sztajnberg (Rio,
Brazil)
 The Digital Divide: Alberto Santoro (Rio, Brazil)
 With Slava Ilyin, Yukio Karita, David O. Williams
 Also Dongchul Son (Korea), Hafeez Hoorani (Pakistan),
Network Progress and
Issues for Major Experiments
 Major R&E Networks have weathered the economic
“storm”
 Backbones & major links advancing rapidly to 10 Gbps
range
 “Gbps” end-to-end throughput data flows have been
tested; will be in production soon (in 1-2 years)
 Network advances are changing the view of the net’s
roles
 Progress to and beyond 10 Gbps within next few
years
 Likely to have a profound impact on the experiments’
Computing Models, and bandwidth requirements
 More dynamic view: dynamic path provisioning;
GB to TB data transactions
 Net R&D Driven by Advanced integrated applications,
such
ICFA SCIC: R&E Backbone and
International Link Progress
GEANT Pan-European Backbone (http://www.dante.net/geant)
 Now interconnects >31 countries; many trunks 2.5 and 10
Gbps
UK: SuperJANET Core at 10 Gbps
 2.5 Gbps NY-London, with 622 Mbps to ESnet and Abilene
France (IN2P3): 2.5 Gbps RENATER backbone by mid-October
 Lyon-CERN Link being Upgraded to 1 Gbps Ethernet
 Proposal for dark fiber to CERN by end 2003
SuperSINET (Japan): 10 Gbps IP and 10 Gbps Wavelength
Core
 Tokyo to NY Links: Now 2 X 2.5 Gbps; Need to get to
Starlight
CA*net4 (Canada): Interconnect customer-owned dark fiber
nets across Canada at 10 Gbps, started July 2002
 “Lambda-Grids” by ~2004-5
GWIN (Germany): 2.5 Gbps Core; Connect to US at 2 X 2.5
Gbps;
Support for SILK Project: Satellite links to FSU Republics
R&E Backbone and Int’l Link Progress
Abilene (Internet2) Upgrade from 2.5 to 10 Gbps Underway
 Encourage high throughput use for targeted applications
ESNET: Upgrade to 10 Gbps “Now”
US-CERN
 to 622 Mbps in August; Move to STARLIGHT
 2.5G Research Triangle from August 2002
STARLIGHT-CERN-NL; to 10G in 2003
SLAC + IN2P3 (BaBar)
 To ~100 Mbps throughput over US-CERN and Renater links
 600 Mbps Throughput is BaBar Target for this Year
(with ESnet and IN2P3 Link Upgrades)
FNAL
 ESnet Link Upgrade to 622 Mbps
 Plans for dark fiber to STARLIGHT, planned for this Fall
NY-Amsterdam Donation from Tyco, September 2002:
Arranged by IEEAF: 622 Gbps+10 Gbps Research
Wavelength
National Research Networks
in Japan
SuperSINET
NIFS
 Started operation January 4, 2002
Nagoya U
NIG
 Support for 5 important areas:
HEP, Genetics, Nano-Technology,
Space/Astronomy, GRIDs
Nagoya
 Provides 10 ’s:
 10 Gbps IP connection
 Direct intersite GbE links
Osaka
 7 Univ. Connected;
Osaka U
Add 3 More this Month
Tokyo
HEPnet-J
Kyoto U
 Reconstructed with
MPLS-VPN in SuperSINET ICR
Kyoto-U
Proposal: Two TransPacific
2.5 Gbps Wavelengths, and
Japan-CERN Grid Testbed by ~2003
IP
WDM path
IP router
OXC
Tohoku
U
KEK
NII Chiba
NII
Hitot.
ISAS
U Tokyo
Internet
NAO
IMS
U-Tokyo
National R&E Network Example
Germany: DFN Transatlantic Connectivity
2002
 2 X OC48: NY-Hamburg
and NY-Frankfurt
 Direct Peering to Abilene (US) and
Canarie (Canada)
UCAID will adding another 2
OC48’s; in a Proposed Global
Terabit Research Network (GTRN)
STM 16
FSU Connections via satellite:
Yerevan, Minsk, Almaty, Baikal
 Speeds of 32 - 512 kbps
SILK Project (2002): NATO funding
 Links to Caucasus and Central
Asia (8 Countries)
In 2001-2 64-512 kbps
Proposed VSAT for 10-50 X BW:
NATO + State Funding
National LightRail: cost-effective owned lit R&E fiber fabric
7/03
Leading-Edge e2e services & experimental
network facilities via MetaPoPs and inter-gigapop
footprint
links for research & next gen. tech., arch., grids,
DTF expansion, content, sensors, apparatus …
Up to 40 dedicated 10 gigabit waves with up to
Canarie
hundreds of dedicated gigabit links system-wide.
fabric
SEA
10 gbs
Tyco IEEAF
donation
BOS
CHI
SUN
CLV?
PIT
DC
DEN
Raleigh?
LA
ATL
8/14/02
10 gbs
Tyco
NY
IEEAF
Donation
MetaPoPs & Core Nodes
ADM sites
Desired Expansion PoPs/ADM
National LightRail” (NLR)
NLR Under Consideration
International Broadband
Metro/WAN owned Fiber ‘Rings’ connecting strategic R&E endpoints.
IEPM: PingER
Deployment
Measurements from
34 monitors in 14 countries
Over 600 remote hosts
Over 72 countries
Over 3300 monitor-remote site
pairs
Measurements go back to Jan-95
Reports on RTT, loss, reachability,
jitter, reorders, duplicates …
Countries monitored
Contain 78% of
world population
99% of online users
of the Internet
Mainly A&R sites
Monitoring Sites
Remote Sites
History – Loss Quality (Cottrell)
Fewer sites have very poor to dreadful
performance
More have good performance (< 1% Loss)
History - Throughput Quality
Improvements from US
80% annual
(1)
Bandwidth of TCP < MSS/(RTT*Sqrt(Loss)) improvement
Factor ~100/8
yr
Progress: but Digital Divide is Maintained
(1) Macroscopic Behavior of the TCP Congestion Avoidance Algorithm,
Matthis, Semke, Mahdavi, Ott, Computer Communication Review 27(3),
True End to End Experience
 User perception
 Application
 Operating system
 Host IP stack
 Host network card
 Local Area Network
 Campus backbone
network
 Campus link to regional
network/GigaPoP
 GigaPoP link to Internet2
national backbones
 International
connections
EYEBALL
APPLICATION
STACK
JACK
NETWORK
...
...
...
...
Work on the Digital Divide:
Several Perspectives
 Identify & Help Solve Technical Problems:
Nat’l, Regional, Last 10/1/0.1 km
 Inter-Regional Proposals (Example: Brazil)
US NSF Proposal (10/2002); possible EU LIS
Proposal
 Work on Policies and/or Pricing: pk, in, br, cn, SE
Europe, …
E.g. RoEduNet (2-6 Mbps); Pricing not so different
from US-CERN price in 2002 for a few Gbps
Find Ways to work with vendors, NRENs, and/or
Gov’ts
 Use Model Cases: Installation of new advanced fiber
infrastructures; Convince Neighboring Countries
Poland (to 5k km Fiber); Hungary; Slovakia; Ireland
 Exploit One-off Solutions: E.g. extend the SILK Project
(DESY/FSU satellite links) to a SE European site
Romania: 155 Mbps to GEANT and
Bucharest;
Inter-City Links of 2-6 Mbps
34Mbps
34Mbps
34Mbps
34Mbps
Annual Cost
> 1 MEuro
34Mbps
GEANT
155Mbps
Yugoslavia
Digital Divide Committee
HUNGARY
Losses: World by sub-region, Jan ‘02
• <1%=good, <2.5%=acceptable, < 5%=poor,
>5%=bad Monitored
• Russia,
S
America
bad
• Balkans,
M East,
Africa,
S Asia,
Caucasu
s poor
Region \
Monitor
BR CA DK DE HU IT JP RU CH UK US
Country (1) (2) (1) (1) (1) (3) (2) (2) (1) (3) (16) Avg
COM
0.2
0.3
0.3 0.2
Canada
1.8 1.6 0.3 0.5 9.0 0.3 1.4 21.7 0.7 0.7 0.5 3.5
US
0.4 2.6 0.2 0.3 8.0 0.1 1.4 13.8 0.3 1.3 0.9 2.7
C America
0.9 0.9
Australasia
0.8 1.8 1.3
E Asia
1.2 3.5 1.0 1.1 9.0 0.9 2.0 5.2 1.5 1.4 1.5 2.6
Europe
0.4 5.6 0.3 0.5 5.4 0.4 1.3 15.5 1.1 1.0 1.0 2.9
NET
1.7 6.2 1.0 1.3 8.0 1.6 3.6 21.9 0.7 0.8 0.9 4.3
FSU4.5
0.5 9.8 0.5 1.6 11.2 4.3 1.2 2.0 4.0
Balkans
3.8 3.8
Mid East
4.6 1.4 3.0 8.5 2.8 3.2 11.8 2.0 2.5 2.1 4.2
Africa
5.8
1.5 12.0 1.2 4.2 11.9 2.0 1.9 2.5 4.8
Baltics
5.3 0.8 2.3 7.7 2.2 3.5 10.8 4.8 2.1 3.9 4.3
S Asia
1.6 7.3 0.1 3.1 9.2 3.0 3.9 17.9 1.5 3.1 3.0 4.9
Caucasus
3.2 3.2
S America 24.1 11.3 0.6 0.9 6.7 12.9 7.7 23.0 9.3 1.1 6.6 9.5
Russia
35.9 24.1 22.2 13.4 23.8 21.7 13.6 0.7 8.7 24.1 12.7 18.3
Avg
7.5 6.9 2.8 2.4 9.8 3.7 3.9 13.8 3.1 3.2 2.8 4.4
Pairs
64 144 54 67 70 203 190 114 209 192 1990
A
v
gAvg
-NA +
(WEU
H+ JP Pairs
Region
COM
0.27
23
Canada
0.74 126
US
0.88 2149
C America 0.89 19
Australasia 1.30 18
E Asia
1.61 215
Europe
1.38 852
NET
2.00
85
FSU2.09
48
Balkans
3.83 109
Mid East
2.70
57
Africa
2.72
45
Baltics
3.12
67
S Asia
3.12
97
Caucasus
3.22
19
S America 6.30 203
Russia
17.57
91
Avg
3.16
Pairs
NREN Core Network Size (Mbpskm):
100M
http://www.terena.nl/compendium/2002
Logarithmic Scale
10M
Advanced
1M
In Transition
Gr
100k
10k
Ir
Lagging
Ro
1k
Ukr
100
Leading
Pl
Cr
It
Ch
Hu
Es
Fi
Nl
Cz
Digital Divide Activities
 Questionnaire Being Distributed (Discuss At ICFA
Meeting)
CERN/IT to Assist with Web Form; Online Submission
 Plan on Project to Build HENP World Network Map;
Updated and Maintained on a Web Site, Backed by
Database:
 Systematize and Track Needs and Status
 Information: Link Bandwidths, Utilization, Quality,
Pricing,
Local Infrastructure, Last Mile Problems, Vendors,
etc.
 Identify Urgent Cases; Focus on Opportunities to
Help
First ICFA SCIC Workshop: Focus on the Digital Divide
 Target Date February 2004 in Rio de Janeiro (LISHEP)
Digital Divide Sub-Committee:
Questionnaire Response Extract:
Institution
Computing / networking needs related to HEP
Other
UERJ, Brazil
HEPGRID PROJECT presented for financial support to
work on CMS; T3 then T1. Last Mile Problem: Need to
reach RNP with good routing from UERJ
Wait for
approved funds
to build a T3; In
2005/6 a T1
Cinvestav,
Mexico
Dedicated 2 Mbps link for HEP group Needed
(now 2 X 2 Mbps for Whole Community; Not Enough)
UNLP,
Argentina
a) LAN upgrade to 100 Mbps;
b) LAN-to-WAN upgrade to 4 Mbps
JSI, Slovenia
Additional bandwidth needed for HEP;
now 2 Mbps for > 1000 people
QAU, Pakistan
In terms of bandwidth need to upgrade but no last mile
connection problem. High Prices
TIFR, India
Will have a Tier3 Grid node; Need network bandwidth
upgrades at reasonable price (Telecom monopoly)
IFT-UNESP
Brazil
Will maintain a farm for Monte Carlo studies and a Tier
3 Grid node; need more bandwidth
University of
CYPRUS
HEP group intends to build a type T2 or T3 Grid node,
and contribute to MC Production. Need to upgrade
Network to Gigabit/sec. In principle there is no access
limit the Network now. But daily traffic load is the real
limitation.
Also plans for
T2 at NUST
34 Mbps Link to
GEANT.Universi
ty pays for
Network
“Cultivate and promote
practical solutions to
delivering scalable,
universally available
and equitable access to
suitable bandwidth and
necessary network
resources in support of
research and
education
collaborations.”
Groningen Carrier
Hotel: March 2002
http://www.ieeaf.org
CA-Tokyo by ~1/03
NY-AMS
Done 9/02
(Research)
Tyco Transpacific Donation
Plan: Santa ClaraJP-HK-TW-CN-SG
Global Medical Research Exchange
Initiative
Bio-Medicine and Health Sciences
St.
Petersburg
Kazakhstan
Uzbekistan
NL
CA
MD
Barcelona
Greece
GHANA
Layer 1 – Spoke & Hub Sites
Buenos
Aires/San
Paolo
Chenai
Navi
Mumbai
CN
SG
PERTH
Layer 2 – Spoke & Hub Sites
Layer 3 – Spoke & Hub Sites
Global Quilt Initiative – GMRE Initiative - 001
Proposed Global Research and Education Network for Physics
Networks, Grids and HENP
 Next generation 10 Gbps network backbones are
almost here: in the US, Europe and Japan
 First stages arriving, starting now
 Major transoceanic links at 2.5 - 10 Gbps in 2002-3
 Getting high (reliable; Grid) application performance
across networks means!
 End-to-end monitoring; a coherent approach
 Getting high performance (TCP) toolkits in users’ hands
 Working in concert with AMPATH, Internet2, Terena;
DataTAG, the Grid projects and the Global Grid Forum
 Network improvements are especially needed in
SE Europe, So. America; SE Asia, and Africa:
 Key Examples: India, Pakistan, China; Brazil; Romania
 Removing regional, Last mile bottlenecks and
compromises
in network quality are now (in all world regions)
On the critical path
Networking for HENP
Closing the Digital Divide
What ICFA, HEPCCC and the HENP Community Can Do
 Spread the message: ICFA SCIC is there to help
 Help identify and highlight specific needs (to Work On)
Policy problems; Last Mile problems; etc.
 Encourage Joint programs [such as in DESY’s Silk project;
Japanese links to SE Asia and China; AMPATH to So.
America]
 NSF & LIS Proposals: US and EU to South America
 Make direct contacts, arrange discussions with gov’t officials
 ICFA SCIC is prepared to participate
 Help Start, or Get Support for Workshops on Networks (&
Grids)
 Discuss & Create opportunities
 Encourage, help form funded programs
Lyon biology grid project
1)IN2P3 was willing to open partially the
services of its computing center to the
french BioMedical research community.
 Setting-up of collaborations with biology
labs, in the Lyon area first.
2)DATAGRID and its WP10 has been an
important opportunity to foster links with
the Bio community. Submit production
jobs or web requests thru grid tools is
one goal.
3) But the opening is going beyond the sole
GRID aspects.
LHCC 18 October 2002
The collaboration with biologists

Real collaborations and grid effort have
started only when we opened one post to
deal with the Bio needs = May 2002.

In addition to EDG WP10, Collaborations
with 3 labs (CNRS-Univ.) have started:
- IBCP (protein bio-chemistry)
- BBE (Biometry & evolutive Biology)
- ERIC (Mammography, breast cancer)
LHCC 18 October 2002
Bio needs : CPU, storage, gridification
CPU :
- Protein sequence comparison algorithms
- philogenic tree calculations
- Metadata generation for medical imaging
STORAGE :
- Reference data bases for proteins and genomics
- Medical images for diagnostic assistance
- Metadata for client radio-medical images
GRID ?
- Only a subset deserves gridification.

LHCC 18 October 2002
Dealing with biologists ? strategy




Culture in Bio research is different : there are no such
collaborations as we are used to in physics
For computing, common thinking is still one PC and all
the services + software on this single PC.
This is the main problem : eg. genomic software and its
environment (tools, libraries, OS) need to be tested &
disseminated before running on several sites as it is
common in HEP eg. to perform LHC Data Challenges
Going from a software running locally with plenty of "doit yourself" fixes to a "full-proof, ready to install
everywhere" product is not an easy task.
Two problems to be solved : cultural and technical.
The cultural barrier is no more a problem with our
collaborators, but structuration, organisation, support is
still lacking. We can push but not replace.
LHCC 18 October 2002
Strategy = cultural + technical =



Ease access to such a computing
service center to which they are
not used to.
Analyse their needs and propose
suited solutions.
For a selected subset, set up a grid
access.
LHCC 18 October 2002
Bio-med regional grid







Select 1 "grid-aware" Bio lab and 2 HEP labs,
plus one application running as a web request
= protein structure comparisons
Web-interfaced grid access (portal in Bio lab)
Application, libraries and DataBases need to
be installed and updated regularly
Job submission / web requests to 3 clusters
(CC-IN2P3, IBCP and LPC Clermont) from this
portal
User-friendly = a simple web request
Use datagrid middleware = the resource
broker of EDG +etc..
Beyond this test, will connect other bio
applications to the grid.
LHCC 18 October 2002
Lyon Biogrid test
Web request
IBCP
Compute+service
Cluster LPC
Clermont-Ferrand
portal
Result
On each site :
Resource
Broker CC
- updated dayly database
- job submission system
Compute+service
Cluster CC-IN2P3
- visible from outside
CC-IN2P3 ready
Compute+service
Cluster IBCP Lyon
LHCC 18 October 2002
Situation



CC-IN2P3 : tools are ready since september
LPC Clermont-F. : need to open their farm and
set-up a job submission tool.
IBCP : idem
+ dayly DB export
 + portal modif. (checked it was not a major change


Expected a first test in early october, but we
are still waiting for the other 2 labs to be
ready. We (can) help, but we are helpless on
several IBCP tasks. Still in progress.
LHCC 18 October 2002
Medium-term strategy




We have set-up good relations with a few
local labs,well-known. Being neighbours is
important. Tighter links with one (also active in
WP10) : chosen for the grid production test.
These labs learn how to use a computing
center, to express their needs, with figures,
prepare a computing model. All this is new.
Will serve as propagandists for the others
Lyon area (including Clermont, with IN2P3 as
one driving force) recognized as important for
BioMed grids.
LHCC 18 October 2002
Conclusion




Collaborations with biologists go beyond the
grid : try to disseminate our computing
culture, of which grid is an important part.
An individual evaluation is needed to adapt
the Bio needs to CC architecture
Hope to get first tests on 3-sites bio-grid very
soon, but as everywhere, speed is driven by
the slowest partner.
One related success to be quoted : the first
open healthgrid workshop to prepare 6th
R&D european program will be held in Lyon,
16-17 january 2003. IN2P3 co-organiser and
in scientific comm.
LHCC 18 October 2002
iHEPCCC Developments
HEPCCC Working Group formed during 10/18/03 HEPCCC
– Guy Wormser (Chair), Song, Kawabata (ACFA), Avery, Price (HEPAP),
Barreira (ECFA), Haas (HEPCCC/HTASC)
Several meetings (phone, video, in person) over the last few months
(last one at SLAC in January)
Draft charter presented to ICFA at the Tokyo meeting in Febuary
G. Wormser writes:
– good overall positive reaction,
– need to revise the membership rules,
– suggestion to create a bureau that could effectively meet in person three
tiles a year while the general assembly could take place once a year in
person and by video/phone otherwise.
Final Suggestion on charter to HEPCCC at the 4 April meeting.