Report of the Event Tag Review and Recommendation Group Page: 5 of 21
20View a full description of this article.
Extracted Text
The following text was automatically extracted from the image on this page using optical character recognition software:
AOD Production AOD Data/Tag Tag Publishing
Athena Job File Registration File -> Database
Stream -- -
Stream " F
Mass Tag Database
Storage
Tag File
E Data File
Figure 2: General schematic of production and publishing of TAG data. Sizes of rectangles are
not indicative of data size.
The structure of a POOL collection is similar to a flattened struct. The user defines a
list of attributes with simple types (bool, int, string, etc.). Arrays are supported only through
attribute names, e.g. ElectronPtl. The resulting list of attributes is mapped onto a structure in
ROOT (TTree) or in a relational database (data + link tables) by the POOL collection code. In
the TAG building code the application simply sets values for the pseudo-struct (AttributeList)
and fills it with a row per event. Although the underlying technologies support zero suppression,
POOL collections require a value for every element of the AttributeList. In job options for the
RegistrationStream, the user then designates which AttributeList/TAG builder to use and which
DataHeader (with streams there may be multiple DataHeaders in StoreGate concurrently) to use
as the primary reference. The provenance (Back Navigation) record for that primary reference
is also unpacked and stored, although currently that is via a token string which takes up more
space than it could.
As mentioned in the computing model section, the current usage of collections uses the
ROOT format as a way of storing collection data locally during job execution for jobs which
generate TAG data. The ROOT collection is then stored as a normal file/dataset and published
into a relational collection with data from other ROOT collections.
2.3 External Dependencies of TAG Creation and Use
* DDM:The event reference used by POOL collections contains a pointer to the file with
the event data and an offset within the file. This pointer takes the form of a unique ID,
the POOL GUID. This generates an implicit dependency on an external service to resolve
the pointer to the file into a physical file from which to fetch the data. In the current
ATLAS data management system, this means querying the Distributed Data Management
(DDM) [6] system or the local file catalog.
* AMI: The TAG attributes themselves will be stored in files at various sites and tables4
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.
Group, ATLAS; Assamagan, Kétévi A.; Barberis, Dario; Bentvelsen, Stan; Brooijmans, Gustaaf; Cranmer, Kyle et al. Report of the Event Tag Review and Recommendation Group, article, April 12, 2006; Berkeley, California. (https://digital.library.unt.edu/ark:/67531/metadc934611/m1/5/: accessed July 18, 2024), University of North Texas Libraries, UNT Digital Library, https://digital.library.unt.edu; crediting UNT Libraries Government Documents Department.