Timing Scan

【概要】
Pixel Timing Scanの流れ (2019.4)
そのとき詰まったところ (TimingScanMemo) 概要(2018)はこのスライドに書いてある(スライドpdf)

Cosmic Analysis

ビームが出る前に検出器だけ動かしてテストをする期間がある。Mile Stone Runと呼ばれる。
この間に宇宙線によるおおまかなタイミングの解析をする。
いつMilestone runが行われるかをATLAS run meetingなどで把握しておく。

Raw Dataのデコード

RawデータをReco.pyでreconstructionして、DAOD_IDTRKVALIDを作る。
batch jobを投げる。
submitする内容はbsubReco.shで、まずmakesub.shでsubファイルをつくる。subファイルはこんな感じ(00344612test.sub)にする。

$condor_submit 00344612test.sub

で実行。アウトプットディレクトリに
data18_cos.00344612.physics_CosmicMuons.merge.DAOD_IDTRKVALID.lb0545.SFO-1.0001.root
という名前のrootファイルが入ったディレクトリができる。

(以下2021.4訂正)
まず

./makesub.sh xxx

を行う。(xxxはrun number)
次に、makesubでできたbatch jobのスクリプトを実行する。現在いるディレクトリにlog/ディレクトリが生成される。
Reco_tf.pyでreconstructionする際に、引数としていくつかoptionを加えている。スクリプトbsubRAWtoAOD.shに書いてある。
このうち、

--AMITag 'x598' \
--conditionsTag all:CONDBR2-ES1PA-2018-05 \
--geometryVersion all:ATLAS-R2-2016-01-00-01 \
--preExec  'all:rec.doExpressProcessing.set_Value_and_Lock(True); rec.doTrigger=False; from RecExConfig.RecFlags import rec; from InDetRecExample.InDetJobProperties import InDetFlags; InDetFlags.useDynamicAlignFolders.set_Value_and_Lock(True);' \

の部分は、

~% localSetupPyAMI
~% voms-proxy-init -voms atlas -hours 240

~% GetTfCommand.py --AMI xxxx

で、xxxxのところに、持ってきたcosmic ray fileの x-tag を入れる。
GetTfCommand.py で出てきたものが、実際に使われたコマンドになので、それをfull copyする。
上記のコマンドは、一例としてrun#384813のコマンド。

Raw DataからNTupleをつくる

https://gitlab.cern.ch/atlas-pixel/PixelTimingをCloneする。
このなかのCosmicAnaに移動して、 README.mdに書いてある操作を行う。初めてcloneしたときは

$cd CosmicAna
$cd build
$source setup_initial.sh

CosmicAna/source/MyTrackAnalysis/util/runPixelClusterAnalysis.cxxの中のデータセット名を先ほどつくったDAOD_IDTRKVALIDに変える。
buildディレクトリで

$make
$cd ../
$mkdir run
$cd run
$runPixelClusterAnalysis ana-DATE

ana-2019.04.09_23.12.38などといった名前のディレクトリがrun以下にできる。この中のdata-MyTrackAnalysis下にある
run numberの名前のついたroot fileから、プロットをつくる。
・layerごとのEtaModulevsPhiModule
・BECvslayer
・layerごとのL1A
・各moduleごとのL1Aの平均。logscaleでみると見やすい。
EtaModulevsPhiModuleをみてnoizyなモジュールがあったらCorevsColumeをみてNoizyなピクセルがないかチェックする。
Noizyなピクセルがいればそれを除いてL1Aの平均の分布をつくる。moduleとかFrontEndがnoizyな感じだったらそこだけ除くようにする。
L1Aの分布をみて、もし想定値からすごく離れていたらピクセルのrun cordinatorとかと相談してROD/BOC近辺にdelayを入れるなどする。

Timing Scan

ビームの出始めにtiming scanが行われる。これもまたピクセルのrun cordinatorとコンタクトをとる、ミーティングをチェックするなどしておく。
データは急いで解析する。

Raw dataのskimmingとデコード/NTuple作成

https://gitlab.cern.ch/atlas-pixel/RawDataAnalysisをcloneする。RawDataAnalysisに関しての説明はこのスライドに書いてある(スライドpdf)
そのままだと動かないかもしれないので適宜変更(TimingScanMemo参照)

$source setup.sh
$make
$cd batch

でsubmitするファイルはbsub_pixel_timing.shで、makes.shでsubmitするファイルをつくる。こんなの(00348197test.sub)
このbsub_pixel_timing.shの本体は同じくbatchディレクトリ下にあるdownload_skim.shと、あとNTupleをつくるmacroになっている。
download_skimの中のデータを取ってくるディレクトリとbsub_pixel_timing.shの中のアウトプットディレクトリとかは適宜変更。

condor_submit 00348197test.sub

で実行
そうするとoutput directoryに指定したディレクトリにXXX.out.rootとXXX.hist.rootというファイルができる。
XXX.hist.rootは各LBごとにつくられ、中身は各moduleごとのL1AとToTの2Dヒストグラムである(treeの中のTimingChargeという名前のヒストグラム)。
16進数の数字はモジュールそれぞれを指している。LBとrelative delayは1対1対応しているはず。

NTupleからintime-efficiencyのプロットを作成

Cosmic Analysisのときにcloneしたhttps://gitlab.cern.ch/atlas-pixel/PixelTimingを用いる。
TimingScanAnaディレクトリに移動
まずTimingScanAna/data/scanConfigPix.txtを編集する。
#Output Fileはrun number を含んだ形に変える #Scan Configurationは人に聞いたりeLog(https://atlpix01.cern.ch/elog/Detector/page1)を見たりして書き込む。

• 
  

  • 図1. eLogの例

SCAN_RANGEとSCAN_STEPはTTCrxScan(タイミングスキャンのコマンド)の引数からわかる
SCAN_RANGEは--startValと --stopValまで。SCAN_STEPはstepSizeをいれる。READOUT_WINDOWはだいたい3。
適宜確認して、データが壊れてるLBとかは除く。
例

データはXXX.hist.rootというデータをpathごと書く。その隣の数字は--startValからstepSizeおきにかく。

$source setup.sh
$ ./bin/TimingScanAnaPix data/scanConfigPix.txt

timingScanAnaPix348197.rootとかいうrootファイルが出来上がる。これでタイミングがあってるかざっくり確認する。
このrootファイルはモジュールごとの各L1Aのefficiencyを含む。各L1Aのefficiencyを足すと1になるはずである。
これと、先ほど作成したXXX.hist.rootのL1AVSToTの図を見比べてだいたい正しくデコードできているかチェックする。

macroでヒストグラムを加工

タイミングの状態がわかりやすいようなグラフをつくる。

$cd PixelTiming/TimingScanAna/macros/makePlot
$root -l -q -b 'drawHistPix.cxx("../../timingScanAnaPix348197.root","../../data/scanConfigPix.txt","348197")'

できたヒストグラムをチェックする。
(1)binningが適切そうか
(2)efficiencyが低いmoduleの、moduleごとのoffset vs in-time efficiencyのグラフをみる
この場合efficiencyが低い(<0.99)moduleの名前を知りたい時は、/macros/makePlot下のdrawHistPix.cxx(IBLの場合はdrawHistIBL.cxx)の中で出力する。

if(pIdealFitFunc->Eval(0.0)<0.99) std::cout << pIdealFitFunc->Eval(0.0) 
<< "-----------------------module ID  = " << pMod->GetDcsGeographicalID() << std::endl;

のようにして出力する。か、drawHistPix実行後にできるmodEffPix.txtのefficiencyから出す。
efficiencyの低いmoduleをチェックして、特定のLBが原因でfittingができていないとかならそのLBは除く。

新しいdelayを反映する

Timing Scanを行ったあとに、
(1)各モジュールごとの結果から反映させるべき新しいdelayを決定する
(1-1) timing scanから、いまずれている分のdelay [ns] を求める

この、いまずれている分のdelay[ns]というのは具体的には、drawHistPixで出したfitPixのプロットのoffset[ns]が、設定したoffsetの値(2018年現在は5ns)から どれだけずれているか。
fitPixのプロットのoffsetが設定した5nsになるようにdelayを調節する。drawHistPixを実行するとmodEffPix.txtというテキストファイルが作られる。
そこに各モジュールのefficiencyとoffset (Relative delayとか書いてあるけど、その表現は語弊があるのでoffsetに読み替える)がdumpされるので、そのファイルを使えばいい。
たとえば、timing scanでとあるモジュールのoffsetが7.5 nsだとわかったら、それを5 nsに直すためには+2.5 nsのdelayを入れる。 このとき符号に注意。-じゃなくて+。

(1-2) 今まで入っていたdelayのregisterをnsに直す (e.g. coarse: 2, fine: 5 というregister valueだったとき -> 6.95 nsのdelay値)
(1-3) 新しくapplyすべきdelayの値をnsで計算: (1-2で求めた今まで入ってたdelay) ± (1-1で求めたいまずれている分のdelay)
(2)それをBOC Txのfine/coarse delayに直す
(3)新しいBOC Txのfine/coarse delayを書いたテキストなどを作る

で、多分Pixelのrun coordinator?か誰かに送る。

Timing MC

Timing MCに入れるためのデータを出すNTupleは、RawDataAnalysisで作成したXXX_pixel.hist.rootの、
relative delayが0nsのところのLBのものを使用してつくる。makeNTuple.cxxでどうやってデータをdumpしているかはわかるはず。