Geant4を使いこなすためのスタートラインに立つためには
世の中に落ちている文書は原子核の人にとっては先を行きすぎていて、まったく意味不明ということがよくある。
そこで、スタートラインに立つための項目をリストアップしてみる。
- c言語は当たり前に理解する。
- c++(オブジェクト指向プログラミング)を一応理解したつもりになっておく。
- KEK/JSTの岩井さんが北里大の講習会で公開していたsample codeを制覇する(今は公開されてないのでご本人にもらうか僕からもらうか)
以上三つでGeant4をこねくり回すためのスタートラインに立てると思います。
北里大の講習会で公開していたsample codeは非常にわかりやすいので超おすすめです(ただ一部変更しないとコンパイルは通らないかもしれません)。
講習会ではこの内容を3日でやったようですが、多分初心者なら一ヶ月かかっても普通だと思います。
そこから先はGeant4に付属しているexampleや僕が公開している中性子検出器のシミュレーションコードを参考に拡張できるはずです。
オブジェクト指向を本当の意味で理解するのはたぶん原子核屋には無理ですし、あらかじめ完璧に理解しておく必要はありません。
Geant4を使っていると何となく体に染み付いてくるかもしれません。
もっとも、Geant4をブラックボックスとしてほんのちょこっとだけ使うというのならここまでしなくても使えますが...
Geant4はtoolkit
Geant4はシミュレータではなくてtoolkitであるということを理解している上の方は少ない。
「Geant4によるシミュレーション」というのは「量子力学により原子核の反応を計算した」というぐらいに意味が無いstatementである。
なので、Geant4というtoolkitの枠組でどのような物理モデルを用い、何を考慮したかというのが明確になって初めてシミュレータとして自立する。
その行為がuser srcを書くことであり、ある意味user srcごとにシミュレータとして名前をつけて良いのである。
たえば初音ミクを使った楽曲に「supercell feat. 初音ミク」とつけるように「neutron simulator feat. Geant4」とかにしたりwww(feat.の使い方がおかしいとか言わない)
ただし、gamma線のシミュレーションなどはほっといても本質的に同じ様なcodeを書くことになるので省略して「Geant4によるシミュレーション」と言っているだけである。
Geant4の難しさ
- 便利なシミュレータではなくあくまでtoolkit。
- 初心者には汎用的すぎ。
- c++でかかれており、プログラムに構造を持っている(これがfortranやcで育って今まで成功してきた偉い人には理解できない)。
- 世の中のテキストがオブジェクト指向を基礎教養として要求している。
- ROOTほど公式のテキストが整っていない。
- codeはバリバリのオブジェクト指向(その割に命名規則とかはバラバラだけど)。
主な難しさは「高エネ・海外」と「原子核・国内」という畑の違いから生まれていると思われる。
もっともGeant4の開発者の多くは日本人みたいですが(始めたのも日本人？)。
最近の学会の発表を見ているとgamma線のシミュレーションはほとんどGeant4でやられているので、畑の違いというのは時間が解決してくれるかな？
c++の難しさ
c++はcの延長と思われがちで、確かにそうなのだが、cは「習うより慣れろ」が通用するのに対して
c++は「習った上で慣れろ」と言うべきでしょうか、習わずに慣れることができる言語とは到底思えません。
これはなぜかというと、cやfortran77はごく自然にcodeを順番に追っていくことができます(手続き型プログラミング)。
一方c++では「開発を楽にするため」(これは一年のほとんどをプログラムに時間をかけている原子核の研究者にとっては重要なファクター)に、
オブジェクト指向、より具体的にはポリモーフィズムや動的に型を判定する(動的型付けというと違う意味になるらしい)ことで、
codeの流れが人間が決めたルールの上でコントロールされるため、そのルール・概念を知らないと理解しようがありません。
比喩を使うなら、ニュートン力学はちゃんと習わなくても演習問題が解けますが、特殊相対論になるとその概念を理解しない限り演習問題は解けません。
古典力学と量子力学の違いと考えてもいいでしょう。
プログラム自体が構造を持っているということはそのぐらい隔たりがあるので、どうか体育会系のノリでc++をやらないで、ちゃんと勉強する時間を作るようにしてください。
ユーザーの使い方を考える
- beamのエネルギーやgeometoryが変更できて各検出器に必要な性能(efficiencyやresolution)がとりあえず出力される
- 実験データlikeなものを生成して解析したい
- 素過程として何が起きているか知りたい
- 入力のenergyを体系的に変えたい
- いろいろなphysics modelを試したい
と、とりあえず上げてみた。
で、実際にシミュレーションをやった経験からすると、どうせ上の人は初めはブラックボックスでいいとかいいながら、
後からそれどこまであってるのー？とかちゃんと細かいところを追えとか言われる。
上に言われなくとも、よくわからず出てきた結果を公に披露できるほどこの業界は適当ではない
(企業なら責任を作った人に押し付けれるのでそれがまかり通るが)。
ということで結局上の要求全てを満たすuser codeでないと最終的にだめなのである。
そこで、以下の二つのuser srcの公開を提案する。
1. 固定のinput, 固定のoutput
表題のタイプは旧来のよくあるシミュレータをデフォルト状態で使用するのと同じである。
これは、特定の検出器に特化したuser srcと文書を用意してシミュレータとして完成したものを配布すれば実現できる。
この様なuser srcはブラックボックスとしてとりあえずそれっぽい結果を出せるようにして、
初めの一歩の閾値を下げることになる(Geant4は動かすだけでもlinux初心者な学生には辛い)。
ただし、この様な思想でかかれたcodeを発展させて先にすすむのは大間違いで、
- 次のステップを踏むのが大変
- 配布したuser srcを直接ガリガリいじることが想定され、他の人のシミュレーションとconsistencyが得られにくい。
- 検出器ごとにメインのcodeを書き直さないといけない。つまりバグの温床となる。
- codeごとに目を丸くして読まないと怖くて使えない
- 配布側がいっぱい書かないといけなくて大変
- 設定を少し変えたいだけでもシミュレーションを再度回す必要があり、長時間かかる。
と、いろいろ問題がある。
そこで、次のステップとして次に示すuser srcも合わせて公開することを考える。
2. 半固定のinput, 一般的なoutput
input(beamのenergyとか)はGeant4が標準で提供しているG4UIdirectoryを使ってインタラクティブに変更できるようにする。
outputはGeant4が計算した「protonが45.3nsのときに2MeVエネルギーを落とした」というようなstep情報をすべてfileに吐くようにする。
これにもう少し細かい仕様を付け加えるとシンチレータを使う検出器などはGeant4のuser src部はDetectorのgeometoryを除いて
基本的に同じcodeとなり管理が楽、つまりむだな労力やバグを減らすことができる。
と、以上書いてみたが、実際に公開して見せるのが一番なのでそのうちちゃんと実現する。