INTT 日本グループ学会発表練習会

Asia/Tokyo
    • 10:30 12:00
      発表練習 1h 30m
      Speaker: Takahiro Kikuchi (Rikkyo university)

      発表練習

      8 分 20 秒かかった

      コメント

      全体

      • 「〜された」は能動的に「〜した」と言う
      • 文字が多い
      • 補正がたくさんで、付いていくのが大変。補正全体をレビューするページは?
      • 補正の話をたくさんしてるけど、補正した最終結果はないのね?
      • ページ送りが早い。不要なページは削る

      タイトル

      • 名前を大きく書く
      • 日付を名前の行に書かない
      • 学会の名前を書く(日本物理学会 2025 年春季大会?)
      • 立教のロゴ
      • 講演番号も書く

      P2

      • 「実験について」:不要
      • sPHENIX の図: MBD 入のものに変更
      • 発表概要→研究概要
      • 貯蔵リング→蓄積リング

      P3

      • 断面積→(minimum-bias)トリガー断面積
      • 1 行目不要
      • Vernir scan で minimum-bias トリガー断面積を決定する
      • 箇条書きの高さを揃える
      • (Peripheral での) Centrality の絶対値を決めるという話はこのページに入れる。
        • 「Peripheral での centrality や Npart, Ncoll の決定に重要である」と書く

      P4 目次

      • スライドの順番を変える。目次も合わせて変更

      P5

      • 削除

      P6

      • 計数→計数レート
      • 字が多い

      P7

      • 手順項目を数字の箇条書きに変える
      • 粒子集団の情報→ビームバンチのプロファイル (σx, σy)
      • つながる→(なし)
      • 余白を活用
      • 図が見づらい。矢印が多い。ビーム軸は実線、スキャンの線は点線のほうがいいかも。アニメーションにするものあり。時間があればやってみよう。

      P8

      • 文は手短に
      • N1, N2 の数字はどうやって得るのか?パラメータの数字をそれぞれどう得るのか書いておきたい。
        • RHIC では Nbunch = 111, frev = 78.4 kHz

      P9

      • L = ... の式の分母は σVx, σVy のバージョンだけを書いちゃう。
      • 図の軸が左右の図で異なるのでややこしい。CW の絵をもらってきても良い。
      • kbunch ってどうなの?Nbunch のほうが良さそう。

      P10

      • sPHENIX MBD は PHENIX BBC を再利用したもの

      P11

      • P8 (変更後のスライド番号)にくっつける

      P12

      • 削除

      P13

      • 図が小さい。字を小さくして置くとか、工夫する
      • 図に x,y の区別がつくように書き込み
      • 図を中心にそれぞれの説明を下に書くようレイアウトを変更
      • 補正の話のあとに持っていく

      P14

      • 補正の話のあとに持っていく
      • 変数の書き方を統一
      • PHENIX 実験と PHENIX experiment が混在
      • PHENIX の話は
      • グラウバーモデルとの比較(sPHENIX からまだ公表されていないので、具体的なことは言わず、ざっくりと定性的な言及に留める)

      P15 各種補正の説明 1/5

      • これ以降で説明する補正の項目を箇条書きで見せる。用語を統一
        • Nparticle なのか粒子数の減少なのか
      • hourglass 効果の補正も書いておく
      • Pileup の話は図のキャプション的な配置にする
      • タイトル変更:補正の概要

      P16

      • タイトル変更:ビーム減衰の補正
      • 菊池:Emittance と ルミノシティの具体的な関係式って何?
        • ルミノシティの式にある σ の項って (σx12x22)(σy12y22) であってる?アンジェリカの emittance の式では σx1σx2σy1σy22 で全部掛け算になっている。
          • σ で書くなら足し算で OK。Emittance で書くなら掛け算になるかも。
      • 測定のタイミングが悪く→測定中の emittance の増加
      • 箇条書きの文字が小さい
      • 結果の数字を書き込む:5% ほど

      P17

      • タイトル変更:Event pileup 補正
      • 文字を減らす
      • 下 4 つの図がまぎらわしい。図ごとに説明のキャプションがほしい
      • 「Pileup はコインシデンスレートと S/N の single hit rate から見積もる」と言う

      P18

      • Event pileup への beam background の影響
      • これは未解決であることを明記する
      • 最終結果のあとに、課題として示す

      P19(まとめ・展望)

      • PHENIX/sPHENIX (RHIC IP-8) で初の金・金 vernier scan
      • グラウバーモデルとの比較(sPHENIX からまだ公表されていないので、具体的なことは言わず、ざっくりと定性的な言及に留める)

       

      想定質問

      • (中川)sPHENIX 金・金測定にはこの解析からくる 2% の誤差がつくの?
        • (菊池)本測定 2025 ではビームがチューニングされるのでよくなるはず
        • (秋葉)重要なのは centrality. 断面積の絶対値が重要になるのはほとんどない。高 Centrality (peripheral) を決めるときどう聞いてくるかが大事。周辺衝突のとき MBD の検出効率は下がる。PHENIX 時代は全 centrality で 93% だった。PHENIX 時代より測定断面積が大きいのはちょっと変。
      • (糠塚)断面積 7.1 barn の値が出て、補正の話をたくさんしているけど、最終結果はなに?
        • (菊池)7.1 barn が最終結果。
          • (秋葉)加えた補正は最終結果の前にあるべき。
    • 15:30 17:00
      発表練習 1h 30m
      Speaker: Ryota Shishikra (Rikkyo university(for the sPHENIX-INTT collaboration))

      メモ

      スライドが仕上がっていないので、できたとこまで本番形式。それ以降はスライドを見て構成を確認。

      全体的なコメント

      • 加藤くんの発表をあてにして、研究背景を簡単に済ませよう。sPHENIX 全体の話を?
      • ページ番号がないページもある
      • 最終プロットを決める。これに向けて必要なものを揃えていけば良い。
      • スライドごとにそのページの結論をかけると良い

      ページごと

      • aaa
      •  

      P1 表紙

      • aaa
      •  

      P2 研究背景

      • aaa
      •  

      P3 研究背景(飛跡検出器)

      • aaa
      •  

      P4 INTT

      • aaa
      •  

      P5 研究内容

      • aaa
      •  

      P6, 7 先行研究

      • 簡潔に述べれば十分
      • バックアップに移動。検出効率 99% と述べるだけ

      P8 目的

      • 目的の文言がちょっと変
      • これは残す

      P9 アルゴリズム

      • aaa
      •  

      P10 シミュレーション

      • ここまでは仕上がっている。7 分かかった
      • Geant4 は業界標準なので簡潔に。イベント生成はちゃんと喋りたい。
      •  

      P11 以降

      Single μ MC, 一方向

      • イベントディスプレイを 2 通り見せる
      • ビーム方向を示す線を足す
      • 青線の意味を示す(reconstructed track)
      • INTT の内側に物質があることを示しておきたい

      Single μ MC, η, θ方向色々、vertex 位置いろいろ

      AuAu MC

      • 「Dead ch あり」と書き込む
      • Hijing を使ったと書く(重イオン業界標準のイベント生成)

      AuAu 実データ

      • MC, RD の residual 分布を重ね書きしたい
      •  

      まとめ

      •  

       

      想定質問

      • 衝突点はどうやって見つける?INTT 自身ならバイアスがかかるのでは?見つからないときは?
      •  

       

    • 17:30 19:00
      発表練習 1h 30m
      Speaker: Mai Kano

      メモ

      全体的なコメント

      • aaa
      • 2 種類の BCO があることに触れていない・・・
        • みかんばこの比喩で、前回の学会ではみかん箱に別の果物が入っている例を見せていた。今回は省略した。
      • 処理時間のスケールをどこかで話してほしい。ストリーミングデータのタイミングチャートで、120 クロック = 12 μs とか書く?

      ページごと

      • aaa
      •  

      P1 表紙

      • aaa

      P2 研究背景 (RHIC)

      • aaa

      P3 研究背景 (INTT)

      • aaa

      P4 研究目的

      • 記述が矛盾している
        • 基本的には設計通りに動作している、1% ほどミックスアップが起こっている
      •  

      P4, 5,  トリガー データ読み出し

      •  
      •  

      P6 トリガー読み出し

      • aaa
      •  

      P7, 8 ストリーミングデータ読み出し

      • aaa
      •  

      P9 ストリーミングモード

      • aaa
      •  

      P10 イベントミックスアップ

      • aaa
      •  

      P13 ヒット数依存

      ページ番号飛んでしまった

      • aaa
      •  

      P14 ヒット数依存 2024 金金データ

      • aaa
      •  

      P15 衝突事象の間隔依存 2024 金金データ

      • ここに来たとこで 8 分経過
      •  

      P16 現象発生イベントの割合

      • Preliminary の話はしない
      • BG 除去の話はしない。新しく作ったプロットの話をしっかりしよう
      • BG 除去は BCO diff プロットで、ピークの下にあるアクシデンタルを差っ引いたという話

      P17 現象発生イベントの割合と衝突レート

      • ここで 10 分経過
      • Preliminary の話はしない
      • BG 除去の話はしない。新しく作ったプロットの話をしっかりしよう

      P18, 19, 20, 21 ストリーミングにおけるイベントミックスアップ

      • 平行四辺形
      •  

      P22 ストリーミングにおけるイベントミックスアップの解説

      •  
      • aaa
      •  

      P23 イベントミックスアップのバンチ番号ごとのヒット

      • aaa
      •  

      P24 まとめ

      • 時間オーバーのときは読まない
      • このトークで重要なポイントはデータ処理時間への依存性。ここをわかりやすく書きたい。
      • 問題は FELIX 内で起こっている。データを送るとこは問題なし。

      想定質問

      Q. ストリーミングだとイベントミックスアップは避けられないの?

      A. サーバーでのデータ処理の問題(加納さん)

      中川さん: INTTのデータ処理のやり方が特殊ゆえ 途中でのBITの付け加えが引き起こす問題?

      想定以上のレートでデータが来れば起こる現象。

      FPHX チップの BCO カウンターが 1 周したことを判別できるようになる必要がある。

      Q. ミックスアップ問題は解決したの?

      ハードでの対応と、オフライン解析(加納トークでは触れないが)でミックスアップ問題は解決できるはず・・・

      おおよそ原因は理解したはず・・・?

      dN/dη の人たちの話と整合性が取れていないことが気になる

      解決したこと、解決していないことが明確にわかるようにしてくれると嬉しい

    • 13:00 14:00
      発表練習 1h
      Speaker: Tomoya Kato (Rikkyo)

      メモ

      13:08 かかった

      全体的なコメント

      • ページ送りが早くて話についていけなかった
      • 分量を減らす。

      ページごと

      P1 表紙

      • 学会用に変更
        • 学籍番号・指導教員名は不要
        • 共著者を載せる。学会に申請した順番で載せる。
        • それぞれの所属も載せる。

      P2

      P3 sPHENIX

      • 喋る時間を大幅に削る

      P4 sPHENIX 検出器

      • 多少の説明

      P5 INTT のシリコンラダー

      P6 

      P7 INTT のセル

      P8 クラスタリング手法

      P9 

      P11 Large z cluster

      P14 Cluster z size 分布

      P24 シミュレーションとの比較

      • ページ番号が飛んでいる
      • 「提供者」って変

      P25 Large z cluster の正体

      P26 ヒットマップ

      • ここで 8 分経過

      P27 ヒットマップ

      P28 Large z cluster の正体

      P29 ヒットマップが示す傾向

      • ページ送り早い

      P30 ヒットマップが示す傾向

      • ここを丁寧に説明する

      P31 vtx z

      P34 MBD について

      • 説明はバックアップに

      P36 衝突点 z 座標依存性

      • ここで 10 分経過

      P38 Cluster z size の多重度依存性

      P39 Cluster z size の多重度依存性

      P40 Cluster z size の多重度依存性

      P45 衝突点カット後の cluster z size 分布

      P44 衝突点カット後の cluster z size 分布

      P47 衝突点カット後の cluster z size 分布

      P48 Cluster z size の多重度依存性

      P49

      P50 まとめ

      想定質問

      Q. MC とデータを合わせるために、MC に値を足していた。これはどういう意味?

      データには MC に無いヒットが 1300 もあるということ。かなり多いように思えるが、INTT のチャンネル数 35 万に対して 0.4% しかない。

      ちょっと結論があやふやなので、学会で見せる必要はない。

       

    • 14:00 15:00
      発表練習 2 1h
      Speaker: Ryota Shishikra (Rikkyo university(for the sPHENIX-INTT collaboration))

      メモ

      全体的なコメント

      • P5 から時間を測り始めた
      • 検出器の説明は簡潔に
        • ポイントを 1 つに絞るとしたら?
          • センサーには z 方向に隙間がある。数% あることを言っておくと良い
      • Single μ MC で角度分布があるものは何がしたかったんだっけ?
        • 最小 multiplicity としてやっている
        • これは衝突データと同じアルゴリズム
      • |Residual| の関数で効率を見せているが、見せて何がしたい?
        • アルゴリズム開発に residual window サイズの決定が含まれてもいい。|Residual| の関数で効率を見せるということは window サイズの最良値について言及することが期待されるが・・・
          • 最良値はまだ確定させない。もう少し時間をかける。
      • (秋葉)各ページの一番下に、そのページの結論を書くと良い。

      ページごと

      P1 表紙

      P2

      P3

      P4 研究内容

      • シンプルシミュレーションはわかりにくい。Single μ MC とか μ gun, particle gun とかと言おう。
      • 研究手法の流れを説明してほしい
        • 1. Single μ MC でアルゴリズム開発、2. 金金 MC でテスト、3. 金金 実データで解析 とか
        • 「アルゴリズム検証の流れ」

      P5

      P6

      P7 アルゴリズム

      P8 シミュレーション

      • シミュレーションは丁寧に説明しているけど、実データの説明は・・・シンプルすぎる?

      P9 シンプルシミュレーション 1

      • 入射源→ビーム生成点

      P10 シンプルシミュレーション 1, イベントディスプレイ 1

      P11 シンプルシミュレーション 1, イベントディスプレイ 2

      P12 シンプルシミュレーション1 residual

      • このページだけ自信なさそうに喋っている

      P13 シンプルシミュレーション1 検出効率

      P14 シンプルシミュレーション1 考察、

      P15 シンプルシミュレーション1, #outer cluster = 1

      • シンプル 1 に 1-1 (94%) と 1-2 (99.7%) があり、順番がややこしい。1-2 を先に持ってきては?
        • 1. 99.7%: もっとも単純な状況である Single μ なら検出効率 100% になるはず。少々極端なカットで確認してみた(テストビームでも同じようなことをしているので問題ない)
        • 2. 94%: ほぼ 100% が確認できたので、衝突データ解析用アルゴリズムを作って適用してみた。99.7% → 94% はアルゴリズムと 2 次粒子の影響だが、衝突データを解析することを念頭に置いているので仕方がない。

      P16 シンプルシミュレーション2

      • この辺で 8 分経過

      P17 シンプルシミュレーション2 結果

      P18 AuAu MC

      • この辺で 10 分経過
      • MC にも dead ch が入っていることを強調する。赤くする

      P19 

      P20 

      P21 AuAu データ vs MC

      • RD と MC のデータ状況を表にまとめる
      • Residual 比較でキャプションの重なりは書き直す。

      P22 まとめ

      • 12 分経過

      想定質問

      Q. シンプルシミュレーション 1 はテストビーム実験と実質的に同じ?でもシミュレーションは 94%, テストビームは 99%

      A. ビームパイプ、MVTX の散乱の影響?(宍倉)

      テストビームではテストするラダーの前後の測定点がかなり近い。この解析では衝突点を使っていて、ラダーから 8 cm ほど離れている。

      Q. シンプル MC 2 で効率 95%. 衝突点から INTT 内側バレルの間に放射長の 5% ほどの物質があるの?

      A. MVTX 1 層 1% で 3 層あるので 3% ぐらいはある。

      QQ. MVTX で相互作用したとしても μ の向きはほとんど変わらないんじゃないの?

      AA. ちゃんと確認しないといけないけど・・・

      (秋葉) δ 線(μ が物質中の電子を弾き飛ばした)がありうる。

      INTT ラダーの放射長 (X/X_0)は 1.14%. MVTX は 1 層で 1% もなかったはず・・・

      Good answer: 2 次粒子であることはイベントディスプレイで確認している。2 次粒子の最有力候補は δ 線で、これから詳細をみる。

      Q. Single μ MC 2 residual 分布の左右非対称なコブはなに?

      ヒットを見て回るアルゴリズムの方向が出ているのでは?

    • 15:00 16:00
      発表練習 2 1h
      Speaker: Mai Kano

      メモ

      全体的なコメント

      • イベントミックスアップ、混在ヒット、混在イベントの使い分けをしている
        • イベントミックスアップ:現象を指す
        • 混在ヒット:ミックスアップしているヒット
        • 混在イベント:ミックスアップが起こっているイベント

      ページごと

      P1 表紙

      P2 もくじ

      P3 研究背景

      P4 研究目的

      P5 トリガーデータ読み出し

      P6 トリガーデータ読み出し フルーツの比喩

      P7 トリガー読み出し 詳しい説明

      P8 ストリーミングデータ読み出し

      P9 ストリーミングデータ読み出し フルーツの比喩

      P10 ストリーミングモード 詳しい説明

      P11 イベントミックスアップ

      P12

       

      P13 ヒット数依存 2023 金金データ

      P14 ヒット数依存 2024 金金データ

      P15 衝突事象の間隔依存 2024 金金データ

      P16 現象発生イベントの割合

      • プロットアップデートしましょう
      • バックアップに移動

      P17 現象発生イベントの割合と衝突レート

      P18 ストリーミングにおけるイベントミックスアップ

      • ここで 8 分経過

      P21 

      P22 ストリーミングにおけるイベントミックスアップ 詳しい説明

      P23 イベントミックスアップのバンチ番号ごとのヒット

      P24 まとめ

      • ここで 10 分経過、11:04 で終了。
      • 今後の展望:10% 捨てるかリカバーするか
        • 言い方に注意しましょう。ミックスアップヒット数的には 1% を捨てたりリカバーする。ヒット単位で処理するとマルチプリシティ分布にバイアスを与えうるので、バイアスを与えたくないときはミックスアップイベント単位で処理すれば問題ない。イベント数的には 10% ほど。

       

      想定質問

      Q. サーバーが busy を発行して処理を待つべきでは?

      busy 発行機能の実装が間に合わなかった。

      2025 年はトリガー発行に dead time 64 (100? 決まっていない) BCO の dead time を入れることにした。これで問題は回避できる。