The CMS integration grid testbed Page: 2 of 8
This article is part of the collection entitled: Office of Scientific & Technical Information Technical Reports and was provided to UNT Digital Library by the UNT Libraries Government Documents Department.
Extracted Text
The following text was automatically extracted from the image on this page using optical character recognition software:
Computing in High Energy Physics, March 24-28 2003, La Jolla, CA
2. Hardware Included in the IGT
Table I shows the available hardware on the IGT.
Participating sites included the California Institute of
Technology, Fermi National Accelerator Laboratory,
University of California at San Diego, and the Uni-
versity of Florida at Gainesville as of November 1,
2002. A group from the LCG at CERN also joined
the effort after November 15, 2002. While the Uni-
versity of Wisconsin at Madison Computer Science
department did not participate directly in the IGT,
they participated directly in the USCMS Development
Grid Testbed2(DGT) in support of the IGT efforts by
troubleshooting problems and by doing important re-
gression tests on the middleware.
In Spring 2003, most of this hardware will be turned
over to a production grid. A small number of machines
will be saved to do integration testing in support of
production grid operations, which is the original pur-
pose of the IGT in the first place.
3. Software Running on the IGT
In the Grid environment, many different layers of
software have to be present. At the lowest level is the
OS itself. The IGT ran a Linux platform with either
RedHat 6.X based operating systems or with RedHat
7.X based operating systems3. The Grid middleware
was distributed using the Pacman [1] based Virtual
Data Toolkit (VDT) [2]. The version which ran on
the IGT was VDT 1.1.3. The next level of software
included the Job Creation level, consisting of mainly
CMS developed tools and some PPDG provided tools
to wrap CMS specific jobs in Grid aware wrappers,
and finally the CMS applications themselves.
Most Grid sites ran the PBS batch system or the
Condor High Throughput Computing System, the
Farm Batch System Next Generation (FBSNG) was
run at Fermilab. [22]
3.1. VDT Middleware
The VDT is composed of three types of grid soft-
ware, although the lines between these types are some-
times blurry. These three types are:
2The DGT is a smaller clone of the IGT on which it is per-
mitted to deploy untested software.
3The use of RedHat 6.X based operating systems was re-
quired for CMS production with applications based on CMS
ORCA which used Objectivity as an object persistency layer.
This was not because of limitations within Objectivity, but was
rather due to licensing issues.* Core Grid Software This is the grid middleware,
and it includes Globus, [3] Condor-G, and Con-
dor [4].
* Virtual Data Software This is the software that
is able to either compute or fetch data on de-
mand, depending on whether it needs to be com-
puted or is already available.[10]
* Utilities This is a selection of software that pro-
vides smaller but still important utilities, such
as as software for fetching certification authority
revocation lists on a regular schedule.
The IGT made use primarily of the core Grid software
and some of the utilities.
The software in Table II was included with VDT
version 1.1.3, which ran on the IGT.
3.2. CMS Specific Software
The CMS software was distributed to the remote
sites using DAR [20] before any jobs were submitted.
In principle, the CMS software can be installed as
part of the job, as described below in the discussion
of MOP. However, the particular production request
handled by the IGT was large enough (greater than
100,000 CPU hours on a single GHz CPU) to justify
special pre-installation.
CMS Monte Carlo production consists of several
steps [5]. First, vector representations of simulated
physics collision events are generated with the Pythia-
based CMKIN application. Second, the responses
of the CMS detector are simulated in the GEANT
3 based CMSIM application. A third CMS specific
step is to re-format the CMSIM events into an Ob-
jectivity DB format with the writeHits application4.
Forth, the native detector signals must be mixed with
noise simulations and with simulated by-products of
nearly contemporaneous collisions called pileup (PU)
in the writeDigis application. Pileup events are typi-
cally pre-processed and stored in locally resident files
ready to be mixed with signal events in writeDigis,
leading to I/O bound behavior when the number of
pileup events per signal event is large. (For the 1034
luminosity expected in the LHC, this ratio is about
200:1 on average.) Finally, the last stage of produc-
tion involves the creation of analysis objects (ntuples)
to be analyzed by the physicists. Table 3.2 summa-
rizes the average behaviors of the executables used in
CMS Monte Carlo production. Actual production de-
pends most critically on the size of each event at the
CMKIN stage: the more particles produced per event
translated directly into higher processing times.
4This step will be combined with the previous step in future
versions of the software.MOCT010
2
Upcoming Pages
Here’s what’s next.
Search Inside
This article can be searched. Note: Results may vary based on the legibility of text within the document.
Tools / Downloads
Get a copy of this page or view the extracted text.
Citing and Sharing
Basic information for referencing this web page. We also provide extended guidance on usage rights, references, copying or embedding.
Reference the current page of this Article.
Graham, Gregory E. The CMS integration grid testbed, article, August 26, 2004; Batavia, Illinois. (https://digital.library.unt.edu/ark:/67531/metadc780629/m1/2/: accessed April 25, 2024), University of North Texas Libraries, UNT Digital Library, https://digital.library.unt.edu; crediting UNT Libraries Government Documents Department.