InDetAlignHowTo

このwebページはInDetAlignHowTo Wiki pageを理解するため近藤（KEK)が日本語にしたものです。2005.10.13b

Introduction

このページはInDetAlignAlgs と InDetAlignTools packages in Athena の中にあるコードをどのように使ってSCT/pixelのアライメント作業（アライメントデータベースにアクセスし、ユーザー用のプログラムコードを修正するなど）を行うかを示すものです。リリース10.5.0以降のアライメントデータベースのCOOL版と関係しますが、一部分は(combined testbeamで使われたように)Lisbon MySQL conditions database を使ったこれまでの具体化にも関係しています。

アライメントデータの貯蔵

アライメントデータはPOOL ROOTファイルの中に 'referenced data' として conditions database に貯えられる、つまり全てのモジュールの位置を与える実際のdata objects はファイルの中に貯えられ、conditions database (COOL) 自身もこれらの objects および有効な期間（IOVs）の情報と共に貯えられている。ここでIOVsとは特定のアライメント定数が有効であるrun/eventの範囲を示すものである。基礎的な conditions database 構造とAthenaの関連は CoolATLAS と CoolAthenaに書いてある。

Athenaのjobが実行されている間, それが使っている条件データは Storegate Transient Detector Store (TDS) の中に納められているAlignableTransform objects のセットに見つけることができる。ここで TDS とはjobが走っている間は生きている detector description とその他の data を含む貯蔵領域のことでイベントの間（訳者コメント：jobが走っている間ということかな？）には消えることはない。

各々の AlignableTransform object は string name を持っており、一つの(バレルレイヤーまたはendcap disk、SCTかピクセルの）モジュール層のデータおよびoffline Identifier によって識別される object の各モジュールのデータからなる。AlignableTransform クラスの関数は識別（Identifier）によるデータのルックアップを提供し、AlignableTransform object に新しいモジュールを追加する機能がある。各モジュールの実際のデータは CLHEP HepTransform3D object であり、それはモジュールの正規の位置からの座標ズレと回転を指定するものである。

AlignableTransformはgeneric objectであり、単にHepTransform3Dsを持った識別子（Identifier）でしかない。高いレベルではSCT やpixel detectorsのためのデータは、アライメント情報をconditions database上で生成・制御・保存するAthena AlgTool InDetAlignDBToolによって組織される。 TDS内のデータは AlignableTransformContainerの objectとしてStoregate key /Indet/Alignに保存される。このAlignableTransformContainerは実は各レイヤー毎に別々のAlignableTransform objectsのStoregate DataVectorであり、さらに幾つかの追加のAlignableTransform objectsがあり、それらは「高いレベル」で各レイヤーさらには全てのSCTやピクセルを１回の変換で動かすことを可能にする。これらの個々のAlignableTrasnform objectは(AlignableTransform tag() でアクセスできる)名前をもっており、 GeoModel の中で以下のようなハイアラキーのレベルに相当する：

• /Indet/Align/ID (level 1): 4 transforms giving displacements/rotations of the complete pixel detector (treated as one unit), the SCT barrel and two endcaps.
• /Indet/Align/PIX (level 2): 9 tranforms giving displacements/rotations of each of the 3 pixel barrel layers and 2x3 endcap disks.
• /Indet/Align/SCT (level 2): 22 transforms giving the displacements/rotations of each of the 4 barrel SCT layers and 2x9 endcap disks.
• /Indet/Align/PIXB (level 3, n=1-3): Transforms giving the displacements/rotations of each barrel pixel module - the number of transforms in each AlignableTransform object corresponding to the number of modules in the layer.
• /Indet/Align/PIXEA (level 3, n=1-3): Transforms giving the displacements/rotations of each endcap A (z>0) pixel module, the number of transforms in each AlignabelTransform object corresponding to the number of modules in the disk.
• /Indet/Align/PIXEC (level 3, n=1-3): Transforms giving the displacments/rotations of each endcap C (z<0) pixel module.
• /Indet/Align/SCTB (level 3 n=1-4): Transforms giving the displacments/rotations of each barrel SCT module. Note that the r-phi and stereo sides are considered part of the SAME module, and have a common transform.
• /Indet/Align/SCTEA (level 3, n=1-9): Transfors giving the displacements/rotations of each endcap A (z>0) SCT module.
• /Indet/Align/SCTEC (level 3, n=1-9): Transforms giving the displacements/rotations of each endcap C (z<0) SCT module.

Between them, these AlignableTransform objects allow each individual SCT or pixel module to be displaced/rotated, and also allow larger movements of a whole layer or detector part by changing a single transform. The structure is read by the SCT and pixel GeoModel readout geometry classes, such that the positions of the detector modules (returned e.g. by the SiDetectorElement objects) take the alignment corrections into account.

Within the collection of AlignableTransform objects, each object can have its own interval of validity, allowing e.g. for the overall position of one barrel to the next to be updated more or less frequently than the positions of each individual module within a layer. The whole collection is stored in a single COOL folder /Indet/Align, i..e with COOL folder name corresponding to the Storegate ID of the AlignableTransformContainer collection. More detail on the alignment data storage can be found here.

Note that prior to release 10.5.0, the data was stored slightly differently: each AlignableTransform object was stored individually in Storegate, and had its own folder in the conditions database (/Indet/Align/ID, /Indet/Align/SCTB1 etc). The advent of channelIDs in COOL folders, and the ability to store container objects allowed all these objects to be instead stored in the single /Indet/Align folder.

Writing alignment data

Writing alignment data from scratch involves up to four steps:

• Creating the alignment data structures in memory, initially with null transformations (i.e. all modules have their default positions and orientations).
• Optionally modifying the transforms for some modules, to create a 'non-trivial' alignment database.
• Writing the AlignableTransformContainer object into a POOL ROOT file.
• Optionally registering the object and associated IOVs in the conditions database iteslf.

The InDetAlignDBTool provides utility functions to help with all steps, and an example of the whole chain (using the tools) can be found in the InDetAlignWrt algorithm. The joboption file WriteDBS.py can be included in an Athena job to trigger the InDetAlignWrt algorithm to write a database, optionally adding misalignments before writing it out.

In more detail, a default database can be created in the TDS by calling the createDB method of InDetAlignDBTool. The dispGroup, setTrans and tweakTrans methods can then be called to modify the position of modules on a statistical or systematic basis. Writing the AlignableTransformContainer object to an Athena OutputStream (and then to a POOL file) can be done by calling the outputObjs method, which internally calls the AthenaOutputStreamTool, and the objects intervals of validity can be registered using the fillDB method, which calls IOVRegistrationSvc (see CoolAthena for more discussion of these tools).

The following points are worth noting:

• If the AlignableTrasnformContainer object is created in memory in this way, it will not be picked up by the GeoModel code, so the module positions will not actually move. This only happens once the database is written out and read back in a subsequent job.
• For local work, it may be sufficient to write out the POOL file containing the AlignableTransformContainer object, without 'registering it' (i.e. writing any intervals of validity into the conditions database). The POOL file can be read back using the CondProxyProviderSvc as discussed below. Setting the writeIOV jobOption for InDetAlignWrt to FALSE will suppress the registration step.
• The POOL file produced gets added to the POOL file catalogue (either an explicit write catalogue if that is specified to PoolSvc) or the standard PoolFileCatalog.xml . If the POOL file is renamed, its entry in the catalogue should be renamed as well (using FCrenamePFN or by editing the catalogue file by hand), or problems may be encountered.

Reading alignment data

Reading alignment data can be done either using the conditions database (when the run/event number being analysed is used to lookup which POOL objects have to be loaded), or by reading a POOL file containing the AlignableTransformContainer object directly.

• The InDetAlignAlgs job option fragment ReadDBS.py demonstrates reading back from the conditions database, specifying in this case a connection to the production COOL conditions database (via the include of RecExCommon_condDb.py) and the conditions database folder to be read in. A conditions database tag can optionally be specified, to select one of several sets of alignment constants for the same run/event number - such tags are specified when the data is registered in the conditions database write step.
• The InDetAlignAlgs job option fragment ReadPool.py demonstrates reading the alignment data back directly from a POOL file, using the CondProxyProviderSvc. Note in particular that the IOVSvc PreLoadData joboption must be set in this case, to force the GeoModel callbacks to be triggered on the alignment data. Note also that the EventSelectorAthenaPool DLL needs to have been loaded for CondProxyProivderSvc to work - when reading POOL events this happens by default, but if you are reading DC1 data or CTB bytestream data you need to do this explicitly by including:

theApp.DLLs+=["EventSelectorAthenaPool"]

In both cases, additional joboptions are used to tell the SCT and pixel GeoModel factories to look for alignment constants and take them into account.

Altering the database from Athena

An alignment algorithm running inside an Athena job may want to change the alignment database to reflect the result of its computations. This will typically be done in the following way:

• Read in constants at beginning of job (via conditions datbaase or CondProxyProviderSvc as described above).
• Process events and calculate changes to alignment constants (in algorithm execute or finalize).
• Modify in-memory version of the alignment database, using InDetAlignDBTool setTrans and/or tweakTrans methods. Note that these methods internally retrieve Storegate const pointers to the data objects, but const_cast them to allow the objects to be updated. This is because objects read in from the conditions database are normally const, i.e. user algorithms are not allowed to alter them.
• Trigger writing out of new constants to POOL file (using InDetAlignDBTool outputObjs method), optionally registering them in the conditions database using IOVRegistrationSvc. These steps could also be performed by running the InDetAlignWrt algorithm as the last step in the chain.

In normal operation, the constants would probably first be written only to a POOL file, and then verified in a read job using CondProxyProviderSvc. They can then finally be registered by running a final Athena job which reads constants in, writes them to a new file, and the registers then, i.e. using a combination of the ReadPool.py and WriteDBS.py job options.

Note that if you modify the in-memory constants using the setTrans and tweakTrans methods, they will NOT be picked up by the GeoModel until they are written out and read back by a subsequent job.

Sharing information and available databases

The approach with just writing POOL files and reading them back with CondProxyProviderSvc is sufficient for simple use cases, but more complex cases (including sharing alignment databases and exploring constants) will require use of the COOL conditions database to register the intervals of validity and references to the files. This can be done either using the ATLAS COOL Oracle server at CERN, or using a local SQlite database, which is a complete COOL database contained in a single file - for more details, see here.

Some database entries have been added to the COOL production server at CERN, in the ATLAS_COOL_INDET schema, with database OFLPROD. These entries can be browsed using the COOL web browser here, and consist of a number of tags, each of which implement one of the misalignment sets discussed in the note ATLbla. They can be accessed using the joboption fragment ReadDBS.py, replacing the tag mytag with the one you want to use. The available tags and their correspondance to the datasets in the note are as given in this table:

Dataset	Tag	Description
0	nominal0	Nominal alignment, no displacements
P1	pixdisp1	zzz
P2	pixdisp2	zzz
S1	sctlocal1	zzz
S1a	sctlocal2	zzz
S1b	sctlocal3	zzz
S2	sctdisp1	zzz
S3	sctdisp2	zzz
S4	sctlocal4	zzz
S5	sctlocal6	zzz
S6	sctlocal8	zzz
S1P1	sct1pix1	zzz
S3P1	sct2pix1disp	zzz
S3P2	sct2bpix1disp	zzz

Performing iterations

Some new infrastructure in Athena is available to allow iterative calibration to be performed, i.e. looping over a set of events, calculating calibration constants, then looping over the events again, recalculating constants, deciding if another iteration is required, and finally writing out the constants to a POOL file and optionally registering in the IOV database. A special Athena EventSelector has been developed to support this, the MultipleEventLoopManager. This implements an event loop which is the same as the standard Athena event loop, except that at the end of each iteration a user algorithm method is called to decide whether another iteration is required. The MultipleEventLoopManager is used by adding joboptions such as:

# configure the ELM
multipleELM = Service("MultipleEventLoopMgr")
# the next pass filter algorithm
multipleELM.NextPassFilter = "MyFilterAlg"
# special option to event selector to allow collection to be rewound
# (needed to be able to read it more than once)
EventSelector.CollectionType = "SeekableROOT"
# then specify EventSelector input collection(s) as normal ...

Any user algorithm can be used as the filter algorithm, provided it additionally inherits from the class INextPassFilter (see AthenaKernel/INextPassFilter.h) and implements the method doNextPass(). A minimal example algorithm which simply counts the number of iterations and restricts it to a configurable maximum can be found as ToyNextPassFilterAlg in Control/AthenaServices. Note also that to enable the MultipleEventLoopManager, Athena must be launched with an alternative bootstrap file:

athena.py -p AthenaServices/MultiplePassBootStrap.py myjoboptions.py

It is also possible to use an AlgTool as the filter instead of an algorithm - see the ToyNextPassFilterTool the same location.

---

Major updates:
-- Main.hawkings - 28 Sep 2005, 12 Oct 2005

to top