Conference Room SAD

[thread display] [new arrival display] [word search] [past log] [管理用]
Subject ： NPARAの問題点

Date ： 2008/03/21(Fri) 00:39:32

Contributor ： Akio Morita
最近のPCでは MultiCore/MultiProcessorな環境が増えていますが、
NPARAを2以上に設定してトラッキングを並列化する場合には、
コードをざっと見た限りでは次のような問題があると思います

1. PSPAC/WSPACとの組み合わせ
   内部の詳細なコードを検証していませんが、粒子分布全体の統計量や
  粒子間相互作用に依存した計算を行うはずなので、NPARA != 1 での
  計算結果は並列化されたトラッキングルーチン間での同期処理が無いために
  結果が保証できない？

2. MAP Elementとの組み合わせ
  (1)と同様の理由により、ExternalMap[]に渡ってくる粒子分布の完全性は
  保証されないので、粒子分布の統計、ダンプや相互作用を取り込んだ処理は
  結果が保証できない？
  (昔、生出さんが ExternalMap[] と NPARAの組み合わせは問題があると言っていた)

3. RAD/FLUCとの組み合わせ
  並列処理されるトラッキングエンジンが同一の疑似乱数列を共有する(fork(2)
  するのだから当然ですが)ので、シンクロトロン放射に伴う量子励起(FLUC)で
  用いられる疑似乱数列がトラッキングエンジン間(粒子グループ間)で統計的に
  結合している。
  * 同一初期条件(粒子分布・疑似乱数列)での計算結果が、NPARA依存になる(確認済み)
  * NPARAが増えれば増えるほど、統計的な性質が劣化する
    np = NPARAの極限では、全ての粒子に同じ疑似乱数列が適用される？
    初期条件が同じ粒子の集団の拡散過程を追いかける場合、NPARA > 1は正しい結果を与えない？
  -> 結果の統計的な性質の改善には、トラッキングエンジン毎に異なる疑似乱数列を与えれば
      良いはずですが、TrackParticles[]の内部でかってに fork(2)して wait(3)で合流して戻ってくるので
      介入手段がありません

SPACとRADLIGHTに関しては、明示的に禁則処理が組み込まれており並列化されません。

短期的な Work Aroundに関しては、問題がある処理を含む場合 SPAC/RADLIGHTと
同様に並列化を禁止すれば良いわけですが、本質的解決には並列トラッキング間の
中途での同期処理の導入と tturn1がトラッキングエンジンの親子関係を認識するように
拡張する必要があると思われます。
また、Space Chargeのように重い処理を並列化しようとした場合、事前に共有メモリを
確保する必要がある現状の fork(2)モデルよりも 全メモリを共有するPOSIX Threadモデルの
方が便利だと思われます。
# ポテンシャルマップを保持するためにメモリを大量に使う場合、64bit化の方が急務かも知れませんが...
Subject	： NPARAの問題点
Date	： 2008/03/21(Fri) 00:39:32
Contributor	： Akio Morita