* 雑多なメモ [#v2cb6a82]
** NEBULA+NeuLAND [#d9b492b2]
このセットアップを使おうと思っている人がシミュレーションできるようにソフトを作る。最終的には情報交換するためのページが必要か？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 アクセプタンス計算用コード [#l67c2172]
*** 11/25 [#lf73ef3c]
作業メモ
- GetIonでneutronはgetできない。わざわざneutronの場合の条件分岐を書いた。
- 結局ヘッダー用にTSimulationHeaderというクラスを作った。ROOTのクラスで適当なものを見つけられなかったので。
-- TDatimeというクラスを使うと日時を記録するのに便利。
-- 何を書いておくべきかは実はよく考える必要があるけれど。。。
- Input用のtreeを作るマクロもできた。
- 座標の定義を書いたEPSを作った。
配布できるくらいになった気がする。あとは配布用に整理するclean.shとか？
その後にとりあえずばらまいてみますかね？
*** 11/22 [#k5d642ee]
大体できた。発生させた粒子の情報はsmsimulatorのTSimulationDataBeamを使い、トレース後の情報は結局元のSPrimaryTrakを少し変更しただけ。汎用のOutput用データクラスを作りたかったけど、各DetectoをIDするためにTStringを使うと、tree->Drawの時に微妙（[[/memo/root/tree]]）なので今はあきらめる。
残りの作業は
- %%クラスの名前を整える%%
- %%ディレクトリの整理%%
- Geant4マクロの整備
- InputのTreeを作るようのROOTマクロの例
- README
- 座標の定義を示したpsファイル
かな？
*** 11/19 [#w5425a1a]
PhaseSpaceDecayをインプットする場合はTreeをあらかじめ作っておいて、それをGeant4で読み込めば良い。そうするとneutron側のシミュレーションで同じinputを使うので、荷電粒子・中性子をそれぞれ独立にシミュレーションすることができる。これの良い点は、どういう分布を発生させるかはROOTのマクロで書けばよく、ビームの広がりや位置・角度の広がりを好きな分布で自由にいじることがやりやすくなる。また、Geant4の計算速度も上がるのでは？
InputするTreeは以下の情報を持っていないといけない。
- 位置・角度
- 運動量
- どの粒子かをIDする何か？
-- 一番簡単にはstringにして、GeneratorActionでParticleTableから検索する。
-- 次点はZやAを保存。でもガンマ線やelectronではダメ。やっぱりstringかな？
*** 11/15 [#zed320f9]
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[#k8add37e]
インプットは
- 標的から出てくる粒子の位置、角度、運動量の分布。以下を切り替えられるようにする？
-- 実験で観測しているものをヒストグラムにしておいて、その分布で乱数を振る
-- 一様に振る
- 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の標準シミュレーターに向けて思ったこと [#s80f273c]
- MessengerのDirectoryの整理の仕方をきちんとしないといけない
- データクラスの共通化
-- 個人的にはTTreeに詰めたら、自動的に展開してくれて、各要素をDrawで見れるのがいい。TClonesArrayやvectorはやってくれる。
- たぶんSetupごとにDetectorConstructionを書く。それに従わせるためにベースクラスが必要。
ページ一覧
