Path: coconuts.jaist!wnoc-tyo-news!news.u-tokyo.ac.jp!komaba!info!makino From: makino@komaba.c.u-tokyo.ac.jp (Makino) Newsgroups: fj.sci.astro Subject: Re: Nbody simulation Date: 10 Nov 94 21:41:09 Organization: College of Arts and Sciences, Univ. of Tokyo Lines: 44 Distribution: fj Message-ID: References: <39silp$dbn@isnews.is.s.u-tokyo.ac.jp> <39ss3h$guk@isnews.is.s.u-tokyo.ac.jp> NNTP-Posting-Host: xss01.komaba.c.u-tokyo.ac.jp In-reply-to: tau@is.s.u-tokyo.ac.jp's message of 10 Nov 1994 10:19:29 GMT In article <39ss3h$guk@isnews.is.s.u-tokyo.ac.jp> tau@is.s.u-tokyo.ac.jp (TAURA Kenjiro) writes: > これで一応ひと安心はしました. もともとは, 果たしてでたら目に粒子分布を > 作りあげていいもんかなあというのが不安だったので, おききしました. (特 > にアルゴリズムによっては粒子が割と一様に分布してるのとそうでないのとで > 結構計算時間が変わると思うので) Barnes-Hut を考えておられるのでしたら、計算量は「それほどは」粒子数に 依存しません。三次元でもっとも速いのは立方体の中に一様に粒子がある場合 でしょうが、現実的な銀河モデルでも計算時間が２倍になるかどうかといった ところのはずです（並列化のしかたが無能だと開きが大きくなりますが）。 > そうですね. 他の人達はどうか知りませんが, 我々の立場からすると, nbody > をやりたくなる理由は, > > (1) 物理的に意味があって, (もちろん別に物理でなくても良い) > > なおかつ, > > (2) sophistecate されたalgorithm (具体的にはadaptive mesh refinement) > がある. > > というのが, 理由です. sophistecateされたalgorithmを並列computerで実行 > するには, 現在の状況だとかなりprogrammerへの負担が大きくて, それをABCL > で改善するというのが一般的な目標です. 上の adaptive mesh refinement は Barnes-Hut tree と理解していいのでしょ うか？それとも FMM の実装も考えておられるのでしょうか？いずれにしても、 BH tree は彼らの元論文に載ってるアルゴリズムとかメイルを送るとくれるプ ログラムは特に並列化しにくい形で書いてあるので、あれをアルゴリズムを大 きく変えないで並列化するのは（特にツリーコンストラクションのところは） しんどいわりには成果がでにくいはずです。で、特に分散メモリの機械で並列 化するアルゴリズムとかはカルテクでデルタを使っていた John Salmon とか がやっていたし、ベクトル化なら僕もやったことがあります（現在天文業界の ほとんどでは僕のアルゴリズムベースのが使われています。コードは僕ではな くて UCSC の Lars Hernquist が書いたものですが）。 「並列化しにくいこんなのでもうまくできますよ」ということをいいたいのだ とすればそこにこそ意味があるということになるのでしょうけれど、それでは 天文屋が使えるものにはなかなかなってくれないので。 # fj.sci.astro では珍しい話題だ。 牧野＠東大駒場