SUMO Wiki
0 / 0
SUMO Wiki
モデルは一般に非常に複雑になり得るため、あるレベルを超えると結果がどこから得られたのかを追跡するのが極めて難しくなります。デバッグツールを使う理由は2つあります。モデルが予想外に遅くなった場合、または結果が私たちの理解と一致せず、背後にある方程式や値を確認する必要がある場合です。
モデルのシミュレーション速度を確認するためのガイドラインを最初の章で示します。その手順をたどることで、シミュレーションが遅い理由を突き止められる場合があります。
結果の根本原因を理解し、デバッグを支援するために、Sumo には XML デバッグツールがあります。
SUMO の構成が不合理なほど遅いと思われる場合、以下のコマンドがその理由に関する情報を提供してくれることがあります。
以下のコマンドの先頭から # を外すことで、User Script のデバッグ機能を有効にします。User Script を編集するには、描画ボード上部のノートアイコンをクリックするか、Advanced|Userscript メニューを開きます。
set Sumo__Debug 1; # より多くのデバッグメッセージを有効にします
set Sumo__SilentSolvers 0; # ソルバー関連のエラーメッセージを表示します
Dynamic model debug 1 - User ScriptNote
実行が遅くなる主な理由は次のとおりです。
シミュレーションエンジンから背景情報を収集するために、モデルのソースコードは XML デバッガーから入手できます（使用方法は次の章を参照）。実行後の最初のステップとして注目すべき主要な変数があります。
次のステップは、OUTPUTS タブでテーブルを作成することです。
Bardenpho の例では、100 日後のテーブルは次のようになります。
Dynamic modeling debug 3 - BardenPho errors after 100 daysこのテーブルは、最大の導関数が汚泥ブランケット内の XU 濃度（unbiodegradable particulate COD）であったことを示しています。モデルが正常に動作している場合、一つの変数に固執することはなく、進行につれて変数を切り替えていきます。また、_error 変数をタイムチャートに配置して動的に確認することもできます。
ループエラーを確認する別のアプローチとして、XML デバッガーの Blocks タブで「AlgebraicLoop」ブロックを確認する方法があります。各ブロックセクションの末尾に、Sumo__Plant__Pipe6_Q_error や Sumo__Plant__Pipe10_Q_error のように _error で終わる変数が1つ以上見つかります。
Dynamic model debug 2 - Algebraic blocks at XML debugger
ActualStep と AvgStep をタイムチャートに配置すると便利です。ほとんどの場合、ステップは小さく始まり、その後すぐに Data Interval の値（デフォルト：1 時間、3600 秒）まで増加します。変更のない実行中でもステップが小さくなるのを見かけるのは正常です。
Dynamic modeling debug 4 - Steps with constant input動的な流入水やその他の動的データは、常にタイムステップを短くします。動的データポイント間の補間はソルバーを大幅に遅くします。次の画像は流入水にバースデーケーキ（birthday cake）を追加したもので、前の実行とステップサイズを比較してください。
Dynamic modeling debug 5 - Steps with birthday cake influentこの手順により、問題のある反応槽や変数が示され、それについてより詳細な調査が必要になる場合があります。
速度に関する情報のさらなる層は、各種評価のカウンターを追跡することで収集できます。これらのカウンターは、Debug ブロックを開くことで、Raw フィルターを用いて OUTPUT 設定のテーブルに追加できます。
Dynamic modeling debug 6 - Countersintegrated カウンターは統合ブロック評価の回数を示し、algebraic loop はループ評価の回数を、DataComm はシミュレーション中の Data Interval の回数を、Accumulated はステップの回数を示します（StopTime をこの値で割ると、これまでのステップの平均ステップが得られます）。これらの数値から得られる情報は次のとおりです。Loop と Integrated カウンターの比はどうなっているか？ この比が 5 を超える場合、代数ループを解くのが厄介であり、正しい解を見つけるのに多くの時間がかかることを意味します。
pH 計算が有効になっている場合、Equilibrium 計算についても同様のカウンターが利用でき、Equilibrium と Integrated の比が重要になります。この比が 15 を超えると、pH ソルバーが解を求めるのに苦労しており、実行が遅くなります。
モデルが本来予測すべき数値を予測しない場合、その内部の仕組みを確認し、どのように計算されているかを調べるのが通常は良い方法です。XML デバッガーを使うと、これを簡単に行えます。ここでは MLE プラントを例に、このツールの使い方を説明します。
デバッグしたい状態までシミュレーションを実行したら、Advanced メニューで XML Debugger をクリックするか、Ctrl-Shift-X を押します。
XML Figure 1 - Start debugger- Sumo XML debugger という新しいウィンドウが開きます。
XML Figure 2 - Debugger opening screen- 現在のプロジェクトの xml を読み込みます。
XML Figure 3 - Current XML loaded左側には3つのブロックがあります。
他の XML を読み込んで参照したり、さらには構築したりすることもできますが、数値が得られるのは現在のものだけです。
xml が読み込まれると、ブロックを開いてウィンドウ左側から変数を選択できます（ウィンドウを最大化すると全体が見やすくなります）。
この例では、Primary sludge flow が予想と異なる理由を確認します。したがって、汚泥の流量から始めます。一次汚泥の流量がどのように計算されるかを理解します。
デバッガーで追跡したい変数のシンボルを見つける方法はいくつかあります。最も簡単なのは Sumo Outputs タブから始める方法です。開いている Sumo プロジェクトの Outputs タブに移動し、次を変更します。
これが一次汚泥流量にどう反映されるか見てみましょう。下の図（XML Figure 4）では、ユニット名と、テーブルの最初の列の変数名が変更されています。Mass flows テーブルはシンボル「Q」で始まっており、これはもともと「Flow rate」（Advanced|Variable identifier|Name）として表示されていたものです。ただし列ヘッダーは、私たちが探しているユニット名ではなく、番号付きのパイプになっています。View|Show pipe names オプションをオンにすることで一次汚泥パイプを特定できますし、あるいは単に Sludge ユニットをテーブルにドラッグ＆ドロップすることもできます。その列を Pipe2 の隣に移動すると、両者が同一の値を持つことがわかります。
XML Figure 4 - Symbols and Incode names showedこのプロジェクトにおける一次汚泥流量の変数シンボルは、Sludge ユニットの「Q」です。
変数のシンボルを特定したら、その変数を見つける方法はいくつかあります。
Namespaces に直接移動します：Sumo|Plant|Sludge。これにより、Sludge プロセスユニットで使用されているすべての変数が下部にリストされます。リストは膨大ですが、その中に「Q」があります。
XML Figure 5 - Use Namespaces structure
変数シンボルを一般的な規則に従って入力します：ユニット名__変数名。この場合は Sludge__Q です。
変数の完全な Incode 名には特殊文字は含まれず、名前空間のレベルは常に「__」で区切られます。検索フィールドは正規表現を受け付けるため、結果のリストをより簡単に制御できます。
XML Figure 6 - Search by symbol
変数が左下パネルのリストに表示されたら、それを選択します。右側には次の情報が表示されます。
上部のセクションには変数の仕様が表示されます。
仕様のすぐ下の最初の行は、常にその変数がどのように計算されるかを表す方程式です。左側が変数、右側が式です。この行は codelocation（計算がいつ実行されるか。詳細は Book of SumoSlang を参照）で始まり、blocksection、row と続き、最後に以下のように方程式が示されます（完全な方程式を見るには右にスクロールする必要があります）。
XML Figure 7 - Variable specification and calculation方程式は完全な Incode 名を使用しており、各変数の下には現在の値が示されています。この方法により、計算で誤った値を使用している変数を特定できます。
式で使用される変数は、識別しやすいように色分けされています。
注：調査対象の変数がエイリアス（Aliased To を持つ）である場合には不具合があり、その Aliased to の変数をクリックする必要があります（この場合は Pipe2__Q）。
計算で使用されている変数の名前を調べるには、Sumo Outputs を使用できます。左下パネルで Symbols/Raw を選択し、（F_XTSS を選択し Influent を選択したうえで）変数名を入力します。
XML Figure 8 - Find out variable nameF_XTSS が TSS 質量流量を表すことを確認するために、Advanced|Variable identifier を Names に戻すのを忘れないでください。
最初の式（Sludge Q = influent TSS mass flow * removal percent/sludge TSS concentration）が役に立たない場合（唯一の systemstate が Influent__F_XTSS であるため）、このツールには変数を掘り下げて追跡する機能があります。その変数をクリックするだけで、下に示す Influent__F_TSS のように、その変数についても同じ情報が得られます。このページでは、調査対象の変数が赤い文字でハイライトされます。File メニューの隣には、すでに確認した変数間を移動するための Back と Forward の2つのボタンがあります。Back メニューを使うと、ツールは Sludge__Q 変数の計算に戻ります（XML Figure 9）。
XML Figure 9 - Variable specification and calculation, next step調査対象の変数の計算の下には、その変数が式の中で使用されているすべての方程式がリストされます（右側で赤くハイライトされます）。
このようにして、どの計算またはどの入力パラメータが誤っているのかを一歩ずつ突き止めることができます。