07 Oct. 2017
<runまわり> 注意 pathは打ち損じの可能性あり
全体config
/opt/eudaq-v17-dev/conf/ITK_oct_2017_ITK_oct_2017_kek_batch1.conf
レファレンス(KEK82)config
/home/testbeam/work/HSIO2/ITKTestbeam_SptOct2017/KEK/KEK82/rceconf/configs/KEK82_primlist_4local__fe0_2572.cfg
FE65-18config
/home/atlasj/work/SPEC/Yarr-eudaq/eudet/config/KEKFE65_18_700e_noisemask.json
<tuningまわり>
♯73(KEKFE65-17 threshold) のconfigがbest!! by中村さん
<yarr_fe65p2_producer うまく走らない問題>
eudaqでconfigをloadしてconfigureする時、yarr_fe65p2_producerのみがエラーを出していた。
以下エラー文#####################
Command Thread exiting due to exception:
Error looking up address 'FHLAIDA':
From eudaq/TransportTCP.cc:543
###############
これは、TranceportTCP.ccの中で
Runcontrolが送ってくるパケット(string)から不要なパラメータをトリミングし、残ったサーバーの名前(この場合はFHLAIDA)からホストのオブジェクトを作ろうとしていて失敗していた。
そこでサーバーのIPを直書きすることでホストを作れるようにして、エラーを回避した。
以下対処法####################
//hostent *host = gethostbyname(“m_server.c_str()”); //もともとあった文。サーバー名からホストが作れない
hostent *host = gethostbyname(“192.168.5.2”); //新しく書いたベタ書き
if(host!){
cout 上のエラー文
}
##########################
この問題はH6Aでは未確認。H6B以外でテストビームを行う際は、この部分をコメントアウトするor書き換える必要がある
(2:20追記)
上の方法でホストが生成されてとりあえずエラー文は出なくなったが、完全にうまくいっているわけではないようで結局eudaq上でspecをうまく動かすことはできなかった。
SPECがビジーを出し続けてしまうバグが残り、ビームが出ててもTrigger数が0のままだった。
#######対処法##########
EnableDUTveto の値を変えて(6→2)FE65のveto信号を無視するようにした。これでTrigger数、Eventbuild数ともに正常に加算されるようになった。
SPECのveto信号はHSIO2に比べて短いため、極端な話なくても問題ないらしい…
(2:30追記)
オンラインモニターを見ようとして、SPECのconverterがないことに気づく
→中村さんがeudat v1.6をインストールしなおしてSPECのconverterを入れてくれた
Corrilationを見る機能はまだない(基本的にH6Aのコードを元にいじれば入れられるはず?)
(3:50追記)
ビームっぽいものが見えた。FE65以外のセンサーが基本的にノイジー(特にKEK82)。(run1761)
ステージを動かしてビームを中心らへんに寄せた(ch0,ch1)=(40,60.5)
(朝シフトへの引き継ぎ事項)
・run1771からビーム中心でのオートマティックrunです
・KEK82はノイジーなのでKEK83,94をnoise scanしてみて良さそうだったら付け替えの検討をお願いします
・~/software/tmp/eudaq-v17dev/の下でオンラインモニターを走らせます
・オンラインモニターでFE65、FEI4、Telescopeのコリレーションが見られるようにして欲しいです(FE65は90度傾いているのでX,Y両方見れるようにお願いします)
・ToT分布もついでに見たいです(中村さん)
・チョコが美味しいです。ぜひどうぞ。(和田さん)
・ちなみにCorrelationはLogスケールだと嬉しいです(中村さん)
・オートランの分のスプレッドシートをお願いします。
・ターミナルをタブにせず散らかしてしまってすいません。キリのいい時にまとめておいてもらえると助かります。
・ポヨポヨでおなじみのtestread.shがstart timeを表示してくれません。きっと文字コードの問題です。
08 Oct. 2017
(7:57) シフト開始、RunControlやproducerたちは頑張って仕事をしている
(8:10)ここまで内山くんに一通り説明
(8:15)run check
→ Single chipのLV1のオフセットはかなり小さい
→ FE65p2 LV1とコリレーションが無いとなんとも言えない
(8:20) 鈴木:Onlinemonの改造、内山:Single chipのチューニング開始→(おわったら)FE65p2のtuning→(おわったら)irradのtuning
(8:40) Online Monitorにfe65のコリレーションを見れるように実装
→ TelescopeとFE65:相関なし
→ FE65とFE-I4:真ん中にまっすぐ線が入っている
最終的にコリレーションを確認(完成版のmake installのし忘れが原因)
(10:00) Lv1を見れるようにコーディングしたが、ここまでずっとFE65のLv1が見れない。
そもそもSPEC PC側が作るLV1分布にも何も入っていない→エンコード側に問題あり?
(10:30) KEK83,KEK94 tune完了→内山くんはFe65p2-17のtuning
両方、noiseを抑えてtuning40Hzくらい。
KEK83 config: 118 KEK94 config:148
control roomのSPEC tyuning用PCが応答しない → Reboot
また、FMC-SCSIの変換基盤が完全に抜け落ち → ネジでSPECに止めました
(朝シフトへの引き継ぎ事項:進捗状況)
・run1771からビーム中心でのオートマティックrunです
→ 現在も安定して動いています(11:30)
・KEK82はノイジーなのでKEK83,94をnoise scanしてみて良さそうだったら付け替えの検討をお願いします
→ 現在チューニングが終了してスタンバイ状態です。ビームが止まった時に付け替えます。 → とりあえずノイズマスクを重ねてみて様子見します。
・オンラインモニターでFE65、FEI4、Telescopeのコリレーションが見られるようにして欲しいです(FE65は90度傾いているのでX,Y両方見れるようにお願いします)
→ 完了しました。
・ToT分布もついでに見たいです(中村さん)
→ 実装は完了しましたが、ToT及び、LV1が何も出てきません。今これに取り組んでいます。
・チョコが美味しいです。ぜひどうぞ。(和田さん)
→ 朝からチョコレートは少し厳しいです
・ちなみにCorrelationはLogスケールだと嬉しいです(中村さん)
→ 取り組み中
・ターミナルをタブにせず散らかしてしまってすいません。キリのいい時にまとめておいてもらえると助かります。
→ Single chipの付け替えと同じタイミングでやります。
・ポヨポヨでおなじみのtestread.shがstart timeを表示してくれません。きっと文字コードの問題です。
→(取り組み中)
(15:00)50V 2M終了、beforeGeoID, fe65を700eにチューニング開始、KEK82の追加マスク、200Vを印加、terminalをtabでまとめた。
→ 新fe65config:KEKFE65-18_700e_noisemask
(15:20)GeoIDインクリメント→2に、Runをstart
(15:24)他チームが1h程度のcontrol access、single chipでNoise scanをすると大量にノイズが出る(検出器全体に)→ thresholdを3000eに再tune
→ 新KEK83config:
(15:37)irradセンサー(KEKFE65-6,10取り出し、あたため開始(tuningするため))
16:00
朝シフトから引き継ぎ完了。
16:48
KEK82を使用していたが、noisyだったので、KEK83を追加。FE65よりも上流側にセット。HVのchは4(300V設定)
KEK83に変更後のconfig → bacth2(
GeoID 2)
17:00
KEK83のtuningを行うがselftriggerでsource-scanを行ったが、noisy(beamあり)
→beamを止めると、tuningができ、source scanできた。
18:38
KEK18がdigital scanができず、応答なし。LVの電源5Vの電源のつけ方が問題。
→1.2V、5.0Vの順にLVをつけることで改善。(beam lineにアクセス)
その後、順調に走り始める。
KEKFE65-18
HV200V 開始。
KEK83は300Vで0.53μA。(KEK82 300V 0.08μA)
20:00
KEK18 LCC noisyであったので、LCCのcolumごとmaskした。
→FE65のconfigfileのColEn/ColSrEnをともに64764(十六進数表記「fcfc」を十進数にしたもの)に変更した。コリレーションは綺麗になった。
09 Oct. 2017
[1:30]
FE65でexttriggerを行った際にLv1,ToTのpdfが出力されるようになった。原因はrun中にデータを一時保存する/tmp/atlasj/tmp_yarr_histo1d_data/などのディレクトリがないのが原因だった。mkdirで解決。
[2:30]
KEKFE65-10のtuning完了。run198のthresholdが最終版。targetの鋭いピークと、targetによってこなかったなだらかなピークがある。一部のピクセルのレジスタが壊れている?
[4:00]
FE65のノイズピクセルをマスクする際、applyMaskのバグを見つける。row=61-64がMask.datの値に関わらずマスクされるようになっていた。原因はバージョンの違いによりマスクファイルの頭の行数が異なっていたから。修正済み。
[5:30]
new config → KEKFE65-18_noisemask_v2_fcfc.json
[8:15](鈴木&内山)
[8:33]
LV1,ToTが見えるようになった
→原因はFillしてなかっただけ
[9:10]
beamがストップ
鈴木 → Reconstruction
内山 → KEKFE65-11をthreshold 2000~3000e目標でtuning開始
[9:30]
Run Summaryの塗りつぶしが変だったので直した
10 Oct. 2017
[8:30]
2枚目のSPECカードをPCにセット。以前のコードを残しておきたいため、新しいディレクトリにgitからSPECのパッケージをインストールしなおした。
[9:30]
2枚のSPECカードはそれぞれ/dev/spec0と/dev/spec1が割り当てられてる。中村さんがscan.shなどを書き直し、どちらのスペックにコマンドを送るかを選択できるようにした。基本的に、今まで使っていたコマンドの一番後ろに0または1を引数としてつければ良い。
2つのターミナルからspec0,spec1に同時にコマンドを送ってスキャンを行い、パソコンがフリーズしないことを確認した。
[12:30]
実際にeudaqにyarrを2つ入れて走らせてみた。
yarr-producerを立ち上げるときは、今までのコマンドの後ろに-i 0 -p 0 のようにつけてspec Numberを指定する。
テレスコープとHSIO2だけだと上手く動くのに、SPECを1枚でも入れるとtrigger数が増えないという問題があったが、これはspec0のアダプターカードにさしているRANケーブルが無理な方向に曲げられてお亡くなりになっているのが原因だった。これを取り替えて2つにしたら正しくeventbuildされるようになった。
オンラインモニターにもFE65p2,FE65p2-2として2枚のFE65が別々に認識されて表示されていた。
[15:30]
先ほどはテキトーなconfigで走ることを確認したが、ちゃんとtuneされたものを使おうとして昨日tuningしたconfigでthresholdscanなどを行った。
SPEC0につないでいるKEKFE65-17(昨日とセットアップ同じ)はtuningがほとんど崩れてなかったが、18(新しいSPECカード、古いアダプターカード)はanalogscanを行った際、とてもノイズが多かった。
その後アダプターカード、SPECカードを交換する試行を行った結果、個体差を持っているのはアダプターカードで絵あることがわかった。
11 Oct.2017
[3:00] KEKFE65-18の再tuning
→ noisemaskv3_fcfc
[3:20]
beam は順調に稼働。
現在溜まっているデータ(200V)は、2,664,727(目標は12M)。
[5:00] 2 spec daqセットアップ
少しつまずいたが、無事完了
DUT Mask=15
fe65p2-2のLV1,ToTがOnlinemonで見えなかったので、修正
コリレーションも確認、LV1はfe65p2-2だけ1にピーク → latencyを228から230に変更
[5:30]
KEK-17のtuning完了(目標値700e)。二つのspecボードの動作を確認後、KEK-17,KEK-18同時測定開始(runnumber 1882)
両センサーともcorrelationを確認。
改善点:
<tuning>
・KEK-18のjson file のうちPrmpCompVompVpbnDac,PrmpVbnFolDacの値を100→50に変更した。
・thresholdsanのrangeを(0,600,10)から(10,1000,10)に変更した。
<EUDaq config>
・KEK-18の情報を加えた。
・他に変更する上で、DutMask 7 → 15にすることに注意(今回、変更前はFE65は4,HSIO2は2,TLUは1の値(LANポート)が割り当てられており、4+2+1=7というように合計値でDutMaskの値は定まっている。新しく加えたFE65の値は5、計15。
[7:58] MD start
H6A にSPEC PCを移動後、起動してもモニターにログイン画面が出てこない
→モニターの設定を変更して対処
######対処法###############################################
1.ログインをする(起動後なら、Enter→password入力→Enterでログインできる)
2.端末を右クリックで開いて、gnome-control-centerを入力してDisplayを選択
3.セカンダリに設定されているモニターをプライマリにし、プライマリに設定されているモニターをオフにする
※設定変更時に画面が暗いときはEnterを押すと反映される(20秒程放置すると変更が破棄される)
#########################################################
12 Oct. 2017
[0:10] MD終了、KEK83 tune, noisemask完了, 300V印加
[0:30] KEKFE65-10 run用config作成
・700e → noisemask v2
・2000e → noisemask
それぞれ400Vで4Mのデータを取得予定
[3:00] 依然、他チームのtuning待ち
[3:30] tuning完了&TLUを動かし始める
[5:00] HSIO2がre-synchronizing errorを大量に吐いている状況。SPEC 1の方が1000Hzくらいで勝手にEventが入ってくる
[5:40] SPEC 1とTLUの間のLANケーブルが刺さっていなかった
[5:40] FE65p2-10のカレントが大幅上昇している 500Vで300uA (1M保護抵抗なので、200Vしかかかっていない)
[5:40] Noise maskをしたかと尋ねると、analogmaskだけとのこと → maskをお願いした。
[6:40] maskはだいたいできた模様だが、Quadがかなりnoisyである。ここで
No beam for NA 30min
今後のplanとして
・Quad以外はmaskできたので、とりあえず、beam scan
・ ビームが当たっていればnoise rateはそれよりも低いはずだが、それでもダメな場合はRunconfigから外す
[9:20] SPEC0,1の不調
SPEC0:analog,digital応答なし
→ KEKFE65-10は諦めて次温めるときに外に出す
SPEC1:勝手にEventbuildされる
→ digital analog tuning後のthresholdは問題なし
[お昼ご飯前]
FE65-17:
RunNo.5018からNoiseMask作成 -> config v5
[14:40]
FE65-17:
RunNo.5026からNoiseMask作成 -> config v6
[17:30]
Beam physicistがビームのパラメータをいじるため2時間程ビームが不安定になるらしい。
"No beam for 2hours"とは書いてあるがほんのたまにスピルが来ている(レートは30Hzくらい)
他チームがアクセスしたいと言ったため、泣く泣くrunを止めた
【これまでの他チームのセンサーまとめ】
・もともとセットアップしたのは、SPEC1、ドルトムントquad、SPEC0、KEKFE83、ジェノバ2枚、バルセロナ2枚、ドルトムントsingle(順番があっているかどうかは要確認)
・ジェノバの1枚目がHVかからず(ワイヤー周りが原因?)、tel3についていたナニカがHVのchが足りないという理由で繋がれていない
・最初に今ある全てのセンサーを入れて走らせた際イベントビルドできなかった
・少しずつセンサーを抜いて原因を調べたところジェノバの2枚目センサー、ドルトムントのquadが原因だった
・quadはtuningし直したら上手く走るようになったが、ジェノバは最終的に3000e以下でtuningできなかったため外された(中村さんがクラウディアを説得!)
・ジェノバセンサーを抜いたらイベントビルドできるようになったがオンラインモニターがたまにクラッシュする問題が発生した
・同様に原因を突き止めたところ、ドルトムントのsingleチップがあるとクラッシュすることがわかった→シングルchipも外された
・現在(13日17:30現在)、SPEC1、ドルトムントquad、KEKFE83、バルセロナ2枚で走っている
・DUT22以降のHSIO2で読み込むconfigが1つずつずれていたことが発覚。これにより、ドルトムントのsingleチップが復活した。
[18:30]
KEKFE65-17で、digital scanは50発帰ってくるがanalog scanで応答が0になる問題が発生
アダプターカードとSCSIケーブルが中途半端に外れているのが原因だった。
[19:30]
ビーム復活。
2スピル300Hz前後の高レートでデータ取得。
13 Oct. 2017
[0:00]
何かに大量のデータが入っているようで1runのデータの区切りが早くなっている。(1run 200kだったものが100k前後に)
[1:30]
event buildされない事態が発生。mimosaがoverflowの状態。
→mimosaの再起動によって回復。1:45データ取得再開。
[morning shift]
FE65-17はrunの度にnoiseが増加.LV1を常に確認しているとnoiseが増えていくのがわかる.correlationも見えなくなってしまう.
night shiftさんから引き継いだ通りnoise maskを施す.->v17が最新(16:00)
9:30頃 よるんさん登場.KEKFE65-10を11に交換する為に温度を上げてもらえることになった.
(ちょうどbeamがなかった&ドルトムントの人たちも交換できるsampleがあった)
<tuning状況>
FE65-11
access時に中に入れ,digital&analog scanができることを確認.(その時の温度は-35度より高かった.-20度程度?)
上に戻ってtuningを始めるとdigitalは返るが,analog scanが通らなくなる.(その時の温度は-35度よりも低い.-35〜-45度程度)
->諦め.
FE65-17
access時にnewFE65-19&20をtestする為に一度外した.
その後digitalは通るが,analogの応答0のpixelが明らかに増加.(bump bondがつながっている領域の半分程度)
->結局HVをかけていなかったことが原因.(長時間HVをかけたセンサーはchargeがどこかに溜まってしまうため,HVをかけていない状態だと挙動がおかしくなる)
->無事解決.
FE65-19&20
access時にSPEC1でtest.
FE65-19(biasレール無): LVショートでscanできず
FE65-20(biasレール有): digital / analog / threshold scan完了-> 90% confidence level で上側2/5程度bump open
biasレールの有無はPCBにペンで書かれていなかったので,FE65-20のscan結果から判断した.
[17:30]
ビームのサイズを調整中。昨晩専門家?が来てBeamprofileを変えていったが、それ以前と同じコンディションに戻そうとしている。(run5216-)
しかし変なBox型を再現できずに2次元ガウシアンのようになっている。
これに伴い、ビームレートは下がった。1スピルなので、今まで100Hz→70Hz程度
バルセロナがビーム形状に満足せずビームをいじり続けているため、run5215-run5225 はデータ取得中にビームコンディションが変わっている。
14 Oct.2017
[5:00] ここまで順調
[5:22] ノイズマスクを作成(v18)→ 逆にnoisyになった
v17に戻したが、今度はイベントが見えなくなった
run controlの再起動、fpga焼き直しを一通り行い、v17のconfigで再開
[7:00]
v17のconfigを使用中、noisyになってもNi crateを立ち上げなおすとnoisyでなくなる現象あり(原因不明)。-> NIcrateではなくrun controll(producer restartの為)? by morning
[morning]
引き継ぎ完了.Johnのproducer restart法は有効.
[9:35]
Johnにv18のmaskがnoisyになった状況を詳しく聞けなかったが,v17でも数個noisyなpixelが見え,correlationが確認できなくなったので,maskを作成(v19) -> noisyになった気配はない
[10:00]
よるんさん(ゆおんさん?)が登場.&中村さんと協議.
お昼頃に一度温度を上げてirrad. sampleを交換できそう.non irrad.は17から20に5min. access程度で交換するか.
[10:30]
FE65-17 @ 25V を2M(本当は1.79M,よるんさんが止めちゃった)まで取り終えたところで1スピルになった.お昼までにさらに2Mためられるか不安...
[11:30]
ポヨポヨsoundが変更される危機を迎えた.中村さんが真剣に"プシュッ"(コーラ缶オープンsound)を探し始める.
[12:00]
中村さんがsound探索に飽きてポヨポヨ続行.
[12:20]
FE65-17 @ 25V はanalogが返って来てなさそう.hitmapがLCC以外まだら.
[12:45]
1M(FE65-17 @ 25Vは3M付近)で止めて一度温める予定に変更.(現時点で0.85M)
温度を上げながらanalogを回して,何度で応答があるか確かめる.(中村さん予想-35度程度)
[13:30]
KEKFE65-11のanalogscanへの応答が-5℃で帰ってきたらしい。->
ZatsuLog1 実際のセンサーの温度はもっと低いと思われる。
【evening shift】
[16:00]
バルセロナのセンサーを傾けたため高さが変わり、FE65とリファレンスのL字の下を5mm底上げする事になった。
[16:30]
冷却開始。KEKFE65-11を10秒ごとにanalogscanするようにし、何度で応答がなくなるかを調べる
while [ 1 ] ; do ./primlist/scan.sh analogscan KEKFE65-11 0 & sleep 15 ; kill -9 ; done と入力すると15秒ごとに自動でanalogscanを行ってくれる。
→-40℃まで耐えた。analogscanでの各ピクセルの応答数が45-55あたりで不安定だが、一応動く。
->
ZatsuLog2
[17:20]
KEKFE65-20のtuningに挑戦した。こちらも各ピクセルの応答数が45-55あたりで不安定。
analogscanが比較的綺麗に帰ってくるパラメータは見つけたが(fe65p2.json_wada20)、Thresholdscanの際バンプついている領域のみフィットに失敗しているので今すぐにデータを取るのは断念。
KEKFE65-20を外して17の25Vのrunを先に取り終えることにした。
誰か時間がある時に20に付け替えてみてtuning挑戦してください。
[19:00]
どっかのセンサーがうっかりLVを切ってしまった&室温じゃないとコンフィグ通せないなどと言うため一度室温に戻す事になった。
KEKFE65-11が一見完璧にtuningできたように見えたのは気付かないうちに温度が上がっていたからだった、残念。
[19:30]
再冷却開始。
またKEKFE65-11のanalogscanを20秒ごとに行う必要がある。
[20:30]
-40℃到達。
KEKFE65-11のtuningに再挑戦。MBじゃない方のdata1355のconfigを元にtuningを行った。
noisescanをすると何回マスクをしてもnoLCCエリアのノイズが次々と出てくるのでCol Maskを64764(fcfc)にした。
[21:00]
他のチームのtuningを待つ間にKEKFE65-11を動かしておきたかったので(
注:KEKFE65-11はしばらく放っておくと応答が返ってこなくなる可能性があるのでなんらかのscanを定期的に行おう)
すでにtuning済みのconfigに対してthresholdscanを行ったところ、早速fitに失敗するピクセルが発生していた。
まだセンサーなどの温度が-40℃になっていない可能性がある。
しかし、今tuningし直してもまたすぐに崩れる可能性が高いため、全チームのtuningが一通り終わったところでRunControlを走らせる事にした。
しばらく時間が経って温度が安定したら再度tuningをする必要があると思う。
[21:15]
KEKFE65-11はバンプの有無関係なく、全ピクセルに1-3ヒットづつ入るタイプのノイズが発生している。
KEKFE65-17はノイズが少なくコリレーションも綺麗に見えている。またrefとの相対位置が動いた。FE65の中心が(25,150)→(12,200)くらいになった。
KEK83のhitmapを見ると少しビームから外れているかもしれない。
[22:30]
HSIO2とミモザの間にコリレーションが見えなくなる問題が発生。HSIO2とFE65の間も見えなくなっていた。
バルセロナのセンサーがノイジーすぎてイベントずれが発生したのが原因だった。マスクしてもらい対処。
[22:50]
バルセロナは傾けて高さが変わった分勝手にボックスを7mm下げていたらしい。許すまじ。
これに抗議したところボックスを2mm上に動かしてもらえた。(残り5mmはFE65を底上げした分)FE65にビームがしっかり当たるようになった。
[23:20]
鈴木くんがKEKFE65-11の上半分を全てマスクしてくれた。
LV1分布が見やすくなり、コリレーションも見えるようになった。(run5398)
/home/atlasj/work/SPEC/Yarr-eudaqMB/src/scripts/mkcolrowmask/mkNoiseMask.sh ←任意の長方形型にマスクしてくれるスクリプト
[23:50]
みんながGatewayPCにアクセスしてオンラインモニターを起動すると重くなることがわかった。
シフトの人は毎runごとにシフト席or sshでオンラインモニターを確認しよう。シフトでない人は極力オンラインモニターを使わないようにしよう。
15 Oct. 2017
[0:15]
シンチレータ0のカウントが少なくなった。
イベントビルドの進みがかなり遅い。
andMaskを4に変更。
シンチレータ0を戻したところ、元に戻った。(原因不明)
[4:00]
KEKFE65-17 25Vのrun終了。short time acess to change non irradiated module
ビームラインで動作確認、analog汚め(カラフル)→ HVかけたらいつもの感じに(バンプ部が0)
[5:00]
KEKFE65-18のキャリブレーション完了。HV200でデータを取り始める。(Bでは2.8Mのデータをすでにとっている)
[night]
run5423でFE65-17から18に取り替えた.その間FE65-11の様子を見れていなかったが,noisyでcorrelationが見れていなかった.
そのことにrun5430で気付き,run control restart.無事解決 -> run5424-5430はFE65-11のevent数には数えない!
SPEC0とSPEC1がdata上でIDされていなかった事件については鈴木さんのlog待ち.
[morning]
引き継ぎ.
FE65-18のrunが終わり次第(明日の朝予定),温めてbox内にSPEC1も収納し,irrad.2枚同時test予定.
[11:20]
OnlineMonitorに"Error Section invalid: 5 1585 2046"的なerrorが出ていたが,telescope restartで解決.
telescopeがcurrent limitに達して5V程度しかかかっていなかった.
[12:00]
run♯5463-5464 は前のversion(v3)で走っていた.先程のゴタゴタでversionを戻しすぎた人がいたと思われる.-> run♯5465からv4に戻した.
[12:35]
FE65-18&11が2枚ともnoisyになりcorrelation見えなくなる.(run♯5465) -> FPGA焼き直しでもだめ -> LV off onで解決
[15:40]
ここまで順調.
boosterの不調でbeamは17:30まで止まる予定.-> 17:00頃beam back
最新config -> FE65-11 v6, FE65-18 v4
[evening]
[18:40]
FE65-18 200Vを5.5M、FE65-11 400Vを7.1Mデータ取得
FE65-11のhigh threshold tuningが間に合わなかったためexcludeして、FE65-18 @ 100Vのデータ取得開始
[20:30]
MIMOSA26 2とKEK83とのcorrelationが見えなくなった(run#5497)
->HSIO2をrebootしてrestartで解消
[21:25]
FE65-11のhigh threshold tuningを中断し、low threshold @ 600Vのデータ取得開始
16 Oct. 2017
[3:00]
KEKFE65-18のHVを100→50に変更。データ取得開始。HV変更による問題は特になし。
[3:30~5:00]
beam stop 30分×2
[5:00]
KEKFE65-11 600V データ量は3.5M
[6:40]
KEKFE65-11 600V 4.4M(run number 5538時点)
[6:50]
KEKFE65-18のHVを50→25に変更。データ取得開始。HV変更による問題は特になし。
[8:00]
冷却Boxを室温に戻し始めた。
その間にKEKFE65-20のtuningに挑戦するためSPEC1につけるセンサーを18から取り替えた。
[8:30]
KEKFE65-18のデータを取っている間にbeforeGeoIDのrunがされていないことに気がついたのであたためている間に実施した。
KEKFE65-11も同様にbeforeGeoIDのrunがされてなさそうだが、温度が変わっていたため諦めた。
シフトの人はビームが止まっているのを見かけたらKEKFE65-11のbeforeGeoIDを取ってください。(600V,400V,それぞれデータ取得時のconfigを再現して)
[9:00]
H6Bにflex2枚とKEK94のセットアップを行った。
しかし、ソースメータのchが足りなかったため、KEKFE94にLVをかけることができなかった。
レファレンスを使わずにデータを取得する。
[11:00]
H6Aのセットアップを終えて冷却を開始した。
中に入っているセンサーはドルトムントquad、SPEC0、KEK83、SPEC1、ジェノバのMD疑惑の何か、ドルトムントの2枚目、ドルトムントの3枚目(?)。
SPEC0にはKEKFE65-11、SPEC1にはKEKFE65-12が繋がっている。
冷やす間2つのセンサーでanalogscanを撮り続け、応答が途切れないことを確認した。
[12:00]
w田さんがH6Bのアクセスキーをコンクリの隙間に落とす事件発生。
中村さんが車メンテナンス用のピックアップツールを持ってきて無事回収した。
[14:00]
11,12の-30℃でのhign threshold tuningに挑戦していた。
11は3000eでtuningできたが、12は2500eでしかtuningできていない。
途中でうっかりscan中のSPECにFPGAを焼くコマンドを送ってしまいSPEC PCがハングした。これ以降SPEC1でうまくthresholdscanが行えなくなったため、試験的に作った2500eの方でデータ取得を開始することにした。
[14:30]
11,12を入れてデータ取得を開始した。使ったconfigは、
11:KEKFE65-11_3000e_noisemask.json (Threshold分布はMBじゃない方のdata/data001530…)
12:KEKFE65-12_2500e_noisemask.json (Threshold分布はMBのdata1/data000563…)
コリレーションも確認できた。
[15:00]
H6BでFlex2枚に50Vをかけることができたと思ったので、データ取得を開始した。コリレーションが確認できた。
[16:00]
No beam for NA
from Tue 8:00 to Wed 18:00
らしい。Run planを見直す必要性を感じる。
[17:00]
H6BのFlexにHVがかかっていなかったことが発覚。(LEMOとセンサー間が外れた状態で50Vかけてた)
これを直したらイベント数が増えた。
[17:50]
<H6B>
ビームが来たときrce offline producerに大量にBad TLU idが吐かれる問題(23:20現在、原因不明)
run controlの全体config:batch4
th2500eのNoise mask適用config->key:1026
th3000eのNoise mask適用config->key:1019
HSIO2が大分不安定
[18:50]
<H6B>
MIMOSAとのcorrelationが見えなくなる問題(flex同士のcorrelationは見えていた)、Bad TLU idと関連性がありそう
->TLUとHSIO2を繋いでるLANケーブルを交換->解消されず
交換時にKEK122とKEK123が逆にHSIO2と繋がっていたことが発覚->取り替えずに続行(DUT21がKEK122、DUT20がKEK123)
KEK122のconfigはKEK123、KEK123のconfigはKEK122
DUT20:KEK122(林栄No.3)上流側
DUT21:KEK123(林栄No.2)下流側
[19:20]
<H6B>
TLUを再起動->Bad TLU id問題解消されず
[19:45]
<H6B>
MIMOSAのconfigをthreshold6から8に変更->MIMOSAとのcorrelation問題解消(MIMOSAがnoisyだった所為だった)
-> Bad TLU id問題は依然として解消されず
[23:20]
<H6B>
run#2003が途中からEvents buildされていなかった->restartで解消されたが、calibserverがビームが来る毎にResynchronizingを吐く&online monitorがEvent not validを大量に吐く
calibserverを立ち上げ直してrestart->あまり解消されず...
17 Oct. 2017
[3:00]
<H6B>
1runごとに400MBまでデータを取るとクラッシュする。(stopが利かず、calibserverまで落ちてしまう)
usefulscripts(ぽよぽよ)にはeventは表示され、rawデータも保存されている。
[4:56]
<H6A>
極めて順調。2:17頃からdouble spillに戻り、~200Hz。現在5.2M取得(6Mまで取得予定)
終了予定時刻は6:00前
[6:00]
beamを絞る。runを回したところ、beamの形を確認。130Hz.
KEKFE65-11,12のbeforeGeoIDを回したところ、どちらもdigital,analogは返ってくるが、thresholdの形は崩れていた。
キャリブレーションし直す余裕はないので、そのままrunを回した。
HVはbeamを絞る前のものを維持。FE65のcorrelationはどちらも見えている。
絞ったbeamは真ん中に当たっている。
[8:00]
<H6A>
beam stop
KEKFE65-11,12のbeforeGeoIDを回したところ、どちらもdigital analogは返ってくるが、thresholdの形は崩れている。
解析するときはtuning時のthreshold分布を参照するしかなさそう。
11:KEKFE65-11_3000e_noisemask.json (Threshold分布はMBじゃない方のdata/data001530…)
12:KEKFE65-12_2500e_noisemask.json (Threshold分布はMBのdata1/data000563…)
Run config -> /home/sjunki/Data/Data/CERN/ITK_Oct_2017にコピーしました
23 Oct. 2017
[11:00]
New Flex KEK125(double)が届く。
HSIO2(atlassi02.cern.ch)で動作チェックを開始。
digital scan(Run Number:201),analog scan(Run Number:202)はともに良好。
Run Number |
|
VthinAltCoarse |
VthinAltFine |
threshold |
#0 |
comment |
203 |
RJ1 |
1 |
40 |
4162 |
2700 |
RJ2の方は良好。RJ1はつぶれた。 |
RJ2 |
1 |
80 |
3505 |
110 |
205 |
RJ1 |
0 |
250 |
3748 |
450 |
|
RJ2 |
1 |
40 |
4528 |
14000 |
206 |
RJ1 |
0 |
200 |
4481 |
10000 |
|
RJ2 |
0 |
250 |
4008 |
1300 |
207 |
RJ1 |
0 |
250 |
4302 |
5000 |
|
RJ2 |
1 |
80 |
4527 |
14000 |
210 |
RJ1 |
0 |
250 |
4324 |
5600 |
|
RJ2 |
1 |
80 |
4539 |
14000 |
211 |
RJ1 |
1 |
40 |
3603 |
250 |
12:00現在で一番よいglobal tuneか local(key:227)の結果はよくなかった |
RJ2 |
1 |
40 |
3553 |
150 |
262 |
RJ1 |
0 |
61 |
3807 |
600 |
GDAC_TUNEを回して最適と思われるcoarse、fine値を探索 RJ2はfitに失敗している→GDACでの値は最適では無い? |
RJ2 |
1 |
61 |
(-3216) |
25000 over |
263 |
RJ1 |
0 |
51 |
3451 |
180 |
RJ2のピークがつぶれてしまっている |
RJ2 |
1 |
40 |
2055 |
25000 over |
264 |
RJ1 |
0 |
35 |
1042 |
5200 |
Fine値を下げすぎた模様 |
RJ2 |
0 |
100 |
495.2 |
25000 over |
265 |
RJ1 |
0 |
45 |
4246 |
4000 |
まだFine値が低い RJ2の0の数が減らない |
RJ2 |
0 |
250 |
1625 |
25000 over |
266 |
RJ1 |
0 |
50 |
200台 |
|
RJ2を一旦excludeしてRJ1の適性Vthinを探索 |
RJ2 |
excluded |
267 |
RJ1 |
0 |
51 |
|
|
Run Number 263と同じ値にしたが再現性が確認できず |
RJ2 |
excluded |
268 |
RJ1 |
0 |
61 |
4208 |
3500 |
Run Number 262と同設定 今度はRJ2のピークが立った |
RJ2 |
1 |
61 |
3667 |
210 |
285 |
RJ1 |
excluded |
RJ2のみ再度globalを回してlocalonly(key:298) |
RJ2 |
1 |
61 |
3768 |
500 |
298(key) |
RJ1 |
excluded |
inlink:1、outlink:1にしたところtime outしたので両方0にして回した |
RJ2 |
|
|
2409 |
|
303 |
RJ1 |
1 |
61 |
3772 |
500 |
RJ1とRJ2のadressを入れ替え |
RJ2 |
1 |
61 |
3633 |
150 |
305 |
RJ1 |
1 |
40 |
3462 |
150 |
|
RJ2 |
1 |
40 |
3318 |
50 |
306 |
RJ1 |
0 |
250 |
4251 |
4000 |
Vthin下げすぎ |
RJ2 |
0 |
250 |
4257 |
4000 |
309 |
RJ1 |
0 |
143 |
2395 |
30 |
GDAC_COARSE_FAST_TUNE(Run Number:307)とGDAC_FAST_TUNE(Run Number:308)で適性Vthinを探して設定 |
RJ2 |
0 |
142 |
2405 |
40 |
322(key) |
RJ1 |
|
|
2383 |
|
tuning完了 |
RJ2 |
|
|
2388 |
|
24 Oct. 2017
Comments
--
Atlasj Silicon - 2017-10-16