動作例については以下を参照されたい。
https://github.com/matsim-org/matsim-example-project

このプロジェクトには有効な pom.xml が含まれており、MATSim 本体を含むすべてのライブラリ依存関係が Maven によって自動的に解決される。

³ この方法は MATSim 0.8.x 以降で利用可能である。

(*) および (**) に示した拡張ポイントについては、第 25 章で詳しく説明されている。このレベルでは、Java および IDE の基本的な知識が必要となる。
Java スクリプトとして書かれた MATSim の例は、以下で確認できる（MATSim のバージョンごとにブランチが分かれている点に注意）。
https://github.com/matsim-org/matsim-code-examples

3.2.4 MATSim ExamplesUtils

サンプルシナリオデータにアクセスするための一つの「方法（トリック）」として、次のようなコードが利用できる。

URL context = org.matsim.examples.ExamplesUtils.getTestScenarioURL("equil");
URL url = IOUtils.extendUrl(context, "config.xml");
Config config = ConfigUtils.loadConfig(url);

これは matsim-example-project に含まれる
RunMatsimFromExamplesUtils.java
で確認できる。

この機能を使用するには、pom.xml に以下の依存関係を追加する。

<dependency>
  <groupId>org.matsim</groupId>
  <artifactId>matsim-examples</artifactId>
  <version>${matsim.version}</version>
  <!-- <scope>test</scope> -->
</dependency>

これらの行はすでに matsim-example-project に含まれている。
シナリオデータは以下に置かれている。
https://github.com/matsim-org/matsim-libs/tree/master/examples/scenarios

⁴ この依存関係は通常は test スコープに限定すべきである（コメントアウトされている行）。そうしないと、継承するすべてのプロジェクトに伝播してしまうためである。ただし、他のプロジェクトから依存されない「末端（leaf）プロジェクト」であれば、main スコープに含めても問題ない。

3.2.5 Contrib や外部拡張の利用

MATSim には、メイン配布物に含まれない拡張機能が存在し、以下の 2 種類に分かれる。

• MATSim リポジトリ内の contrib セクションに含まれる拡張

• MATSim リポジトリ外に存在する 外部拡張

拡張機能は以下から探すことができる。
http://matsim.org/extensions

外部拡張は、入力生成や出力分析・可視化など、より独立した用途や API 設計を持つ場合が多い。
contrib・外部拡張のいずれについても、利用方法は各拡張のドキュメントを参照する必要がある。

MATSim コアチームは、contrib や外部拡張を利用する場合も、まず
https://github.com/matsim-org/matsim-example-project
から開始することを推奨している。pom.xml に依存関係を追加するだけで Maven が管理してくれるためである。
この場合も、Java および IDE の知識が必要である。

例：OTFVis の利用（概略）

main( ... ) {
  Config config = ConfigUtils.xxx(...);
  Scenario scenario = ScenarioUtils.loadScenario(config);
  Controler controler = new Controler(scenario);

  controler.addOverridingModule(new OTFVisLiveModule());
  // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  controler.run();
}

これにより、各 mobsim 実行に直接接続されたインタラクティブ可視化ツール OTFVis が起動する。

3.2.6 独自拡張の作成

既存の拡張だけでは目的の分析を構成できない場合、次の選択肢は 独自の拡張を作成することである。
この場合も、まず
https://github.com/matsim-org/matsim-example-project
から始めることを勧める。

また、自作拡張は第 25 章で述べられる 拡張ポイント を使用すべきである。これが、将来的に公式 contrib として取り込まれる唯一の方法だからである。

3.3 この仕組みの背後にある考え方

このような構成は、MATSim が単一の巨大なモノリシックソフトウェアとして成長し続ければ、最終的には開発チームが対応しきれなくなる、という認識から生まれた。そのため、コア開発者は中核インフラに集中し、道路課金、マルチモーダルシミュレーション、信号制御、追加の選択次元、分析モジュールなどの個別機能は、コミュニティによって開発・提供される仕組みが求められた。

このため、プラグイン型アーキテクチャは必然的な選択であったが、十分に柔軟で堅牢な拡張ポイントを整備するには（そして今なお）時間と労力を要している。

同時に、MATSim は研究プラットフォームでもある。研究では、設計時には想定されていなかった新しい問いに取り組むことが多く、スクリプト言語が解決策となることが多い。例えば、QGIS⁵、VISUM⁶、EMME、SUMO（TraCI インタフェース経由）⁷では、Python 等のスクリプトがプラグインとして利用されている。

MATSim でも Scala の導入が検討されたが、最終的には Java 自体をスクリプト言語として使う 判断がなされた。これにより、MATSim の開発と利用の間で 2 つの言語を学ぶ必要がなくなる。また、ベルリン工科大学（TU Berlin）のチームは、MATSim の導入教育と一般的な専門スキルとして、引き続き Java を教えることができる。

3.4 既存 MATSim 機能の全体像

図 3.1 は、主要な MATSim モジュールが MATSim ループのどこに結合しているかを示している。
一部のモジュールは単一の接続点を持ち（ループ周辺に配置）、他のモジュールは複数の接続点を持ち（円の中央部に配置）、さらにグローバルに作用するものは左上・左下に配置されている。

技術的な利用方法の詳細は、以下から参照できる。
http://matsim.org/extensions

MATSim の contrib は、分散的かつプロジェクト主導・博士論文主導（第 26 章参照）で開発されるため、特定用途に特化して実装されることが多い。その結果、特定の交通手段専用、あるいは特定の呼び出し順序でしか動作しないなどの制約を持つ場合がある。

これらを一般化するには追加の開発努力が必要であり、結果として、特定モジュールを他の機能と組み合わせて利用することは容易でない場合が多い。そのため、実運用の前に、モジュールの組み合わせは体系的にテストする必要がある。

第 4 章以降におけるモジュールの説明は、表 3.1 に示される分類に基づいて行われる。

⁵ http://docs.qgis.org/testing/en/docs/pyqgis_developer_cookbook/
⁶ PTV (2011)
⁷ http://sumo.dlr.de/wiki/TraCI

4. MATSim の設定に関する詳細

4.1 概要

本章では、3 つの基本要素（config、population、network）と組み合わせて使用できる各種設定オプションについて説明する。

MATSim は設定ファイルを複数の場所に書き出す。たとえば、ログファイル内、各イテレーションの出力ディレクトリ内、あるいは第 2.1.3 節で説明した CreateFullConfig 機能によって生成されるファイルなどである。第 2.4 節で述べたように、これらのファイルには設定オプションを説明するコメントが付与されており、しばしば設定内容を確認するための最良の情報源となる。

config は当然ながら、config ファイルを編集することで変更できるが、コード側から変更することもできる。基本的な構文は第 3.2.3 節で示したとおりである。IDE を通じて MATSim を利用するつもりであれば、コード側で設定を変える方法の方が有利な場合も多い。以降では、その Java 側の構文を逐一説明はしないが、多くの場合、XML の構造と IDE のタブ補完を併用すれば、対応関係は容易に推測できるはずである。

4.2 MATSim のデータコンテナ

4.2.1 Network

config ファイルの

<module name="network">
  ...
</module>

のセクションでは、シミュレーションで使用する network ファイルを指定する（第 2.1.3 節および 2.3.1.1 節参照）。時間変動ネットワークの指定など、さらなる設定オプションについては第 11.2 節で説明する。

4.2.2 Population

config ファイルの

<module name="plans">
  ...
</module>

のセクションでは、どの population ファイル（デイリープラン群）を使用するかを指定する（第 2.1.3 節および 2.3.1.2 節参照）。エージェント属性やサブポピュレーションの指定など、さらに踏み込んだ設定については第 11.3 節で説明する。

4.2.3 その他の MATSim コンテナ

その他の MATSim コンテナについては第 11 章で説明する。

4.3 グローバルモジュールとグローバルな側面

4.3.1 controller 設定セクション

Control(l)er は MATSim を実行する上で不可欠であり、そのパラメータは config ファイルの

<module name="controller">
  ...
</module>

のセクションで設定する。

ここでは、MATSim 実行の出力ディレクトリ、イテレーション数、plans および events の出力間隔などを指定できる。また、使用する mobsim の種類もここで定義する（第 4.4 節）。

経路探索アルゴリズムは、次の設定で指定する。

<param name="routingAlgorithmType" value="{Dijkstra | AStarLandmarks | SpeedyALT}" />

現在は SpeedyALT がデフォルトであり、他の 2 つは後方互換性のために残されている。

4.3.2 並列計算

MATSim は計算速度を向上させるためにマルチスレッドを使用している。関連する設定パラメータはいくつかの config モジュールに分散しているが、ここでまとめて説明する。

グローバルなスレッド数

config ファイルの global セクションには、次のような設定が含まれる。

<module name="global">
  <param name="numberOfThreads" value="2" />
  ...
</module>

この値は複数箇所で使用されるが、最も重要なのは「革新的戦略（innovative strategies）」であり、そこでの複数リクエストが複数スレッドに分配される。出発点としては、利用可能な CPU コア数と同じ値を設定するのがよい。

イベント処理の並列化

config ファイルの

<module name="parallelEventHandling">
  ...
</module>

のセクションでは、イベント処理に用いるスレッド数を指定する。Waraich et al. (2009) で述べられているように、イベント処理は MATSim 実行のボトルネックになり得るため、複数スレッドで処理することでシミュレーションを大きく高速化できる場合がある。

QSim の並列化

並列 QSim（Dobler, 2013 参照）のスレッド数は、次のようにして設定する。

<module name="qsim">
  <param name="numberOfThreads" value="10" />
  ...
</module>

一般的な推奨事項

一般に、スレッド数を増やせば必ずしも高速になるとは限らず、MATSim でも同様である。シナリオとハードウェアの組み合わせごとに試行が必要になる。以下にいくつかの推奨事項を示す。

• 「global」のスレッド数は、まず利用可能な CPU コア数から開始するのがよい。

• イベント処理の並列化は、完全にオフにすることはもはやできない。0、null、1 を指定した場合はいずれも同じ意味になる。1 より大きい値を設定すると性能が向上することもあるが、その効果は一般にそれほど大きくはない。

• 最も敏感なパラメータは QSim 用のスレッド数である。比較的新しいハードウェア（例：2014 年の MacBook Pro）では、利用可能な 8 コアのうち 6 コアを QSim に割り当てることで、mobsim を 2 倍以上高速化しつつ、同じマシンでオフィス用途も継続できることがある。古いサーバーでの経験では、スレッド数を増やすと逆に遅くなることが多く、mobsim のスレッド数は慎重に検証する必要がある（Dobler, 2013）。

• ハイパフォーマンスコンピューティングクラスター（HPC）が利用できる場合もある。この種の環境では、通常、計算時間に応じてコスト（もしくは優先度低下）を支払う。これは、ジョブの実行時間と予約コア数の積に比例することが多い。このような状況では、未使用コアに対して料金を支払わないよう、プロセス全体で使用するコア数を安定させるべきである。
  一つの推奨としては、QSim のスレッド数を最適値（上記の要領）で n と決め、parallelEventHandling を 1、global のスレッド数を n とし、ジョブの投入時にも n コアを要求する、というやり方がある。
  一般に、効率の観点からは、スレッド数は少ない方がよいことが多い。

• さらに、キャリブレーションや「what-if」シナリオの検証では、多数のパラメータや入力データを変えたシミュレーションを繰り返し実行する必要がある。総 RAM に余裕があるなら、スレッド数を抑えたシミュレーションを多数並列に走らせる方が、スレッド数を多くしたシミュレーションを少数走らせるよりも効率的なことが多い。

4.3.3 global 設定セクション

config ファイルの

<module name="global">
  ...
</module>

のセクションでは、シミュレーションの乱数シード、「global」な Java スレッド数（第 4.3.2 節参照）、および座標系（第 2.3.4 節参照）を定義できる。

乱数シードを明示的に指定するかどうかに関わらず、MATSim は常に固定の乱数シードから開始する。シードは、ユーザが指定した値、あるいは内部定数のいずれかである。つまり、同じバージョンの MATSim を同じ config で 2 回実行すると、同じ乱数列が使用され、まったく同じシミュレーション結果が得られる。

この挙動を変えたい場合は、乱数シードを明示的に変更する必要がある。

4.4 Mobility Simulations（移動シミュレーション）

MATSim における移動シミュレーションの概観は Dobler and Axhausen (2011) によって示されている。QSim と JDEQSim の双方で用いられているキューモデル（queue model）は、以下の要素を実装している。

• ストレージ制約：リンクが満杯でない場合にのみ車両はリンクに進入できる。

• 自由速度制約：リンク上の自由速度走行時間が経過した場合にのみ車両はリンクから退出できる。

• アウトフロー制約：現在のタイムステップで、そのリンクの流出容量が消費されていない場合にのみ、車両はリンクを出ることができる。

詳細は「Queueing Representation of Kinematic Waves（キネマティック波の待ち行列表現）」の章を参照のこと。

図 4.1 は、MATSim のループの中で mobsim がどこに位置するかを示している。

4.4.1 QSim

キューに基づくタイムステップ型の QSim（Gawron, 1998; Simon et al., 1999; Cetin et al., 2003; Dobler and Axhausen, 2011; Dobler, 2010）は、MATSim のデフォルト mobsim である。そのパラメータは config ファイルの

<module name="qsim">
  ...
</module>

<param name="numberOfThreads" value="..." />

これにより QSim を並列実行できる（第 4.3.2 節参照）。

• flowCapacityFactor と storageCapacityFactor

<param name="flowCapacityFactor" value="..." />
<param name="storageCapacityFactor" value="..." />

サンプルシナリオを実行する際には、これらの値をサンプル率に合わせて設定する必要がある。例えば需要の 10% サンプルを用いる場合には、これらの値は 0.1 に設定する。

交通ダイナミクスの種類
QSim は以下の交通ダイナミクスをサポートしている：

• queue：リンクのストレージ容量が満杯の場合には、新たな車両はリンクに進入できない。

• withHoles：1 台の車両がリンクを退出するたびに「穴（hole）」が生成され、典型的なキネマティック波速度である 15 km/h で上流方向へ伝播する。車両は、上流端に穴が到達したときにのみリンクへ進入できる。リンクは、ストレージ容量に相当する数の穴が上流端に存在する状態から初期化される。これによりキネマティック波の一部を表現する。

• kinematicWaves：withHoles の設定を拡張し、リンクの流入も制約する。最大流入量は、自由流と渋滞流の両方を直線的と仮定した基本図から最大流として計算される。
  詳細は前述の「Queueing Representation of Kinematic Waves」の章を参照。

これらは以下のように設定する。

<param name="trafficDynamics" value="..." />

• 第 12.3 節で示すように、QSim はマルチモーダルシナリオを扱うことができる。

• stuckTime

<param name="stuckTime" value="..." />

このパラメータは、車両が何秒間動かない状態になったら、たとえ行き先リンクのストレージ制約に反していても交差点を強制的に通過させるか、というしきい値を決める。これは、どの車両も動けなくなる「グリッドロック」（幾何学的な詰まり）を解消するために導入されている。
QSim では、この値を利用して、ストレージ制約を超える形で超過車両をリンクに追加することができる。これは、極めて混雑した状態でも最小限の流れを維持することに相当する。
デフォルト値は 10 であり、これは「動かない状態が 10 タイムステップ続いたら車両を前進させる」ことを意味する。一見短く思えるが、体系的な検証（残念ながら未公表）では、この値を大きくすると、交通カウントデータとの比較においてシミュレーションがむしろ現実から離れることが示されている。

4.4.2 Hermes

Hermes は、スイス連邦鉄道（SBB）が ETH チューリッヒに開発を委託した mobsim である。全機能のうち重要な 80% に絞り込み、その範囲で高速な実装を提供することを目的としている。SBB によって積極的に維持・利用されているが、特定の研究テーマに関する最新機能をすべて取り込んでいるわけではないため、研究用途には必ずしも最適ではない。

4.5 スコアリング

図 4.2 は、MATSim のループの中でスコアリングがどこに位置するかを示している。

config ファイルの

<module name="scoring">
  ...
</module>

のセクションでは、エージェントのプランのスコアリングに使用されるパラメータを指定する（第 2.1.3 節参照）。パラメータの詳細は第 14 章で説明される。

4.6 リプランニング戦略

図 4.3 は、MATSim ループ内でリプランニングがどこに位置するかを示している。

4.6.1 概要

リプランニング戦略は、MATSim における基本的な「イノベーションモジュール」である。エージェントが保持するプラン集合（選択肢集合）自体に影響を与えるモジュール（選択肢集合生成）と、既存のプラン集合の中からどれを選ぶかだけを変えるモジュール（選択）の 2 種類に区別できる。
MATSim を選択モデルの文脈で捉える詳細な議論は、「Choice Models in MATSim」の章を参照されたい。

第 2.2 節で既に示したように、リプランニングは次のように設定される。

<module name="replanning">
  <parameterset type="strategysettings">
    <param name="strategyName" value="ReRoute" />
    <param name="weight" value="0.2" />
  </parameterset>

  <parameterset type="strategysettings">
    <param name="strategyName" value="TimeAllocationMutator" />
    <param name="weight" value="0.1" />
  </parameterset>

  <parameterset type="strategysettings">
    <param name="strategyName" value="ChangeSingleTripMode" />
    <param name="weight" value="0.1" />
  </parameterset>

  <parameterset type="strategysettings">
    <param name="strategyName" value="ChangeExpBeta" />
    <param name="weight" value="0.7" />
  </parameterset>
</module>

各モジュールには重み（weight）が与えられ、そのモジュールに対応する行動が選ばれる確率を表す。重みの総和が 1 でない場合は正規化される。

この例では、各エージェントは、確率 0.2 で経路変更、0.1 でプラン時刻の変更、0.1 で交通手段の変更を行い、残りの場合はプラン集合からロジットモデルに基づいてプランを選択する（ChangeExpBeta）。図 4.4 にそのイメージが示されている。

古いバージョンの config ファイルでは、番号付き戦略を用いる非推奨の記法が残っている場合がある。また、公共交通などの拡張機能（第 3.2 節参照）とイノベーション戦略を組み合わせると、期待どおりに動作しないことがある。
戦略の組み合わせは慎重に行い、疑問があれば http://matsim.org/faq で問い合わせることが推奨される。

4.6.2 プラン生成・削除（プランイノベーション／選択肢集合生成）

この小節では、選択肢集合を変更する設定について説明する。

いわゆる「イノベーション戦略」は、まず 1 つのプラン¹を選び、それをコピーしてエージェントのプラン集合に追加し、そのコピーを「selected」に設定して次回 mobsim 実行で用いる。その後、mobsim 実行後には他のプランと同様にスコアリングされる。最後に、エージェントのプラン数が 5 を超えていれば、最もスコアの低いプランが削除される²。

この仕組みによって、各エージェントのプラン集合は継続的に更新され、新しいプランが追加され、スコアリングされ、既存プランより良ければ残されていく。これを「plans innovation（プランイノベーション）」と呼び、最終的にはどこかの時点で停止するのが望ましい。

4.6.2.1 時間イノベーション

時間イノベーションは、以下のような戦略設定を追加することで適用される。

<param name="strategyName" value="TimeAllocationMutator" />

およびその重み。対応するモジュールは

<module name="timeAllocationMutator">
  ...
</module>

で設定される。

この戦略は、Balmer et al. (2005)、Raney (2005) で説明されているように、アクティビティの終了時刻を指定範囲内でランダムにシフトする。

4.6.2.2 経路イノベーション

経路イノベーションは、次の戦略設定を追加することで適用される。

<param name="strategyName" value="ReRoute" />

およびその重み。さらに第 4.3.1 節で述べたように、controller セクションで使用する経路探索アルゴリズムを指定する必要がある。

4.6.2.3 モードイノベーション

モードイノベーションは、次のいずれかの戦略名を指定することで適用される。

<param name="strategyName" value="{ChangeTripMode | ChangeSingleTripMode | TripSubtourModeChoice}" />

この例では、自動車と公共交通 pt 間のモード切替を許可している。³

イノベーション戦略は、まずランダムにプランを 1 つ選び、それをコピーして集合に追加し、そのコピーを次回 mobsim の selected プランにする、という点を思い出してほしい。

• ChangeTripMode は、そのコピーされたプラン内のすべての trip のモードを変更する。デフォルトでは、自動車と公共交通のみがサポートされており、プラン全体として 1 種類の交通手段しか持たない。

• 1 日の中でサブツアーごとに異なるモード（例：朝は車、昼は徒歩など）を扱うには、SubtourModeChoice 戦略が必要になる。

• ChangeSingleTripMode は、ランダムに一人のプランを選び、そのプラン内の 1 つの trip をランダムに選んで、その trip のみモードを変更する。このため、1 つのプラン内に複数モードを共存させることができる。デフォルトの対応モードは、自動車と公共交通である。また、オプションとして自動車利用可能性（car availability）を考慮することもできる。

モードイノベーションについては、Rieser et al. (2009)、Meister et al. (2010)、Ciari et al. (2008, 2007) で説明されている。

4.6.2.4 プラン削除

エージェントごとの最大プラン数は、次の設定で指定する。

<module name="replanning">
  <param name="maxAgentPlanMemorySize" value="5" />
  ...
</module>

エージェントのプラン数がこの値を超えた場合、MATSim はプランを 1 つずつ削除していき、最大数に収まるまで繰り返す。削除対象プランは、次の設定で指定する。

<module name="replanning">
  <param name="planSelectorForRemoval" value="..." />
  ...
</module>

利用可能なオプションは config ファイルのコメントに記載されている。この設定自体については、まだ十分な研究がなされていない（「Research Avenues」章の Choice Set Generation セクション参照）。
デフォルトでは、メモリがいっぱいになったとき、スコアが最も低いプランが削除される。

4.6.3 プラン選択（Choice）

選択戦略とその重みも、次のように strategyName として追加される。

<param name="strategyName" value="KeepLastSelected | BestScore | SelectExpBeta | ChangeExpBeta | SelectRandom | SelectPathSizeLogit" />

各セレクタの動作は以下のとおりである。

• KeepLastSelected
  前イテレーションで選択されていたプランをそのまま選ぶ。

• BestScore
  現時点でスコアが最も高いプランを選ぶ。

• SelectExpBeta
  離散選択モデルにおける多項ロジット（MNL）に相当する形で、プランを選択する。scoring config グループ内の BrainExpBeta パラメータ⁴でスケールパラメータ（式 ?? 参照）を指定する。通常はデフォルト値 1.0 のままを推奨する。

• ChangeExpBeta
  異なるプランへ切り替える確率を e^(Δscore) に依存して定める。ここで Δscore は 2 つのプランのスコア差である。この戦略も MNL のサンプリングを行う（「Agent-Based Traffic Assignment」章の Selection (Choice) セクション参照）。

• SelectRandom
  プラン集合からランダムに選択する。

• SelectPathSizeLogit
  Frejinger and Bierlaire (2007) による path size logit モデルに基づき、既存プランの中から選択を行う。PathSizeLogitBeta パラメータは scoring config グループ⁵で設定する。このセレクタは系統的な検証がまだなされていない。

BestScore の使用には注意が必要である。稀な交通渋滞など、一度のイテレーションだけの偶然要因により低スコアとなったプランは、その後二度と選択されなくなり、再評価されない。そのため、何らかのランダム性を含むセレクタ（SelectExpBeta や ChangeExpBeta など）と組み合わせて使うことが推奨される。

4.6.4 イノベーションの停止

理論的観点（「Agent-Based Traffic Assignment」章の Innovation (Choice Set Generation) セクション参照）からは、どこかの時点でイノベーション戦略を停止し、その後は各エージェントのプラン集合を固定することが望ましい。これは次の設定で制御できる。

<param name="fractionOfIterationsToDisableInnovation" value="..." />

この設定は、スコアの移動平均（Method of Successive Averages, MSA；第 14.3.3 節参照）と併用するのが望ましい。

4.7 観測モジュール

4.7.1 Travel Time Calculator

たとえば経路探索モジュールは、全リンクの旅行時間推定を必要とする。この計算負荷を制御するために、旅行時間推定は時間ビンに集約される。このビン幅などのパラメータは、config ファイルの travelTimeCalculator セクションで指定できる。

4.7.2 Link Stats

linkStats セクションでは、各リンクのシミュレーション統計をどの間隔で出力するかを指定できる。出力されるボリューム値を「各イテレーションごと」にするか、「複数イテレーションにわたって平均する」かも設定可能である。
link stats は、多くの用途の一つとして、第 11.4 節で紹介される交通量カウントデータとの比較にも利用される。

4.8 さらなる情報源

シミュレーション実行時には、output_config.xml というファイルが生成される。このファイルには、その実行で実際に用いられたすべての設定が含まれており、ほとんどの設定項目にはコメントが付属している。config スイッチの意味を確認する際には、まずこのファイルを参照するのがよい。

もし説明のないスイッチがあり、その意味が必要な場合は、https://matsim.org/faq で問い合わせれば、可能な限り早急に改善が試みられる。

完全な config ダンプ（すべてのコメント付き）は logfile.log にも含まれている。また、第 2.1.3 節で説明した方法により、すべてのスイッチがデフォルト値で設定された完全な config ファイルを生成することもできる。

ただし、完全な config ファイルの利用は明示的に推奨されない。むしろ、自分がデフォルトから変更したいスイッチだけを指定するべきである。
その理由は、我々が研究の進展に応じてデフォルト値を更新しており、それらを利用することでユーザのシミュレーションも最新の「ベストプラクティス」に追従できるからである。すべてのスイッチを明示的に設定してしまうと、この利点を失い、時間とともに「我々が最適と考える設定」から乖離していくことになる。また、スイッチの追加・変更・削除による互換性問題も起こりやすい。

自動生成される output_config_reduced.xml は、短い config ファイルを作成する際の出発点として利用できる⁶。

⁶ ただし、このファイルからさらに削除すべき内容も一部残っており、現時点では完全自動でクリーンな短縮版が得られるところまでは到達していない。