Abstract
The complex geometry of the whole detector of the ATLAS experiment at LHC is currently stored only in custom online databases, from which it is built on-the-fly on request. Accessing the online geometry guarantees accessing the latest version of the detector description, but requires the setup of the full ATLAS software framework “Athena”, which provides the online services and the tools to retrieve the data from the database. This operation is cumbersome and slows down the applications that need to access the geometry. Moreover, all applications that need to access the detector geometry need to be built and run on the same platform as the ATLAS framework, preventing the usage of the actual detector geometry in stand-alone applications.Here we propose a new mechanism to persistify (in software development in general, and in HEP computing in particular, persistifying means taking an object which lives in memory only - for example because it was built on-the-fly while processing the experimental data, - serializing it and storing it on disk as a persistent object) and serve the geometry of HEP experiments. The new mechanism is composed by a new file format and the modules to make use of it. The new file format allows to store the whole detector description locally in a file, and it is especially optimized to describe large complex detectors with the minimum file size, making use of shared instances and storing compressed representations of geometry transformations. Then, the detector description can be read back in, to fully restore the in-memory geometry tree.Moreover, a dedicated REST API is being designed and developed to serve the geometry in standard exchange formats like JSON, to let users and applications download specific partial geometry information.With this new geometry persistification a new generation of applications could be developed, which can use the actual detector geometry while being platform-independent and experiment-independent.
Highlights
The new file format allows to store the whole detector description locally in a file, and it is especially optimized to describe large complex detectors with the minimum file size, making use of shared instances and storing compressed representations of geometry transformations
Figure 2a shows the diagram of the implementation of a single PhysicalVolume node, representing a geometrical volume
The combination of a PhysicalVolume and a LogicalVolume creates a concrete geometrical object; that object is placed into the space with the usage of a Transformation node, which is inserted as child node before the object to place
Summary
In-memory model vs database The GeoModel description of the ATLAS detector is the master copy of all geometry. Detector factories running within an on-line geometry service read a database of primary numbers and build a highly detailed description of ATLAS, which is translated directly to Geant4 [3] for the full simulation of the detector response. The procedures to build the GeoModel are complex, depend on a large stack of ATLAS software, and lack portability. It is difficult to port the geometry builders into lightweight applications designed to run without the full ATLAS software stack. In this work we designed and developed the mechansim to dump the whole description into a database file and provide a portable mechanism to read it back in, to be used for a generic experiment and within stand-alone applications. The development of the new geometry persistification mechanism presented here is all about portability
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
