= Timing Scan =
'''~+【概要】+~''' <
>
Pixel Timing Scanの流れ (2019.4) <
>
そのとき詰まったところ (TimingScanMemo)
概要(2018)はこのスライドに書いてある([[attachment:timingTask.pdf|スライド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に関しての説明はこのスライドに書いてある([[attachment:RawDataAnalysis.pdf|スライド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]])を見たりして書き込む。<
>
{{attachment:eLog.png||width=300}}<
>
図1. eLogの例
SCAN_RANGEとSCAN_STEPはTTCrxScan(タイミングスキャンのコマンド)の引数からわかる<
>
SCAN_RANGEは--startValと --stopValまで。SCAN_STEPはstepSizeをいれる。READOUT_WINDOWはだいたい3。<
>
適宜確認して、データが壊れてるLBとかは除く。<
>
'''例'''
|| SCAN_RANGE || -10 20 ||
||READOUT_WINDOW || 3 ||
||SCAN_STEP|| 1.0 ||
データは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しているかはわかるはず。<
>