24/10/21 進捗報告

Gadget-4のMerger treeについて理解する。

マニュアルには以下のようなことしか書いてない。

マニュアル (Gadget4-Osaka)

マージツリーの構築は、Springel et al. (2005) によって導入された概念に従っています。詳細は以下のリンク先をご参照ください: http://adsabs.harvard.edu/abs/2005Natur.435..629S。このツリーは、FOFグループ内で識別されたサブハローのためのものであり、FOFによるグループの探索とSUBFINDまたはSUBFIND_HBTを使用したサブハローの検出が必要です。そのため、MERGERTREEを設定する際にはこれらのオプションを有効にする必要があります。構築されたマージツリーの模式的な組織構造は、以下のスケッチに示されています。

[図]

各出力時刻で、FOFグループが識別され、それらは1つ以上の（サブ）ハローを含み、マージツリーはこれらのハローを接続します。FOFグループはツリーにおいて直接的な役割を果たしませんが、指定されたFOFグループ内で最大のハローがメインサブハローとして選ばれます。ツリーを構築するためには、各サブハローに対していくつかのポインタを定義する必要があります。各ハローは、後の時刻でのグループカタログにおける子孫を知っている必要があり、マージツリー構築における最も重要なステップはこのリンクを決定することです。

このリンクの決定は、GADGET-4を使用して2つの方法で実行できます。シミュレーションを実行している間にMERGERTREEを有効にすると、新しいスナップショットが生成されるたびに、前のグループカタログの子孫ポインタが計算され、出力ディレクトリに蓄積されます。結果はsub_desc_XXXという特殊なファイルに書き込まれます。本質的に、これらのファイルは2つの連続したグループカタログ間の接着剤の役割を果たします。この方法の利点は、粒子データ自体を出力することなくマージツリーを構築できる点です。代替として、MERGERTREEオプションを使用せずに実行されたシミュレーションに対して、後処理でこれらのファイルを作成することも可能です。しかし、この場合、スナップショットファイルが必要で、少なくとも、粒子IDがグループカタログ出力に含まれている必要があります。

これらのリンクファイルを作成するプロセスは、リスタートフラグ7を使用し、指定されたスナップショット番号および前回の出力のために行うことで実行できます。この操作は、ツリーに含めるすべてのスナップショットに対して、最初のものを除いて（すなわち、出力番号1から最後のものまで）繰り返す必要があります。最後に、GADGET-4に個別のツリーを分離し、対応するサブハローをツリーを簡単に処理できる形式に整理するよう指示することができます。この形式は、例えば、銀河形成のための半解析コードで使用されます。このプロセスでは、上記のスケッチに示されている他のリンクも計算されます。これを行うには、GADGET-4をリスタートフラグ8で起動し、最後のスナップショット番号を追加引数として指定します。GADGET-4はその後、すべてのグループカタログデータおよび子孫リンクファイルを処理し、新しいツリーファイルのセットを決定します。アルゴリズムは完全に並列化されており、非常に大規模なシミュレーション、大規模なグループカタログおよびツリーセットを処理できるよう設計されています。この場合、ツリーファイルは通常、多数のファイルに分割され、後の処理を簡素化するため、ツリーがどのファイルに配置されるかはランダム化され、サイズが均等に分散されます。各タイムスライスのサブハロー番号に基づいて、該当するツリーがどこにあるかを素早く参照できるよう、対応するポインタもグループカタログに追加されます。

VolkerのAndrewのメールへの返信

マニュアルにはさほどのことが書いてない。

そこで、ぐぐるとAndrewとVolkerのやり取りが出てきた。

AndrewがGadget Usersに対して次のような文章を投げたようだ。

Gadgetユーザーの皆様、

現在、pynbodyツールセット（pynbody.github.io）をGadget-4のsubfind実装にスムーズに対応させるための更新を行っています。最新バージョンのpynbodyではほとんどすべてがうまく動作していますが、Gadget 4のシミュレーションからマージツリーをtangos（ハローとツリーを保存するためのデータベースシステム）にインポートしようとして少し行き詰まっています。以下についてお分かりの方がいらっしゃれば教えていただきたいです。

https://wwwmpa.mpa-garching.mpg.de/gadget4/09_special_modules/ によると、Gadget 4はリンクリストのスキーマに従ってハローの祖先と子孫の両方を格納していることを理解しています。

この情報を基に、すべての子孫（または、詳細を少し変更して祖先）を列挙するために、私は以下のように仮定しました。

1. 興味のあるサブハローについて、subhalo_desc_nnn.hdf5内のFirstDescSubhaloNrを確認する。

2. 次のスナップショット（m=n+1）にあるsubhalo_prog_mmm.hdf5を確認し、NextDescSubhaloNrをたどって次の子孫を探す（ある場合）。

3. NextDescSubhaloNrのチェーンを、-1に達するまでたどり続ける。

これで一部のケースでは動作するのですが、“DescSubhaloNr”（「First」や「Next」で始まらないもの）の役割について非常に混乱しています。最初にツリーを解読しようとした際、「DescSubhaloNr」を無視していました。しかし、「DescSubhaloNr」がハローの適切な子孫を指しているケースに遭遇し、一方で「FirstDescSubhaloNr」が-1で子孫がいないように見えるケースがあります。（同様に、「FirstDescSubhaloNr」が適切に見えるが「DescSubhaloNr」が全く別の場所を指しているケースもあります。）“DescSubhaloNr”の役割について何かご存じの方はいらっしゃいますか？

何かヒントをくださったり、正しい方向を指し示していただければとても助かります。まだコードを読んでも大きな進展が見られませんでした。

よろしくお願いします。

Andrew Pontzen

原文

それに対して、Volkerが返信した内容が役に立つ。

こんにちは、Andrew。

大変遅くなって申し訳ありません。最近は旅行が多くて…。

これらのフィールドの命名は、当然のことながら非常に紛らわしいものです。説明してみますね。

DescSubhaloNrフィールドを決定するために、コードは各サブハローに対して、次のスナップショットで最も可能性の高いサブハローを1つ（最大で）見つけます。この一致は、サブハローの最も結合が強い粒子を追跡し、それらの粒子がどこに終着するかを見ることで確立されます。これらの粒子が同じサブハローに全て収まらない場合は、最も結合が強い粒子の「ほとんど」を含む1つのサブハローを特定するためにスコアが使用されます。

同様に、コードは逆方向でも実行され、ProgSubhaloNrフィールドに格納される主要な祖先サブハローを、最も結合が強い粒子がどこから来たのかを調べることで決定します。

複数のサブハローが同じDescSubhaloNrを指すことがあります。このサブハローのグループは、FirstProgSubhaloNrおよびNextProgSubhaloNrによって説明されるリンクリスト構造でアクセス可能です。

同様に、複数の異なるサブハローが同じ祖先ProgSubhaloNrを指すこともあります。この場合、対応するサブハローのグループは、あなたが説明したようにFirstDescSubhaloNrおよびNextDescSubhaloによって識別できます。

基本的に、ProgSubhaloNrはFirstDescSubhaloNr/NextDescSubhaloフィールドを誘導し、DescSubhaloNrはFirstProgSubhaloNr/NextProgSubhaloNrフィールドを誘導します。このため、FirstDescSubhaloNr/NextDescSubhaloとFirstProgSubhaloNr/NextProgSubhaloNrの2つのリンクリストペアは厳密には新しい情報を追加しませんが、ツリー内をナビゲートしたいときに非常に便利です。

この結果として、通常、最良の子孫はDescSubhaloNrによって与えられますが、これが失敗するか疑わしいリンクを与える場合は、FirstDescSubhaloNr/NextDescSubhaloで与えられるセットを確認し、より良い代替が含まれているかを確認できます（これらのサブハローは最終的にはProgSubhaloNrリンクに基づいています）。

同様にProgSubhaloNrも、基本的には最も自然な祖先ですが、FirstProgSubhaloNr/NextProgSubhaloNrは、現在のサブハローをDescSubhaloNrとしてリストしているサブハローの代替を提供します。

これにより、例えばFirstDescSubhaloNr = -1がない一方でDescSubhaloNrが存在し、問題ない場合もあります。逆のケースも原理的には可能です。

この説明が少しでも役立てば幸いです。

よろしく、

Volker

原文