memo/00雑多

雑多なメモ †

NEBULA+NeuLAND †

このセットアップを使おうと思っている人がシミュレーションできるようにソフトを作る。最終的には情報交換するためのページが必要か？Wiki？たぶんUploadされる情報は

• simulationのレポート
  • クロストーク解析についてもDescriptionが必要か？うーん。面倒。。。
  • simulationのGeometryとレポートをセットにすればほかの人もすぐSimulationできる。
  • 北側の壁ぎりぎりに置いた時にどんな影響があるか見たい。
  • two-double planeを離すか、近づけるか？距離はどうやってOptimizeする？
  • VETOはどうする？
• 図面？
• セットアップ図？
• 掲示板のような使い方でOpenな議論をするか？それともメーリングリスト？
  • 掲示板の使い方なら、記事だけでなく、名前と日付を入れるべし。
  • Open question
    • VETO
    • proton tracking?
• 共通のアカウントかな？

とか？結局自分しかUploadしなさそう。。。 これは28Oの実験とするか、NEBULA+NeuLANDとするか？ 最終的にはNEBULA+NeuLAND Collaborationみたいな業績なども載せるページ？？？それは管理が大変。。。

SAMURAI アクセプタンス計算用コード †

11/25 †

作業メモ

• GetIon?でneutronはgetできない。わざわざneutronの場合の条件分岐を書いた。
• 結局ヘッダー用にTSimulationHeader?というクラスを作った。ROOTのクラスで適当なものを見つけられなかったので。
  • TDatimeというクラスを使うと日時を記録するのに便利。
  • 何を書いておくべきかは実はよく考える必要があるけれど。。。
• Input用のtreeを作るマクロもできた。
• 座標の定義を書いたEPSを作った。

配布できるくらいになった気がする。あとは配布用に整理するclean.shとか？ その後にとりあえずばらまいてみますかね？

11/22 †

大体できた。発生させた粒子の情報はsmsimulatorのTSimulationDataBeam?を使い、トレース後の情報は結局元のSPrimaryTrak?を少し変更しただけ。汎用のOutput用データクラスを作りたかったけど、各DetectoをIDするためにTStringを使うと、tree->Drawの時に微妙（/memo/root/tree）なので今はあきらめる。

残りの作業は

• クラスの名前を整える
• ディレクトリの整理
• Geant4マクロの整備
• InputのTreeを作るようのROOTマクロの例
• README
• 座標の定義を示したpsファイル

かな？

11/19 †

PhaseSpaceDecay?をインプットする場合はTreeをあらかじめ作っておいて、それをGeant4で読み込めば良い。そうするとneutron側のシミュレーションで同じinputを使うので、荷電粒子・中性子をそれぞれ独立にシミュレーションすることができる。これの良い点は、どういう分布を発生させるかはROOTのマクロで書けばよく、ビームの広がりや位置・角度の広がりを好きな分布で自由にいじることがやりやすくなる。また、Geant4の計算速度も上がるのでは？

InputするTreeは以下の情報を持っていないといけない。

• 位置・角度
• 運動量
• どの粒子かをIDする何か？
  • 一番簡単にはstringにして、GeneratorAction?でParticleTable?から検索する。
  • 次点はZやAを保存。でもガンマ線やelectronではダメ。やっぱりstringかな？

11/15 †

Geometryの部分は大体なんとなくできた。今は磁石の角度をMessengerからinputできるようにしているけど、きっとこれはSDetectorConstruction?にべた書きでいい。将来的にはSDetectorConstruction_Dayoneのような感じで各実験セットアップごとに作るのだろう。

あとはデータの入出力。

• 磁場マップはMessengerでも良い？（が良い？）
• treeに吐いたデータをそのままDrawしたい。今はFDCHitのTObjArray?を保存していて、要素が展開されない。TClonesArray?だと勝手にしてくれるが面倒。vectorでも展開してくれるみたい？

作業リスト

• TSimulationDataBeam?の輸入
• Trackの保存用にTSimulationDataTrack?を作るとすっきりするか？
• いろんなBeamType?の実装
• FDC2のoffsetのMessenger
• 荷電粒子窓
• 磁場マップのMessenger
• 磁場の強さをスケールするためのMessenger
• inputファイルの整備
• treeをinputにできるようにする
• PhaseSpaceDecay?でビームの位置・角度・Brhoを乱数で振る
  • treeのinputで対応することにする

うーんやること沢山。面倒くさい。。。

11/13 †

インプットは

• 標的から出てくる粒子の位置、角度、運動量の分布。以下を切り替えられるようにする？
  • 実験で観測しているものをヒストグラムにしておいて、その分布で乱数を振る
  • 一様に振る
• Erelの値
  • ある一定値
  • 一様に分布させる
  • ヒストグラムで分布を作っておいてその分布で乱数を振る
• phase space decayだけで良いよね？
• FDC2の位置をinputできるようにするのか？（面倒くさい）

インプットはrootファイルでやるのが良かろう。 アウトプットは

• ヒストグラムで作ったアクセプタンス
• treeで各粒子の運動量とアクセプトされたかどうかの情報等？

treeは例えば実験と分布を比較するときに必要になる。treeをマクロで解析して、中性子窓のアクセプタンスを含めて、中性子のefficiencyを含まないアクセプタンスも評価できる。

treeに詰めるobsevableとしてはこんなもん？

• 標的後の位置、角度、運動量
• 荷電粒子のFDC2での位置と角度
• flight lengthやTOF？　(HODを定義しないといけない。面倒。)

インプットやアウトプットのROOTファイルを管理するクラスを1個作ればできてしまうが。。。データクラスとファイル管理とに分けた方が良いのか？でもデータクラスでROOTに保存するとROOTで解析するときにライブラリをロードしないといけないとか、ユーザーには分かりづらい。treeに詰めるなら稚拙でもa_tgtとかにする方が良い気がする。うーむ。構造体をrootに保存して、勝手に展開してくれるみたいなのが良いけれど。

SAMURAIの標準シミュレーターに向けて思ったこと †

• MessengerのDirectoryの整理の仕方をきちんとしないといけない
• データクラスの共通化
  • 個人的にはTTreeに詰めたら、自動的に展開してくれて、各要素をDrawで見れるのがいい。TClonesArray?やvectorはやってくれる。
• たぶんSetupごとにDetectorConstruction?を書く。それに従わせるためにベースクラスが必要。