1 / 17

Grid Infrastructure for Caltech CMS Production on Alliance Resources

Grid Infrastructure for Caltech CMS Production on Alliance Resources. Vladimir Litvin, Harvey Newman Caltech CMS Scott Koranda, Bruce Loftis, John Towns NCSA Miron Livny, Peter Couvares, Todd Tannenbaum, Jamie Frey Wisconsin Condor. CMS Physics.

zelia
Télécharger la présentation

Grid Infrastructure for Caltech CMS Production on Alliance Resources

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Grid Infrastructure for Caltech CMS Production on Alliance Resources Vladimir Litvin, Harvey Newman Caltech CMS Scott Koranda, Bruce Loftis, John Towns NCSA Miron Livny, Peter Couvares, Todd Tannenbaum, Jamie Frey Wisconsin Condor

  2. CMS Physics The CMS detector at the LHC will probe fundamental forces in our Universe and search for the yet undetected Higgs Boson Detector expected to come online 2006

  3. CMS Physics

  4. ENORMOUS Data Challenges • One sec of CMS running will equal data volume equivalent to 10,000 Encyclopaedia Britannica • Data rate handled by the CMS event builder (~500 Gbit/s) will be equivalent to amount of data currently exchanged by the world's telecom networks • Number of processors in the CMS event filter will equal number of workstations at CERN today (~4000)

  5. Leveraging Alliance Grid Resources • The Caltech CMS group is using Alliance Grid resources today for detector simulation and data processing prototyping • Even during this simulation and prototyping phase the computational and data challenges are substantial

  6. CMS run naturally divided into two phases Monte Carlo detector response simulation 100’s of jobs per run each generating ~ 1 GB all data passed to next phase and archived reconstruct physics from simulated data 100’s of jobs per run jobs coupled via Objectivity database access ~100 GB data archived Specific challenges each run generates ~100 GB of data to be moved and archived many, many runs necessary simulation & reconstruction jobs at different sites large human effort starting & monitoring jobs, moving data Challenges of a CMS Run

  7. Globus middleware deployed across entire Alliance Grid remote access to computational resources dependable, robust, automated data transfer Condor strong fault tolerance including checkpointing and migration job scheduling across multiple resources layered over Globus as “personal batch system” for the Grid Meeting Challenge With Globus and Condor

  8. Master Condor job running at Caltech CMS Run on the Alliance Grid • Caltech CMS staff prepares input files on local workstation • Pushes “one button” to launch master Condor job • Input files transferred by master Condor job to Wisconsin Condor pool (~700 CPUs) using Globus GASS file transfer Caltech workstation Input files via Globus GASS WI Condor pool

  9. Master Condor job running at Caltech Secondary Condor job on WI pool 100 Monte Carlo jobs on Wisconsin Condor pool CMS Run on the Alliance Grid • Master Condor job at Caltech launches secondary Condor job on Wisconsin pool • Secondary Condor job launches 100 Monte Carlo jobs on Wisconsin pool • each runs 12~24 hours • each generates ~1GB data • Condor handles checkpointing & migration • no staff intervention

  10. CMS Run on the Alliance Grid • When each Monte Carlo job completes data automatically transferred to UniTree at NCSA • each file ~ 1 GB • transferred using Globus-enabled FTP client “gsiftp” • NCSA UniTree runs Globus-enabled FTP server • authentication to FTP server on user’s behalf using digital certificate 100 Monte Carlo jobs on Wisconsin Condor pool 100 data files transferred via gsiftp, ~ 1 GB each NCSA UniTree with Globus-enabled FTP server

  11. Secondary reports complete to master Master Condor job running at Caltech Secondary Condor job on WI pool NCSA Linux cluster gsiftp fetches data from UniTree CMS Run on the Alliance Grid • When all Monte Carlo jobs complete Secondary Condor reports to Master Condor at Caltech • Master Condor at Caltech launches job to stage data from NCSA UniTree to NCSA Linux cluster • job launched via Globus jobmanager on cluster • data transferred using Globus-enabled FTP • authentication on user’s behalf using digital certificate Master starts job via Globus jobmanager on cluster to stage data

  12. Master Condor job running at Caltech NCSA Linux cluster CMS Run on the Alliance Grid • Master Condor at Caltech launches physics reconstruction jobs on NCSA Linux cluster • job launched via Globus jobmanager on cluster • Master Condor continually monitors job and logs progress locally at Caltech • no user intervention required • authentication on user’s behalf using digital certificate Master starts reconstruction jobs via Globus jobmanager on cluster

  13. NCSA Linux cluster CMS Run on the Alliance Grid • When reconstruction jobs complete data automatically archived to NCSA UniTree • data transferred using Globus-enabled FTP • After data transferred run is complete and Master Condor at Caltech emails notification to staff data files transferred via gsiftp to UniTree for archiving

  14. Production Data • 7 Signal Data Sets 50000 events each have been simulated and reconstructed without pileup • Large QCD background Data Set (1M of events) has been simulated through this system • Data has been stored both NCSA UniTree and Caltech HPSS

  15. Condor Details for Experts • Use CondorG • Condor + Globus • allows Condor to submit jobs to remote host via a Globus jobmanager • any Globus-enabled host reachable (with authorization) • Condor jobs run in the “Globus” universe • use familiar Condor classads for submitting jobs universe = globus globusscheduler = beak.cs.wisc.edu/jobmanager- condor-INTEL-LINUX environment = CONDOR_UNIVERSE=scheduler executable = CMS/condor_dagman_run arguments = -f -t -l . -Lockfile cms.lock -Condorlog cms.log -Dag cms.dag -Rescue cms.rescue input = CMS/hg_90.tar.gz remote_initialdir = Prod2001 output = CMS/hg_90.out error = CMS/hg_90.err log = CMS/condor.log notification = always queue

  16. Condor Details for Experts • Exploit Condor DAGman • DAG=directed acyclic graph • submission of Condor jobs based on dependencies • job B runs only after job A completes, job D runs only after job C completes, job E only after A,B,C & D complete… • includes both pre- and post-job script execution for data-staging, cleanup, or the like Job jobA_632 Prod2000/hg_90_gen_632.cdr Job jobB_632 Prod2000/hg_90_sim_632.cdr Script pre jobA_632 Prod2000/pre_632.csh Script post jobB_632 Prod2000/post_632.csh PARENT jobA_632 CHILD jobB_632 Job jobA_633 Prod2000/hg_90_gen_633.cdr Job jobB_633 Prod2000/hg_90_sim_633.cdr Script pre jobA_633 Prod2000/pre_633.csh Script post jobB_633 Prod2000/post_633.csh PARENT jobA_633 CHILD jobB_633

  17. Master Condor job running at Caltech Secondary Condor job on WI pool Future Directions • Include Alliance LosLobos Linux cluster at AHPCC in two ways • Add path so that physics reconstruction jobs may run on Alliance LosLobos Linux cluster at AHPCC in addition to NCSA cluster • Allow Monte Carlo jobs at Wisconsin to “glide-into” LosLobos • Add pileup datasets 75 Monte Carlo jobs on Wisconsin Condor pool 25 Monte Carlo jobs on LosLobos via Condor glide-in

More Related